When you set up alerts in MongoDB Management Service, you now have the option to send them to PagerDuty. Like MMS, PagerDuty helps you increase application uptime and identify performance issues. With this new integration, you can set up multiple on-call schedules in PagerDuty to rotate your MMS alerts to different members of the team.
MongoDB Management Service tracks dozens of different MongoDB-specific metrics, providing you with visibility into the performance of you MongoDB system. Using MMS, you can create alerts when particular statistics are out of range. While previously you were limited to setting email and mobile alerts to individual members of the team, you can now rotate those alerts around your team, giving everyone time off by easily scheduling on-call rotations. And with PagerDuty, there are automated escalations so you can be sure that you’ll never miss an alert.
Meet Alvin Richards: Technical Director for Performance and Quality
Meet Alvin Richards, MongoDB’s Technical Director for Performance and Quality. What is your role at MongoDB? I’m MongoDB’s Technical Director for Performance and Quality. I work in the engineering department, but my job is cross-functional across all our products. I make sure everything we produce is high quality, acceptable, correct, and performant. Where were you before MongoDB? Why did you choose to come to MongoDB? I’ve worked at a variety of small companies and startups. Right out of college I started at Oracle, a little company building this new thing called a relational database. Soon Oracle became the market leader in that space; we’d completely changed how people thought about data. After sixteen years I left to work at a variety of startups and pursue a second degree. When I joined MongoDB, I felt like it was the way Oracle had been in the eighties; we were disrupting the ways people thought about their data. We were fixing areas where relational theory had broken down and now we’re reinventing the industry. I’ve been here for four years and we’ve just only started. What’s your hometown? That’s a good question. My heart says San Francisco, but my birth certificate says London. Right now I live in Belmont, California. Did you have previous experience using MongoDB before you arrived? If so, how are things different now that you work at MongoDB? My education was Dwight asking me to build a 100-node cluster for a conference in 6 weeks. So it was a baptism of fire in learning the technology, how to deploy something that size on EC2, figuring out LVM versus MD and many other issues. I love we now have a formal education program… but sometimes I think the new employees are missing out on an experience. Have you had any personal projects where you’ve used MongoDB? I’m hacking my Linn Magik DS at home. I think I can do better than the Frankenstein set of technologies the vendor thinks I have to use to simply play music over a network. Bike or public transportation to work? Electric car. I get to hack the system by being in a car alone and using the carpool lane. That’s California! What’s a typical day (or week) for you? We work in a form of organized chaos because we’re developing a new product and disrupting an existing space. You need to be able to think on your feet but keep the mission in mind. Each day starts with a triage of what happened overnight, covering everything from customer cases, performance runs in the lab, requests from the field or partners. It’s then trying to find the balance of keeping the short term moving but make progress on your strategic goals (i.e. keep your eyes on the prize). What do you love most about MongoDB? The people. There were only twelve of us when I joined and now we’re 340. Part of the joy of being here is watching the growth of not only the organization but also the people. New hires mature and take on new roles and opportunities. It’s very exciting to watch. What’s the most challenging aspect of your job? Solving the next problem. I could say starting as the initial employee in California and building that team from scratch. Then going to Europe for two years and doing the same thing for a whole continent. We had to go to community events, contact existing customers and find new ones, join meetups, and try to figure out what was happening when and where and why. You have to do literally everything. I’m doing the same with my new team, starting from scratch and building in three locations (New York, Palo Alto and Austin) at the same time. What’s one of the most rewarding experiences you’ve had working here so far? Random people coming up to me after to talk or meetup to tell me that I’ve helped them think through the problems they have been having. What’s your favorite Seamless lunch order? BLT from ‘wichcraft Name one secret skill you have, unrelated to work. Debugging a 1965 Datsun Fairlady. A rare but critical skill to ownership. Kindle or book? What’s your favorite book? Always a book, preferably on a beach. I’m not sure if this is my favorite but I enjoy “Season of Blood” by Fergal Keene immensely. Describe your perfect weekend. The kids don’t wake me up too early (they’re 11 and 8). Southampton wins a soccer game. I get to spend time with the family and dog (a 2 year old Hungarian Vizsla). Maybe playing some Apex Twin or Underworld a little too loudly on the turntables. So what did you get that second degree in? I graduated with a degree in computer science when I was 19. I worked at Oracle for about 7 or 8 years, and then I realized that tech was here to stay, and I could really do this job for the rest of my life. So I decided to go out and do what I wanted before things got too complicated (worrying about a family, marriage, etc.) I got a degree in photography, then went off to travel the world and take photos. I did a lot of work for the IRCR (International Committee of the Red Cross). They were fun times and a great way to collect stories to tell the grandchildren, but the bug of technology was never far away for me. If you're interested in joining the MongoDB Team there many open positions available in Engineering, Sales, Marketing, and Business Development. To learn more about open roles at MongoDB, please visit the MongoDB Careers Page .
Data Resilience with MongoDB Atlas
Data is the central currency in today's digital economy. Studies have shown that 43% of companies that experience major data loss incidents are unable to resume business operations. A range of scenarios can lead to data loss, yet within the realm of database technology, they typically fall under three main categories: catastrophic technical malfunctions, human error, and cyber attacks. A data loss event due to a catastrophic breakdown, human error, or cyber attack is not a matter of if, but a matter of when it will occur. Hence, businesses need to focus on how to avoid and minimize the effects as much as possible. Failure to effectively address these risks can lead to extended periods of downtime of a few hours or even a few weeks following an incident. The average cost of cyberattacks is a surprising $4.45 million, with some attacks costing in the hundreds of millions. Reputational harm is harder to quantify but no doubt real and substantial. The specific industry you're in might be subject to regulatory frameworks designed to counter cyber attacks. Businesses that are subject to regulatory regimes must maintain compliance with these requirements. This can determine the configuration of your disaster recovery approach. In this blog post, we'll explain the key disaster recovery (DR) capabilities available with MongoDB Atlas . We'll also cover the core responsibilities and strategies for data resilience including remediation, and recovery objectives (RTO/RPO). Planning for data resilience in Atlas Data resilience is not a one-size-fits-all proposition, which is why we offer a range of choices in Atlas for a comprehensive strategy. Our sensible defaults ensure you're automatically safeguarded, while also offering a variety of choices to precisely align with the needs of each individual application. When formulating a disaster recovery plan, organizations commonly begin by assessing their recovery point objective (RPO) and recovery time objective (RTO). The RPO specifies the amount of data the business can tolerate losing during an incident, while the RTO indicates the speed of recovery. Since not all data carries the same urgency, analyzing the RPO and RTO on a per-application basis is important. For instance, critical customer data might have specific demands compared to clickstream analytics. The criteria for RTO, RPO, and the length of time you need to retain backups will influence the financial and performance implications of maintaining backups. With MongoDB Atlas, we provide standard protective measures by default, with customizable options for tailoring protection to the service level agreements specified by the RPO and RTO in your DR plan. These are enhanced by additional features that can be leveraged to achieve greater levels of availability and durability for your most vital tasks. These features can be grouped into two main categories: prevention and recovery. Backup, granular recovery, and resilience There are many built-in features that are designed to prevent disasters from ever happening in the first place. Some key features and capabilities that enable a comprehensive prevention strategy include multi-region and multi-cloud clusters , encryption at rest , Queryable Encryption , cluster termination safeguards , backup compliance protocols , and the capability to test resilience . (We will discuss the features in-depth in part two of this series.) While prevention might satisfy the resilience needs of certain applications, different applications may demand greater resilience against failures based on the business requirements of data protection and disaster recovery. MongoDB provides comprehensive management of data backups, including the geographic distribution of backups across multiple regions, and the ability to prevent backups from being deleted, all through an automated retention schedule. Recovery capabilities are aimed at supporting RTO and minimizing data loss and include continuous cloud backups with point-in-time recovery. Atlas cloud backups utilize the native snapshot feature of your cluster's cloud service provider, ensuring backup storage is kept separate from your MongoDB Atlas instances. Backups are essentially snapshots that capture the condition of your database cluster at a specific moment. They serve as a safeguard in case data is lost or becomes corrupted. For M10+ clusters, you have the option of utilizing Atlas Cloud Backups, which leverage the cluster's cloud service provider for storing backups in a localized manner. Atlas comes with strong default backup retention of 12 months out of the box. You also have the option to customize snapshot and retention schedules, including the time of day for snapshots, the frequency at which snapshots are taken over time, and retention duration. Another important feature is continuous cloud backup with point-in-time recovery, which enables you to restore data to the moment just before any incident or disruption, such as a cyber attack. To ensure your backups are regionally redundant and you can still restore even if the primary region that your backups are in is down, MongoDB Atlas offers the ability to copy these critical backups, with the point-in-time data, to any secondary region available from your cloud provider in Atlas. For the most stringent regulations, or for businesses that want to ensure backups are available even after a bad actor or cyber attack, MongoDB Atlas can ensure that no user, regardless of role, can ever delete a backup before a predefined protected retention period with the Backup Compliance Policy. Whatever your regulatory obligations or business needs are, MongoDB Atlas provides the flexibility to tailor your backup settings for requirements. Crucially, this ensures you can recover quickly, minimizing data loss and meeting your RPO in the event of a disaster recovery scenario. When properly configured, testing has shown that Atlas can quickly recover to the exact timestamp before a disaster or failure event, giving you a zero-minute RPO and RTO of less than 15 minutes when utilizing optimized restores. Recovery times can vary due to cloud provider disk warming and which point in time you are restoring to. So, it is important to also test this regularly. This means that regardless of your regulatory or business requirements, MongoDB Atlas allows you to configure your backups to ensure that you can meet your recovery requirements and, most importantly, recover with precision and speed to ensure that your data loss is minimal and your recovery point objectives are met should you experience a recovery event. Conclusion As regulations and business needs continue to evolve, and cyber-attacks become more sophisticated and varied, creating and implementing a data resilience strategy can be simple and manageable. MongoDB Atlas comes equipped with built-in measures that deliver robust data resilience at the database layer, ensuring your ability to both avoid incidents and promptly restore operations with minimal data loss if an incident does occur. Furthermore, setting up and overseeing additional advanced data resilience features is straightforward, with automation driven by a pre-configured policy that operates seamlessly at any scale. This streamlined approach supports compliance without the need for manual interventions, all within the MongoDB Atlas platform. For more information on the data resilience and disaster recovery features in MongoDB Atlas, download the Data Resilience Strategy with MongoDB Atlas whitepaper. To get started on Atlas today, we invite you to launch a free tier today .