MongoDB 3.0.5-rc2 is released

MongoDB
July 23, 2015

MongoDB 3.0.5-rc2 is out and is ready for testing. This is a release candidate containing only fixes since 3.0.4. The next stable release 3.0.5 will be a recommended upgrade for all 3.0 users.

Fixed in this release:

  • SERVER-17254 WT: drop collection while concurrent oplog tailing may greatly reduce throughput
  • SERVER-17689 Server crash during initial replication sync
  • SERVER-18875 Oplog performance on WT degrades over time after accumulation of deleted items
  • SERVER-18902 Retrieval of large documents slower on WiredTiger than MMAPv1
  • SERVER-18926 Full text search extremely slow and uses a lot of memory under WiredTiger
  • SERVER-19255 Listener::waitUntilListening may return before listening has started
  • SERVER-19489 Assertion failure and segfault in WorkingSet::free in 3.0.5-rc0
  • SERVER-19513 Truncating a capped collection may not unindex deleted documents in WiredTiger

3.0 Release Notes | Downloads | All Issues

As always, please let us know of any issues.

– The MongoDB Team

← Previous

MongoDB Pluggable Storage Engines: State of the Union, Storage Engine Summit

Back at the inaugural MongoDB World user conference in June 2014, our co-founder and CTO, Eliot Horowitz, announced that MongoDB would incorporate a storage engine API into the next major version of the database – MongoDB 3.0 . The goal of the storage engine API was to make it fast and easy for MongoDB and the community to build new pluggable storage engines that allow the database to be extended with new capabilities, and to be configured for specific hardware architectures. 12 months on, following both the MongoDB 3.0 release and the MongoDB World 2015 conference (keynotes and sessions from the event are now online ), we hosted our first Storage Engine Summit, bringing together storage engine developers from across both MongoDB and the community. The summit’s goals were to: Review the status of current MongoDB storage engines Provide developers with visibility into the roadmap for both the storage engine API itself, and the database roadmap Collect storage engine developer’s feature requirements Develop best practices for community collaboration and development of the API In this blog, I’ll provide an overview of the progress happening around MongoDB storage engines, and key outcomes from the summit. Why Pluggable Storage Engines? First, a bit of background. With users building increasingly complex data-driven apps, there is no longer a "one size fits all" database storage technology capable of powering every type of application built by the business. Modern applications need to support a variety of workloads with different access patterns and price/performance profiles – from low latency, in-memory read and write applications, to real-time analytics, to highly compressed "active" archives. The storage engine API allows MongoDB to be configured with a choice of storage engines, each configured for specific workloads. This “pluggable” approach significantly reduces developer and operational complexity compared to running multiple databases. Now users can leverage the same MongoDB query language, data model, scaling, security and operational tooling across different applications, each powered by pluggable MongoDB storage engines that are optimized for specific workloads. So what progress has been made so far? Quite a bit, and in a very short time frame. MongoDB 3.0 shipped with two supported storage engines: The default MMAPv1 engine, an improved version of the engine used in prior MongoDB releases, enhanced with collection level concurrency control. The new WiredTiger storage engine. For many applications, WiredTiger's more granular concurrency control and native compression provide significant benefits in terms of lower storage costs, greater hardware utilization, higher throughput, and more predictable performance. Benchmarks show MongoDB 3.0 configured with WiredTiger delivers 7-10x higher performance than MongoDB 2.6 using the original MMAP storage engine. In addition, storage compression rates of up to 80% are fairly common. To demonstrate how developers could start to innovate, several experimental engines also shipped with MongoDB 3.0, including the in-memory and /dev/null storage engines. Beyond the walls of MongoDB engineering teams, the community also started releasing its own engines. Within one quarter of 3.0’s availability: Facebook released mongo-rocks , a MongoDB storage engine based on its RocksDB embedded database project. Mongo-rocks is already in use for some production workloads at Facebook’s Parse mobile backend-as-a-service division, which today supports over 500,000 applications on MongoDB. Percona published a release candidate of its TokuMXse storage engine. What’s Next? Held in our New York offices on June 4th, the summit drew diverse representation from the community. Some attendees already had storage engines for MongoDB; some were in varying stages of development; while others were just starting to evaluate the opportunities. Attendees included: Facebook, who already has RocksDB Percona, readying TokuMXse SanDisk, developing an engine optimized for its Fusion-io SSD storage devices Deep , who have developed a MySQL storage engine featuring an adaptive database kernel 8k Data , currently building a JSON database on top of Postgres There was also representation from MongoDB’s storage engine teams, who discussed additional engines planned for the MongoDB 3.2 timeframe, including: An encrypted storage engine protecting data at-rest, with keys secured by the industry standard Key Management Interoperability Protocol (KMIP). At-rest encryption is especially critical for regulated industries such as healthcare, financial services, retailers and certain government agencies. And with so many high profile breaches of sensitive data at high profile companies over the past five years, increasingly all data is being encrypted. An in-memory engine designed to serve ultra high-throughput, low-latency apps typical in finance, ad-tech, gaming, real-time analytics, session management and general cache use cases. A new option for insert only workloads (e.g., streaming IoT sensor data, log file analysis, social media feed ingestion), based on the LSM option in the WiredTiger storage engine. Much more than just sharing feeds and speeds, the intent of the storage engine summit was to bring together developers to share best practices in how to collaborate: Mark Callaghan, one of our esteemed MongoDB masters and member of Facebook’s technical staff, gave great insight into his experiences working as part of the MySQL storage engine community. He shared the good, the bad, and the downright ugly. Dr Michael Cahill, co-founder of WiredTiger, and now Director of Storage Engineering at MongoDB, shared his experiences implementing the WiredTiger storage engine, both while outside MongoDB, and within the company. Mathias Stearn & Geert Bosch, senior database kernel engineers, provided a deep dive walkthrough into the storage engine API implementation, and plans for the future. This gave all those present an opportunity to provide feedback on issues they had faced, solutions to move forward, and future requirements to shape the evolution of the API All of the talks gave a great frame-of-reference in how the MongoDB storage engine community should move forward. So what did the summit achieve in one short day? The formation of a focused community committed to building MongoDB storage engines. The establishment of a framework for communications, contributions, collaboration & future summits. It connected engine developers directly with MongoDB engineers designing & implementing API functionality. Not only has feedback already helped evolve the storage engine API in the current 3.0 release, additional enhancements will be reflected in MongoDB 3.2’s API. Wrapping Up Huge progress has been made, and the MongoDB storage engine ecosystem is continuing to grow. This diversity helps MongoDB users solve new classes of use cases with a single database framework. The storage engine API helps developers innovate faster. And it helps storage engine partners get their technology in front of a whole new audience. To learn more of the promise of multiple storage engines, download the What’s New in MongoDB 3.0 guide. What’s New in MongoDB 3.0

July 22, 2015
Next →

MongoDB Database Observability: Integrating with Monitoring Tools

This post is the final in a three-part series on leveraging database observability. Welcome back to our series on Leveraging Database Observability! Our previous post showcased a real-world use case highlighting how MongoDB Atlas’s observability tools effectively tackle database performance challenges. Whether you’re a developer, DBA, or DevOps engineer, our mission is to empower you to harness the full potential of your data through our observability suite . Integrating Atlas metrics with your central enterprise observability tools can simplify your operations. By seamlessly working with popular observability tools, our approach helps teams streamline workflows and enhance visibility across systems. Integrating MongoDB Atlas with third-party monitoring tools MongoDB’s developer data platform combines all essential data services for building modern applications within a unified experience. Our purpose-built observability tools for Atlas environments offer automatic monitoring and optimization, guiding diagnostics tailored specifically for MongoDB. Additionally, we extend Atlas metrics into your existing enterprise observability stack, enabling seamless integration without replacing your current tools. This creates a consolidated, single-pane view that unifies Atlas telemetry with other tech and application metrics, ensuring comprehensive visibility into both database and full-stack performance. This integration empowers you to monitor, receive alerts, and make data-driven decisions within your existing workflows, driving greater efficiency. Below is a quick guide to modifying integration settings through the Atlas UI and the popular integrations we support: Navigate to the Project Integrations page in Atlas. Choose the organization and project you want to configure from the navigation bar. On the Project Integrations page, select the third-party services you’d like to integrate. Configure the chosen services with the required API keys and regions. Critical integrations for your observability platform With Atlas’s Datadog and Prometheus integrations, you can send critical MongoDB metrics to these platforms, empowering detailed, real-time monitoring. Through Datadog , you can track database operation counts, query efficiency, and resource usage, ideal for pinpointing bottlenecks and managing resources. Similarly, Prometheus enables you to monitor essential metrics like query times, connection rates, and memory usage, supporting flexible tracking of database health and performance. Both integrations facilitate proactive detection of issues, alert configuration for resource thresholds, and a cohesive view of Atlas data when visualized in Grafana. Atlas’s integration with PagerDuty streamlines incident management by sending metrics like performance alerts, billing anomalies, and security events directly to PagerDuty. This integration records incidents automatically, notifies teams upon alerts, and supports two-way syncing, ensuring resolved alerts in Atlas are reflected in PagerDuty. It enables efficient incident response and resource allocation to maintain system stability. With Atlas integrations for Microsoft Teams and Slack, you can route key metrics—such as query latency, disk usage, and throughput—to these channels for timely updates. Teams can use these insights for real-time performance monitoring, incident response, and collaboration. Notifications through these platforms ensure your team stays informed on database performance, storage health, and user activity changes as they occur. Use case: Centralized observability with MongoDB Atlas, Datadog, and Slack Let’s walk through a hypothetical scenario for ShopSmart, an e-commerce company that leverages MongoDB Atlas to manage its product catalog and customer data. As traffic surges, the DevOps team faces challenges in monitoring application performance and database health effectively. To tackle these challenges, the team leverages MongoDB Atlas’ integration with Datadog and Slack, creating a powerful observability ecosystem. Integrating MongoDB Atlas with Datadog: The team pushes key MongoDB Atlas metrics into Datadog, such as query performance, connection counts, and Atlas Vector Search metrics. With Datadog, they can visualize these metrics and correlate overall MongoDB performance with their other applications. Out-of-the-box monitors and dedicated dashboards allow the team to track metrics like throughput, average read/write latency, and current connections. This visibility helps pinpoint bottlenecks in real time, ensuring optimal database performance and improving overall application responsiveness. Setting up alerts in Datadog: The team configures alerts for critical metrics like high query latency and increased error rates. When thresholds are breached, Datadog instantly notifies the team. This proactive approach allows the team to address potential performance issues before they impact customers. Integrating Datadog with Slack: To ensure fast communication, alerts are sent directly to the dedicated Slack channel, “ShopSmart-Alerts.” This integration fosters seamless collaboration, enabling the team to discuss and resolve issues in real-time. With these integrations, ShopSmart’s engineering team can monitor performance quickly and address issues efficiently. The unified observability approach enhances operational efficiency, improves the customer experience, and supports ShopSmart’s competitive edge in the e-commerce industry. By leveraging MongoDB Atlas, Datadog, and Slack, the team ensures scalable performance and drives continuous innovation. Conclusion MongoDB Atlas empowers developers and organizations to achieve unparalleled observability and control over their database environments. By seamlessly integrating with central enterprise observability tools, Atlas enhances your ability to monitor performance metrics and ensures you can do so within your existing workflows. This means you can focus on building modern applications confidently, knowing you have the insights and alerts necessary to maintain optimal performance. Embrace the power of MongoDB Atlas and transform your approach to database management—because your applications can thrive when your data is observable. And that wraps up our Leveraging Database Observability series! We hope you learned something new and found value in these discussions. Sign up for MongoDB Atlas , our cloud database service, to see database observability in action. To dive deeper and expand your knowledge, check out this learning byte for more insights on the MongoDB observability suite and how it can enhance your database performance.

November 14, 2024