Our next cloud release is here! The biggest feature of this release are the enhancements of user roles within MMS. Previously, MMS had only “Group Admin” or “Read Only” roles - these have been expanded to include:
- Read Only
- User Admin
- Monitoring Admin
- Backup Admin
All users will continue to have read-only access to all data for their Group. However, each role may modify only the appropriate modules (i.e., you must be a Backup Admin to start or stop MMS Backup, and a User Admin to modify users).
There is also now an alert for exposed hosts. If you enable this alert, MMS will periodically attempt to access your monitored MongoDB instances to make sure they are properly secured and not open to the public internet. In the event that a database is not secure, the owner will receive a notification.
The Monitoring Agent is now available in Go instead of Python. Go has fewer dependencies than Python, making the installation process seamless to the user. Our Backup Agent is also built in Go, and we’ve received lots of positive feedback on the ease of setup. We think that Go is the best fit for our agents for a variety of reasons, including its C-like syntax, strong standard library, the resolution of concurrency problems via goroutines, and painless multi-platform distribution. To learn more about our usage of Go, check out our recent post on the MongoDB blog.
Have an issue or a bug or a feature request? File a ticket in our feature request queue!
Learn About Lock Percentage: Concurrency in MongoDB
MongoDB Management Service (MMS) tracks dozens of MongoDB-specific metrics. In this post, we’ll dive into a critical statistic – lock percentage. What is locking in MongoDB? In order to allow multiple clients to read and write at the same time, MongoDB employs a locking system. This lock system ensures that the clients reading and writing to the MongoDB database each have the same view of the data. It also prevents the clients from making conflicting modifications at the same time. Prior to version 2.2, MongoDB employed a single reader/writer lock per mongod instance. Since MongoDB version 2.2, concurrency has improved and MongoDB also implements a more granular, database-level lock. In addition, long-running operations may now yield their lock if certain conditions are met. Global lock still exists, however, it is used for widespread maintenance and is used very rarely. The concurrency FAQ includes more details on how locking works in MongoDB. Should I track lock percentage? Lock contention can cause the performance of any database to degrade, and MongoDB is no exception to that rule. A high lock percentage will have impacts across the board: it can starve replication, make application calls slow, timeout, or fail. Lock contention generally needs to be kept within a reasonable threshold for a database to function smoothly. What is a normal lock percentage for a healthy MongoDB system? The normal level will vary greatly per database, though it’s difficult to imagine a healthy system with a lock percentage (averaged over a minute) over 80%. Of course, “normal” depends very much on your use case. A write-heavy database might regularly see >60% lock whereas a read-heavy database may never see anything above 10%. Using MMS, you’ll want to examine trends over time to understand what is normal for your application, establish your baseline, and then track anything that is significantly over that baseline. How is lock percentage measured in MMS? On the MMS hosts page, the lock% chart will show you the percentage of time you are waiting for any particular database lock. You can also choose “global” as the lock to inspect. Oddly enough, doing so does not show the percent time waiting for the global lock. Instead, choosing “global” displays a derived metric that adds the percent of time spent in the global lock (typically a very small number) plus the percent of time locked by the hottest database at the time of measurement, where hottest means “most locked.” Because the data is sampled and combined, it is possible to see values over 100%. What does lock percentage look like in MMS? Here is an example chart:
4 Common Misperceptions about MongoDB
One year ago, in the middle of the pandemic, Dev Ittycheria, the CEO of MongoDB, brought me on as Chief Technology Officer. Frankly, I thought I knew everything about databases and MongoDB. After all, I’d been in the database business for 32 years already. I’d been on MongoDB’s Board of Directors and used the products extensively. And of course I’d done my due diligence, met the leadership team, and analyzed earnings reports and product roadmaps. Even with all that knowledge, this past year as MongoDB’s CTO has taught me that many of my preconceived notions were just plain wrong. This made me wonder how many other people might also have the wrong impression about this company. And this blog is my attempt to set those perceptions straight by sharing my four major revelations of the last year. My first revelation is that MongoDB is not trying to become this generation’s relational database. For years I assumed that MongoDB basically wanted to be a better, more modern version of Oracle when it grew up. In other words, compete with the huge footprint of Oracle and other commercial RDBMSs that have been the industry archetype for so long. I was way off. The whole point of MongoDB is to leave all those forms of archaic, legacy database technology in the historical dust. This was never supposed to be an evolution, but instead a revolution. Our founders not only envisioned the world's fastest and most scalable persistent store, but also one that would be programmed and operated differently. The combination of embedded documents and structures combined with automatic high availability and almost-infinite distribution capability all add up to a fundamentally different way of working with data, building applications, and running those applications in production. Oracle and (SQL*Server, etc) still hang their hats on E.F. Codd’s 51-year old vision of rows and columns. To obtain high availability and distribution of data, you need add ons, options packages, bailing wire and duct tape. And you need a lot of database administrators. Not cheap. Even after all that, you’re still trailing the technological edge. This is how wrong I was. Our durable competitive advantages over these legacy data stores make competing with those products almost irrelevant. We instead focus on the modern needs of modern developers building modern applications. These developers need to create their own competitive advantage through language-native development, reliable deployments to production, and lightning fast iteration. And the world is noticing; just check out the falling slope of Oracle and SQL*Server and the rising slope of MongoDB on the db-engines website. Which brings me to my second revelation: MongoDB was built for developers, by developers. I always knew that MongoDB was exceedingly fast and easy to program against. One time while I was bored in a meeting (yes, it happens here as well!), I built an Atlas database, loaded it with 350MB of data, downloaded and learned our Compass data discovery tool, built-in analytics aggregation pipelines, and our Charts package, and embedded live charts in a web page. This took me all of 19 minutes, end to end. To build something like that for engineers , it just has to be built by engineers , ones that are free to focus on all the rough edges that creep into products as features are added. I was first exposed to software planning and management over 40 years ago, and my LinkedIn profile shows a pretty diverse tour around the industry. Now, one year in, I can emphatically state that engineering and product at MongoDB are both different and better than any company I’ve ever had the privilege to work at. Our executive leadership gives engineering and product broad brushstokes of goals and desired outcomes, and then we work together to come up with detailed roadmaps, updated quarterly, that meet those goals in the way we think best, with no micromanagement. And we’re not afraid of 3-5 year projects, either. For example, multi-cloud was more than three years in the making. Also unlike any other company I’ve been at, we embrace the creation and re-payment of tech debt, rather than sweeping it under the rug. We do this through giving our product and engineering teams huge amounts of context, delivered with candor and openness. And one more essential thing; we have an empowered program management team that improves processes (including killing them) as fast as we create them. In short, we paint the targets for our teams and let them decide how and when to shoot. They even design the arrows and bows. It’s true bottoms-up engineering. Our engineers feel valued and understood. And that, in turn, empowers them to develop features that make our customers feel valued and understood, like a unified query language, or real-time analytics and charting directly in the console, or multi-region/multi-cloud clusters where all the networking cruft is taken care of for you. And this brings me to my third revelation: MongoDB is built for even the most demanding mission critical applications. Fast? Yes. Easy? Of course. But mission-critical? That’s not how I saw MongoDB when I used Version 2 for a massive student data project 10 years ago. While it was the only possible datastore we could have chosen for the amount of data and the speed of ingestion and processing needed, it was pretty hard to set up and use in a 24 x 365 environment. MongoDB had gotten ahead of itself in the early 2010’s. There was a gap between our capabilities and the expectations of the market. And it was painful. Other databases had had more than 30 years to solidify their systems and operations. We’d had five. But with Version 3 we added a new storage engine, full ACID transactions, and search. We built on it with Version 4. And then again with Version 5, released this week at our .Live conference. I knew about all this progress intellectually of course when I joined, but not viscerally. I came to realize that the security, durability, availability, scalability, and operability our platform offers (of course in addition to all the features that developers love too) was ideal for architecting fast-moving enterprise applications. And I found the proof in our customer list. It reads like a Who’s Who of major global banks, retailers, and telecommunications companies, running core systems like payments, IoT applications, content management, and real-time analytics. They use our database, data lake, analytics, search, and mobile products across their entire businesses, in every major cloud, on-premises, and on their laptops. And that leads me to my fourth and final revelation. MongoDB is no longer just a database. Of course, the database is still the core. But MongoDB now provides an enterprise-class, mission-critical application data platform. A cohesive, integrated suite of offerings capable of managing modern data requirements across even the most sprawling digital estates, and scaling to meet the level of any company’s ambition, without sacrificing speed or security. Since the day I was first introduced to MongoDB’s products, I’ve had tremendous respect and admiration for the teams and their work. After all, I’m a developer, first and foremost. And it always felt like they “got” me. But had I known then what I know now, I would have jumped on this train a long time ago. In fact, I might have camped out on their doorstep with my resume in hand. And who knows? Maybe a bunch of people reading this will do just that, and have their own revelations about how fulfilling and exciting it can be to be at a great company, with a great culture, producing great products. I’ll write another letter a year from now, and let you know how it’s going then. In the meantime, please reach out to me here, or at @MarkLovesTech .