One of the core components of MongoDB Atlas, the cloud database service for MongoDB, is the fully managed disaster recovery functionality. With continuous backups, you can take consistent, cluster-wide snapshots of sharded deployments and trigger point-in-time restores to satisfy demanding recovery point objectives (RPOs) from the business. Continuous backups also allow you to query backup snapshots to restore granular data in a fraction of the time it would take to restore an entire snapshot.
Today we’re making it even easier to manage your backups with an expanded Atlas API. Programmatically get metadata about your snapshots, delete them, or change their expiration. Trigger restore jobs and retrieve them. The MongoDB Atlas API allows you to incorporate the rich functionality of Atlas fully managed backups into workflows optimized for how you manage your IT resources.
Visit our documentation for more information.
Cloud Provider Snapshots for Azure
We are also introducing a new type of managed backup service for MongoDB Atlas, using the native snapshot capabilities of your cloud provider. With cloud provider snapshots, your backups will be stored in the same cloud region as your managed databases, granting you better governance over where all of your data lives.
Compared to continuous backups, cloud provider snapshots allow for fast restores of snapshot images. Pricing, which varies slightly from region to region, is also lower.
Cloud provider snapshots are available today for replica sets on Microsoft Azure. Support for Amazon Web Services and Google Cloud Platform will be rolled out later this year.
If you’re considering switching backup methods (from continuous backup to cloud provider snapshots), consider creating a separate project in MongoDB Atlas. For each Atlas project, the first cluster you enable backups for will dictate the backup method for all subsequent clusters in the project. To change the backup method within the same the project, disable backups for all clusters in the project, then re-enable backups using your preferred backup methodology. MongoDB Atlas automatically deletes any stored snapshots when you disable backups for a cluster.
Not yet a MongoDB Atlas user? Create an account and get a free 512 MB database.
MongoDB Has Revamped Its Parental Leave Policy
To kick off the new year, the MongoDB Human Resources team introduced an updated Parental Leave Policy to the company. Now that MongoDB has over 900 employees globally, the previous policy was no longer suitable or scalable, and it had the potential for improvement. With each new year we strive to be better and do more based on the needs, wants, and interests of our employees. My name is Dan Heasman and I am the most recent addition to the MongoDB leadership team. As Chief People Officer and a father of two, I was particularly passionate and excited about updating our parental leave. A strong support for mothers and fathers at the start of the incredible parenting journey is absolutely essential to our goals of fostering a highly inclusive culture and ensuring MongoDB is a great place to come and build a career. The new policy, effective as of January 1, 2018, allows for 20 weeks of paid leave for both mothers and fathers, as well as additional programs to provide assistance. Parental leave can be taken at any time, in separate durations if desired, within the first year. To facilitate a smooth transition when returning to work, employees are also able to participate in an additional 4-week flexible work arrangement with intermittent leave within the first year. This is all in addition to our unlimited vacation policy and flexible work from home standards. I spoke with some of our employees regarding the policy, including those who experienced the previous version, and those who are already experiencing or will experience the new policy. They provided some really great insight on the real concerns expecting parents face while maintaining their career. Andy Schwerin, Vice President of Engineering for the MongoDB Core Server team, is responsible for the design and development of sharding, replication and query execution, and the teams that build them. He is a father of three, having had one child in his first year at MongoDB and adding two more in the years since. “Before our second child was born we had just moved to New York and our biggest concern was that my wife would go into labor while I was at the office. At the time, MongoDB was a much smaller company with limited leave policies. I think the new policy is a terrific idea. Talented, motivated people are hard to hire and important to retain. A generous parental leave policy sends the message that MongoDB values its employees, and that it’s willing to support employees as we grow our families.” A gender neutral approach was particularly important for us moving forward because both parents should be able to share the responsibilities regardless of gender. Duncan Armstrong is a Senior Developer, working as a backend developer on MongoDB cloud products, as well as mentoring, pairing, and reviewing code for other developers. He is also the father of 15-month-old twin boys. For his wife, pregnancy was incredibly difficult due to a medical condition, and Duncan needed a lot of support from his leaders and team at MongoDB. “I had to work from home often, or work off hours so I could look after and help my wife. There was never any hint of disapproval from my manager. The only problem with our previous program was that four weeks of leave wasn’t really sufficient. It’s hard enough for inexperienced parents to look after one newborn, but with twins, it was a full on rollercoaster. I really had to figure out how to manage my time. Because MongoDB has unlimited general leave it was easy to take extra time off when I needed to, and I was able to work from home a lot the first few months. “In regards to the new policy, I’m so happy MongoDB has taken this step. As a father I know it can be hard bonding with your newborn. In the beginning they don’t give you much in return for your many efforts and the only way around that is to spend a lot of time with them. I don’t know how you can get that kind of bonding time if you’ve got to be back at the office full-time after just a couple of weeks.” Keeping these types of experiences in mind, we opted to provide additional benefits within the program to address some of the common obstacles expecting parents will face during pregnancy. The MongoDB Parental Buddy Program provides support by connecting both birth, foster, and adopting parents as they prepare for the arrival of their baby, during their parental leave, and during their return to work. LUCY provides employees with fully personalized and customizable counselling. From pregnancy through the baby's first year, sessions are conducted by a team of licensed, vetted health and wellness experts on all aspects of taking parental leave – from coping with morning sickness to choosing the right childcare. Our global Employee Assistance Program provides employees with free counseling sessions to and includes a program to help new parents deal with the natural stress and emotional adjustment that comes with being a first time parent. (EAP offers free counseling for all employees, not only new parents.) Ozge Tuncel is our VP of Customer Success and Sales Development, working out of our NYC headquarters for the last three years. A little over a year ago, Ozge was the only expecting mother in our New York office. “At the time, there was no one other than me going through the experience in New York. The policy was three months of leave, with the ability to work from home as needed, and a very nice private room in the office available as a mother's room. Our HR team had a great process to help with formal steps, the executive team was very supportive during my transition back to work, and flexible working hours were very helpful. What we lacked was an informal peer support system that any new parent needs. We now have more new parents, a new-moms Slack channel, and the Parental Buddy Program, which are all great for advice and support.” We are very excited for our currently expecting parents and future parents-to-be to experience all that the new program has to offer. New parents can now expect flexibility baked in, removing the need to request or negotiate time off or time away – which can be perceived either by the employee or manager as an individual accomodation, one that generally comes at the cost of other members of the team. Jen Tyrseck is our Director of Corporate Communications, managing company-wide communications internally and externally to help people learn more about and gain confidence in MongoDB. She recently had her first child at the end of January, and is the first employee to experience our updated parental leave policy. “Thinking back to the beginning of my pregnancy, I did have a number of (unwarranted) concerns regarding how I would balance working full time and the challenges of pregnancy. Things like, ‘Would I become suddenly sick at my desk? Would my team question my commitment to the job and company? Could I manage the new expectations required of me to continue performing well in my job, while raising a family?’ “I’ve really been impressed with the support I’ve received. A flexible, work-from-home as needed schedule has permitted me the time to attend all doctor’s appointments. I also have access to licensed health and wellness experts for customized counselling on planning for parental leave, preparing for labor and delivery, and newborn basics as well as counselling sessions after the baby comes regarding lactation, sleep transitioning, and how to ease back to work. A strong network of women interested in mentoring and sharing experiences to learn how to balance the inevitable changes, including how to balance my life in two full-time roles, has also been invaluable.” Graham Neray is the Chief of Staff to MongoDB CEO Dev Ittycheria. His wife, Meghan Gill, is our VP of Sales Operations, and reports directly to CRO Carlos Delatorre. They met at work, married in October of 2016, and welcomed their first child in early January of this year. Both are extremely passionate about their careers, and are on very lean teams, so questions arose when they decided to start a family – particularly how to adapt to being on leave at a fast-paced company where things are constantly evolving, and how to balance their roles at MongoDB while adjusting their schedules to their new lives as parents. “On other teams, everyone can take on a little bit of what you’re doing – maybe 10% or 20% each while you’re out. As Chief of Staff, I am essentially a team of one and I do a little bit of everything,” Graham noted, “so I had to find other people on other teams to pitch in while I’m on leave – in finance, marketing, partners, and HR. Dev’s EA helped out a lot too. In the end, everyone has been very supportive, especially Dev. Over and over he told me: ‘family comes first.’ ” “The most important thing for us is flexibility,” said Meghan. “For instance, we were both able to easily step out for appointments while I was pregnant, and through LUCY, we took several classes to prepare for life as new parents. Now that we have a baby, there will of course be more visits to the doctor and other things that pop up. “MongoDB has been a center of gravity for us for a while – now we have a new center of gravity. From our experience during the pregnancy, it’s comforting to know that we can successfully make use of a flexible work arrangement to get it all done.” Current parental leave standards throughout the world, and in the U.S. especially, can de-prioritize starting a family if the choice has to be made between pursuing a career and beginning this new life, rather than doing both at the same time. We are proud of the steps we are taking to ensure no MongoDB employee ever feels obligated to make that choice, and has the support they deserve from the organization they have selected to give their dedication and time.
MongoDB’s Drive to Multi-Document Transactions
Transactions are important. Any database needs to offer transactional guarantees to enforce data integrity. But they don’t all do it in the same way – different database technologies take different approaches: Relational databases model an entity’s data across multiple rows and parent-child tables, and so transactions need to span those rows and tables. With subdocuments and arrays, document databases allow related data to be unified hierarchically inside a single data structure. The document can be updated with an atomic operation, giving it the same data integrity guarantees as a multi-table transaction in a relational database. Because of this fundamental difference in data modeling, MongoDB’s existing atomicity guarantees are able to meet the data integrity needs of most applications. In fact, we estimate 80%-90% of applications don’t need multi-document transactions at all. However, there are some legitimate use cases and workloads where transactions across multiple documents are needed. In those cases, without transactions, a developer would have to implement complex logic on their own in the application layer. Also, some developers and DBAs have been conditioned by 40 years of relational data modeling to assume multi-table/document transactions are a requirement for any database, irrespective of the data model they are built upon. Others are concerned that while multi-document transactions aren’t needed by their apps today, they might be in the future and they don’t want to outgrow their database. And so, the addition of multi-document ACID transactions makes it easier than ever for developers to address a complete range of use-cases on MongoDB. As one can imagine, multi-document transactions are a much more complex thing to build in a distributed database than in a monolithic, scale-up database. In fact, we have been working on bringing multi-document transactions to MongoDB as part of a massive multi-year engineering investment. We have made enhancements to practically every part of the system – the storage layer itself, our replication consensus protocol, sharding architecture, consistency and durability guarantees, the introduction of a global logical clock, and refactored cluster metadata management and more. And we’ve exposed all of these enhancements through APIs that are fully consumable by our drivers. The figure below represents the evolution of these enhancements as well as the work in progress to enable multi-document transactions. As you can see, we are nearly done. In MongoDB 4.0, coming in summer 2018*, multi-document transactions will work across a replica set. We will extend support for transactions across a sharded deployment in the following release. Importantly, the green boxes highlight all of the critical dependencies to transactions that have already been delivered over the past 3 years. And, frankly, that was the hardest part of the project – how to balance building the stepping stones we needed to get to transactions with delivering useful features to our users straightaway to improve their development experience along this journey. Wherever we could, we built components that suited both goals. For example, the introduction of the global logical clock and timestamps in the storage layer enforces consistent time across every operation in a distributed cluster. These enhancements are needed for transactions in order to provide snapshot isolation, but they also allowed us to implement change stream resumability and causal consistency in MongoDB 3.6, which are immediately valuable on their own. Change streams enable developers to build reactive applications that can view, filter, and act on data changes as they occur in the database in real-time, and recover from transient failures. Causal consistency allows developers to maintain the benefits of strong data consistency with “read your own write” guarantees, while taking advantage of scalability and availability of our intelligent distributed data platform. The global logical clock is just one example. A selection of other key enhancements along the way illustrates how our engineering team deliberately laid the groundwork for transactions in such a way that we consistently surfaced additional benefits to our users: The acquisition of WiredTiger Inc. and integration of its storage engine way back in MongoDB 3.0 brought massive scalability gains with document level concurrency control and compression to MongoDB. And with MVCC support, it also provided the storage layer foundations for transactions coming in MongoDB 4.0. In MongoDB 3.2, the enhanced consensus protocol allowed for faster and more deterministic recovery from the failure or network partition of the primary replica set member, along with stricter durability guarantees for writes. These enhancements were immediately useful to MongoDB users then, and they are also essential capabilities for transactions. The introduction of readConcern in 3.2 allowed applications to specify read isolation level on a per operation basis, providing powerful and granular consistency controls. Logical sessions in MongoDB 3.6 gave our users causal consistency and retryable writes, but as a foundation for transactions, they provide MongoDB the ability to coordinate client and server operations across the nodes of a distributed cluster, managing the execution context for each statement in a transaction. Similarly, retryable writes, implemented in MongoDB 3.6, simplify the development of applications in the face of elections (or other transient failures) while the server enforces at most once processing semantics. Replica set point in time reads in 4.0 are essential for transactional consistency, but it’s also highly valuable to regular read operations that don’t need to be executed in a transaction. With this feature, reads will only show a view of the data that is consistent at the point the find() operation starts, irrespective of which replica serves the read, or what data has been modified by concurrent operations. The number of remaining pieces on the roadmap to transactions is small. Once complete, multi-document distributed transactions will provide a globally consistent view of data (both in replica set and sharded deployments) through snapshot isolation and maintain all-or-nothing guarantees in cases of node failures. This will greatly simplify your application code. After all, MongoDB’s job is to take hard problems and solve them for as many developers as possible, so that you can focus on adding value to your applications and not dealing with the underlying plumbing. We’re really excited about the release of multi-document transactions, and what they will allow you to build with MongoDB going forward. You should view our multi-document transactions page to learn more, and we invite you to sign up for the beta program so that you can start to put all of the work we’ve done through its paces. * Safe Harbour Statement This post contains “forward-looking statements” within the meaning of Section 27A of the Securities Act of 1933, as amended, and Section 21E of the Securities Exchange Act of 1934, as amended. Such forward-looking statements are subject to a number of risks, uncertainties, assumptions and other factors that could cause actual results and the timing of certain events to differ materially from future results expressed or implied by the forward-looking statements. Factors that could cause or contribute to such differences include, but are not limited to, those identified our filings with the Securities and Exchange Commission. You should not rely upon forward-looking statements as predictions of future events. Furthermore, such forward-looking statements speak only as of the date of this presentation. In particular, the development, release, and timing of any features or functionality described for MongoDB products remains at MongoDB’s sole discretion. This information is merely intended to outline our general product direction and it should not be relied on in making a purchasing decision nor is this a commitment, promise or legal obligation to deliver any material, code, or functionality. Except as required by law, we undertake no obligation to update any forward-looking statements to reflect events or circumstances after the date of such statements.