DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Data Engineering
  3. Databases
  4. Understanding durability & write safety in MongoDB

Understanding durability & write safety in MongoDB

Dharshan Rangegowda user avatar by
Dharshan Rangegowda
·
Aug. 26, 14 · Interview
Like (1)
Save
Tweet
Share
9.09K Views

Join the DZone community and get the full member experience.

Join For Free

Durability is the "D" in the "ACID" properties popularized by traditional RDBMS. Durability is the guarantee that written data has been saved and will survive permanently. NoSQL databases like MongoDB give developers fine grained control over the durability of their write calls. This enables developers to choose different durability, safety and performance models for different classes of data. However this also places the burden on the developer to discern and understand the nuances of the different write safety options. In this blog post we will look at the different options for write safety provided in the Java driver. In MongoDB parlance this is called "Write Concern". Write concerns vary from "weak" to "strong". Weak writes concerns can lead to higher throughput but provide less data safety and strong write concerns are vice versa.

The java driver allows you to specify your write safety options using several telescoping constructors. Here is the constructor with all the options:

WriteConcern(int w, int wtimeout, boolean fsync, boolean j, boolean continueOnError)

As you can see this constructor has a lot of options - in order to make it easier for developers "Tags" are provided for common write concern values - Unacknowledged, Acknowledged, Journalled, Fsynced & Replica Acknowledged. Each tag maps to a certain invocation of the above constructor

Unacknowledged

This is the "fire and forget" mode. The MongoDB driver does not attempt to acknowledge the receipt of write operations. E.g. If your mongodb service is down and you are using this mode all the errors are silently ignored and your data is lost. Obviously you should be only using this mode for low value data where write throughput is more important that loss of certain amount of data. This mode can be specified as follows:

new WriteConcern(0) / WriteConcern.UNACKNOWLEDGED

Acknowledged

This is the default write mode for MongoDB. In this mode the MongoDB driver attempts to acknowledge the receipt of write operations on the server.  This will allow the driver to catch any network errors, duplicate keys errors etc. However this does not guarantee that data is saved on the disk. If the mongodb server crashes after acknowledging the write but before committing it to disk the data is lost. This mode can be specified as follows:

new WriteConcern(1) / WriteConcern.ACKNOWLEDGED

Journalled

In this mode the mongodb server acknowledges the write only after committing the data to the journal.  In this server even if the server crashes, on server restart the data is reapplied from the journal. Obviously journalling needs to be enabled for this to work. All production systems should have journalling enabled, our other blog post Should you enable MongoDB journalling? has more details. In a replica set scenario the journalling write concerns only apply to the primary. By default the journal is committed to disk every 100 ms. When you specify a write with the journalled option the journal is committed to disk in 30ms. So if you specify j:true for every write your throughput will be a maximum of 1000/30 = 33.3 writes/sec. If you want better throughput you will need to batch your updates and set j:true for the last update of the batch. This mode can be specified as follows:

WriteConcern( 1, 0, false, true ) / WriteConcern.JOURNALLED

Fsynced

In this mode the mongodb server acknowledges the write only after the write is written to disk. This mode can be specified as follows:

new WriteConcern(true) / WriteConcern.FSYNCED

Replica acknowledged

The previous write safety modes apply only to a single server. When you run replica sets you have the option of controlling on how many replicas your write needs to be written before it is considered successful. E.g. With a write concern of "w:2" the write needs to be written to one primary and atleast one secondary before it is considered successful. This reduces the throughput but gives you better safety. If you are not aware of the number of replicas beforehand you can use the WriteConcern.MAJORITY tag to ensure that the data is saved in the majority of the replicas. This is the safest option in mongodb. If you are going to use this option also make sure to set the "wtimeout" value to indicate how long the command should wait before returning failure

new WriteConcern(2)/ REPLICA_ACKNOWLEDGED
new Majority()/ WriteConcern.MAJORITY

The following tags have been deprecated (or plan to be) - ERRORS_IGNORED, NORMAL, SAFE, FSYNC_SAFE, JOURNAL_SAFE, REPLICAS_SAFE. Please use the newer options instead of these options.

Database MongoDB Durability (database systems) Data (computing)

Published at DZone with permission of Dharshan Rangegowda, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How to Create a Real-Time Scalable Streaming App Using Apache NiFi, Apache Pulsar, and Apache Flink SQL
  • Better Performance and Security by Monitoring Logs, Metrics, and More
  • Differences Between Site Reliability Engineer vs. Software Engineer vs. Cloud Engineer vs. DevOps Engineer
  • How To Check Docker Images for Vulnerabilities

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: