Welcome to the final part in our tour of what’s new in MongoDB 4.4.
In part 1, we announced that MongoDB 4.4 is now generally available and ready for production usage. We also covered enhancements to the MongoDB Query Language (MQL) and drivers.
In part 2, we covered a new, more flexible approach to horizontal scale-out with refinable shard keys and support for compound hashed shard keys. We also covered hedged reads which enable you to maintain more predictable query latency by the MongoDB cluster automatically working around degraded nodes.
If you read those previous posts, you know that 4.4 is the culmination of close to 270,000 hours of engineering time closing over 5,200 tickets. And so today, we will see where those efforts have been applied to database resilience and security.
Reducing user impact of replica set elections following a primary failure or planned maintenance, MongoDB now keeps the caches of secondaries warm by continuously mirroring a subset of reads to them.
Prior to mirrored reads, a secondary may not have had the latest data served by the primary in its memory, resulting in performance degradation immediately after it’s election.
Now the electable secondary replicas are warmed with the most recently accessed data on the primary, enabling the cluster to quickly restore steady-state application performance after an election. By default 1% of all reads are mirrored. You can dial this percentage up – recognizing that this will increase load on the replica set – or you can disable mirrored reads entirely.
Resumable Initial Sync
The initial sync process now automatically resumes after encountering transient network errors, avoiding the process having to start over from the beginning.
This makes it easier and faster to scale-out your database by adding new replicas to the cluster or to recover nodes that have fallen too far behind other members of the replica set.
By default, the secondary tries to resume initial sync for 24 hours – a timeframe that is user-configurable. If the secondary cannot successfully resume the initial sync process in the configured time, it selects a new healthy source node from the replica set and restarts initial sync from the beginning.
Additional Resilience Enhancements in MongoDB 4.4
- Streamed topology changes: When a new primary is elected after a node failure or maintenance event, cluster topology changes are now streamed back to the drivers in real time. As a result, clients can react immediately to cluster state changes, switching open connections as needed, reducing the user impact of primary elections.
- Faster client authentication: By cutting the round trips required to establish secure connections, the network latency clients will see when connecting to a new MongoDB primary is improved by up to 50%. This improvement has been achieved with multiple enhancements including enabling support for TCP Fast Open and removing redundant round trips in the SCRAM handshake. Like Mirrored Reads and Streamed Topology Changes, this also reduces the impact of primary elections.
- Time-Based Oplog Retention: You can now configure MongoDB’s oplog retention period by time, rather than just by its size. This additional flexibility is highly useful to DevOps teams who plan cluster maintenance around specific time windows and need to preserve oplog entries over this period. It is also useful for developers building reactive and event-driven services as it ensures they can resume a change stream from within a specific window of history.
AWS IAM Authentication to MongoDB Atlas
Further simplifying cloud-native security, your applications, containers, and serverless functions can now authenticate to MongoDB Atlas reusing existing regular and temporary Amazon IAM credentials.
Applications provisioned on EC2 instances, Docker containers managed by ECS, or serverless functions running on AWS Lambda can automatically obtain IAM credentials from local metadata, using them to authenticate to MongoDB Atlas, just as you can for any AWS-native service. You no longer have additional configuration files and secrets to manage in the application layer, while also eliminating the need to coordinate secrets deployment, management, and rotation across separate authentication mechanisms.
With support for AWS IAM Authentication, there is less effort on your part to create and maintain a secure database environment. You can build apps faster on Atlas and AWS with the peace of mind and simplicity of a single, trusted security infrastructure.
Additional Security Enhancements for MongoDB 4.4
- TLS 1.3: Starting with 4.4, MongoDB supports TLS 1.3 when used with a compatible OpenSSL library. TLS 1.3 and the accompanying forward secret ciphers can further help meet strict encryption-in-motion requirements. TLS 1.3 has also been backported to all supported MongoDB releases. TLS 1.3 support will be added to Atlas in the next couple of quarters.
- OCSP Stapling: MongoDB can now confirm certificate validity by directly querying the CA over OCSP, eliminating the need to periodically download a Certificate Revocation List, and then restarting the server to refresh its view of certificate status.
- Kerberos Configuration Utility: The new mongokerberos command line utility automatically runs a series of checks for common issues with your MongoDB and Kerberos configuration, providing you with recommendations on the corrective actions needed to successfully deploy your cluster. This utility is available with MongoDB Enterprise Advanced.
Getting Started with MongoDB 4.4
A good place to learn more about all of the features and enhancements in our latest release is to watch the on-demand What’s New in MongoDB 4.4 webinar.
Alternatively, if you want to dive straight in, there are multiple ways you can get going:
- Spin it up 4.4 in the cloud using the fully-managed and global MongoDB Atlas database service.
- Alternatively, download 4.4 and run on your own infrastructure (select 4.4.x under Version).
- Review the documentation in the 4.4 Release Notes.
I’m excited to see where MongoDB 4.4 takes you as you build out your applications!