MongoDB Read/Write Concern and Read preference

Write Concern in MongoDB

Write concern in MongoDB controls how write operations are confirmed within replica sets, ensuring data is written to a specified number of nodes before acknowledging the operation. Key components include:

{ w: <value>, j: <boolean>, wtimeout: <number> }

w: Number of replica set members that must acknowledge the write, with options ranging from none (0) for highest performance to 'majority' for default durability since MongoDB 5.0.

j: Boolean indicating if the operation must be written to the on-disk journal.

wtimeout: Time limit in milliseconds to achieve the specified acknowledgement level, after which an error is returned.

Since MongoDB 4.4, global default write concerns can be set, and from MongoDB 5.0, 'majority' is the default setting unless arbiters adjust it to { w: 1 }. The choice of write concern affects performance (lower values increase speed but risk durability) and durability (higher values ensure data safety but increase latency).

Set Global Default Read and Write Concerns

db.adminCommand({
  "setDefaultRWConcern" : 1,
  "defaultWriteConcern" : {
    "w" : 2
  },
  "defaultReadConcern" : { "level" : "majority" }
})        

Significance of Write Concern

The selection of a write concern level directly impacts data durability and the performance of write operations:

• Performance: Opting for a lower write concern, like { w: 0 }, can accelerate write operations by minimising latency, but this comes at the expense of data reliability.
• Durability: Choosing a higher write concern, such as { w: "majority" }, enhances data durability by ensuring that the majority of nodes confirm the write, though this may slightly increase the latency of operations.

Read Preferences in MongoDB

Read preferences dictate how read operations are routed within a replica set, aiming to balance load and enhance availability. Five modes are supported:

• primary: Default, directs reads to the primary member.
• primaryPreferred: Fallback to secondary if primary is unavailable.
• secondary: Directs all reads to secondary members.
• secondaryPreferred: Reads go to secondary unless unavailable.
• nearest: Chooses the member with the lowest latency.

Additional options include tag sets for targeted reads and max staleness to avoid overly stale data. The choice of read preference impacts both system performance and data availability, especially during primary downtime.

Significance of Read Preference

Selecting a read preference affects both the efficiency and availability of data:

• Performance: Allocating read operations to secondary members can improve system performance by alleviating the burden on the primary node.
• Availability: If the primary node is unavailable, read operations can continue to be handled by secondary nodes, provided the selected read preference mode supports this functionality.

Read Concerns in MongoDB

Read concern settings ensure data consistency and isolation in read operations. Supported levels are:

• local: Returns the most recent data available, default setting.
• available: Provides data with minimal latency without consistency guarantees.
• majority: Ensures data has been acknowledged by the majority, enhancing consistency.
• linearizable: Offers the highest consistency level.
• snapshot: Provides a consistent view from a specific point in time.

Higher read concern levels improve consistency and isolation, impacting the overall system performance and data integrity.

Significance of Read Concern

The selection of read concern settings plays a crucial role in determining data consistency and isolation:

• ?Consistency: Elevated read concern levels, such as "majority" or "linearizable," guarantee that the data retrieved is consistent across all members of the replica set.
• Isolation: Utilizing the "snapshot" read concern level allows transactions to be isolated from simultaneous write activities, maintaining a consistent snapshot of the data throughout the transaction.