Feb 19 Release Notes: More Granular Restore Points for Sharded Clusters, a Windows Installer, and more

MongoDB
February 20, 2014
#Cloud

Welcome to the MMS Blog! The blog is one of our items for this release, and we hope you will find it useful. Here we will post our release highlights, give advice, answer user questions, plus tell you a bit about what we’re working on. We are pushing new releases to production every two weeks.

For this release, we implemented a brand new onboarding flow for monitoring and backup which will streamline your MMS setup. On the UI side, we updated our theme and made the skin of MMS look much nicer.

The big ticket item in this release is the ability to restore sharded clusters to discrete checkpoints in time using MMS Backup. You can now schedule checkpoints taken at 15, 30, or 60 minute intervals. During a checkpoint, if the balancer is stopped, a token is inserted in all shards and config servers to mark that point in time. The checkpoints are stored in the oplog, giving you the ability to restore to any successful checkpoint within the last 24 hours.

We are also pleased to announce a new MSI installer for the Backup agent on Windows - it now runs as a service. Additionally, the backup agent init script for RPM was tweaked to automatically restart after a server reboot. Formerly, administrators had to restart it themselves. 

To summarize, the February 19th release contains:

  • More granular restore points for sharded clusters 
  • MSI installer for the backup agent on Windows
  • Preparation to support MongoDB 2.6
  • Better, more intuitive sign up and installation of agents for Monitoring and Backup 
  • The “Lock %” alerts are now calculated using the same definition of “Lock %” we show in charts
  • If a particular host changes state, we will now automatically close alerts (for example, MMS will auto-close replication lag alerts if host becomes primary)
  • The MMS Blog!

Have an issue or a bug or a feature request? File a ticket!

That’s all for now, folks!
-Rachelle (@techbelle)

← Previous

Getting Production Ready at Gliph with MMS

This is a guest post from Nick Asch , CTO of Gliph. Gliph is a startup with a secure messaging app that allows easy bitcoin payments. Gliph runs on top of a technology stack that includes MongoDB as the primary database for long-term data storage, from user profiles to hundreds of thousands of messages and pictures. In this post, I’ll describe how we transitioned from a proof of concept MongoDB implementation to a production-ready setup, and how we now utilize MongoDB Management Service (MMS) to ensure an excellent user experience. From Hackathon to Production A service like Gliph has fairly complicated components, including user data encryption, messaging with scheduled delivery and expiry, integration with major wallet providers (each with their own API), among many other pieces. We’re a small team adding features quickly, and iterating is easiest when your system is stable. But our system wasn’t always as robust as it is today! Gliph started as a proof of concept at a hackathon. Our use of MongoDB at that time was fairly simple. The system was designed to work 99 percent of the time, but as usage increased, edge cases popped up daily. By the time we launched our iPhone app three months later, it was time to move to production. For that, we configured multiple servers for a replica set, scheduled regular backups (and tested them), and added comprehensive error logging. Once we had a production ready database setup and configured, I started to learn how infrastructure and efficient use of the database were closely tied. Our code needed to take advantage of the intricacies of the database, and the database needed to take advantage of the structure of our app and data. Being relatively new to MongoDB, I lacked detailed knowledge of the internals and of how to optimize our backend. I needed greater visibility into my queries and to understand system performance and health. Taking off the blindfold Using monitoring from MongoDB Management Service (MMS), I was able to uncover and correct inefficiencies in our system. MMS monitors as many databases as you have, tracking system stats such as ram available. It lets you visualize the queries being performed, and set alerts when certain metrics are out of range. Here are three things that I discovered and was able to fix with the assistance of MMS: 1. Missing indexes. I didn’t realize that some queries for analytics were not using indexes. Our analytics queries run every ten minutes and it wasn’t apparent to me that they were affecting performance until I looked at the graphs MMS provides. While these queries executed, unlucky users would have to wait longer than necessary to read a new message or send one. I still wonder how many users tried signing up and were unimpressed with the latency! Several graphs showed periodic spikes exactly ten minutes apart, including the network bandwidth graph. This pointed right at the analytics queries, but still required some analysis to determine the cause of the problem. A few query hints later and I knew the problem was with missing indexes. We added an index, performance improved, and it no longer impacted our users. 2. Unnecessary fields in queries. While looking at network bandwidth, I noticed that our primary database server was returning far more data to the web server than the web server was returning to the user. After further investigation, I realized that MongoDB was returning fields that were never returned to the client. We only needed a small subset of the document. When we updated the query to make it more efficient, bandwidth decreased. 3. Completely unnecessary queries. When users retrieved messages, their messages were being marked as read, even if they were already read. This lead to unnecessary update queries. I first noticed this when looking at the opscounter graph. Updates were almost as frequent as read queries, counter-intuitive when we mostly send and receive read-only messages. Because updates are so infrequent in our application, I could quickly find in the code the unnecessary “mark-as-read” function. Rather than updating each message to mark it as read, it now keeps track of only the last message the user saw. When fixed and deployed, the graph made the improvement clear. Conclusion MongoDB’s is a great option for people looking to create web applications at the earliest stage of their venture. In my experience, it is possible to successfully move from a single instance to a robust production deployment. And tools like MMS make that transition simple by enabling you to find inefficiencies in your web application’s interaction with the database.

February 17, 2014
Next →

Congratulations to the 2023 EMEA MongoDB Innovation Award Winners

Throughout 2023, MongoDB has recognized the exceptional successes our APAC and North America customers realize when they build with MongoDB Atlas. Today, we are pleased to announce the recipients of the 2023 EMEA MongoDB Innovation Awards. These customers join a premiere group of organizations that have been recognized for boldly exploring the power of data and harnessing it to build the applications of tomorrow. The professionals behind these innovative projects span industries, use cases, and geographies. However, what remains constant is each organization's unfailing commitment to delivering deeper insights, powerful features, and capabilities, as well as seamless experiences, to their customers. We congratulate each of the EMEA MongoDB Innovation Award winners for delivering big results and invite you to find inspiration in their work below. Building the Next Big Thing Since being originally founded in Finland as a food delivery service, Wolt expanded their offering into groceries, gifts, and other items, and makes it possible for people living in hundreds of cities across 25 countries to get whatever they need, delivered quickly and reliably to their front door. Due to the rapidly increasing scale in their business and new partnerships with enterprise retailers, Wolt needed to rethink their existing tooling that is used by their tens of thousands of merchant partners to manage their offering inside Wolt’s delivery platform. To provide their merchants with multi-venue management capabilities, increased automation, and no limitations on amounts of menu items, Wolt chose fully-managed MongoDB Atlas due to its flexible data document model, support for Kafka and event-driven architectures, high performance, and limitless scalability. Industry Transformation Gong ’s Revenue Intelligence Platform uses proprietary AI technology to enable revenue teams to utilize customer interactions to increase business efficiency, improve decision-making, and accelerate revenue growth. Gong chose MongoDB Atlas as a high-performing transactional database due to its ability to handle Gong’s complex data structures and algorithms, and indeed MongoDB Atlas was able to support 30-40 million daily interactions and mission-critical search queries. Through the adoption of MongoDB Atlas, Gong’s queries take only 20-30 milliseconds, and with Atlas’ sharding capabilities, Gong future-proofed its environment for ongoing growth and gained greater control over its customer data. Innovative Leadership in Diversity, Equity, and Inclusion As part of its "Inclusion for All" strategy, Vodafone is committed to ensuring our digital society is accessible to all, and that women feel empowered to participate in it. In addition, Vodafone’s mission is to have 40% of women in management roles by 2030. Earlier this year, Vodafone UK teamed up with MongoDB to host interactive sessions and networking for “Digital & IT Women in Tech Week.” With a shared goal of reducing the gender gap in technology and inspiring young women to build their careers by pursuing leadership roles, the week’s events brought together more than 200 Vodafone employees to discuss breaking workplace biases and enhancing gender equality in the industry. In addition, Vodafone spoke at the 2023 MongoDB.local London event in the IDEA Lounge. Inspiring Innovation Ernst & Young LLP (EY) manages high volumes of transactional data and its clients and internal teams work under strict timelines to file taxes and meet regulatory deadlines. Their cloud-based Global VAT Reporting Tool (GVRT) platform automates and digitizes the preparation of 242 different types of returns across 79 countries. With support from MongoDB Professional Services, EY planned and executed a data migration from their previous database solution to MongoDB Atlas so that the GVRT tool could fully benefit from MongoDB’s developer data platform. Since migrating to Atlas, EY experienced a significant performance boost, they reduced costs by as much as 50%, and they are able to scale without limitations to handle increased data volumes, transactional loads, and concurrent user requests during peak periods. Find out Who Uses MongoDB and read more about our customers’ MongoDB Atlas successes.

September 27, 2023