[DOCS-1058] Add description of the correct way for a client to handle replica set reconfiguration Created: 28/Jan/13  Updated: 30/Oct/23  Resolved: 27/Jul/16

Status: Closed
Project: Documentation
Component/s: manual
Affects Version/s: None
Fix Version/s: Server_Docs_20231030

Type: Bug Priority: Major - P3
Reporter: William Zola Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Participants:
Days since reply: 11 years, 3 weeks, 2 days ago

 Description   

When there is a replica set reconfiguration or election, all client connections to that primary are disconnected, and the client-side driver will raise some form of exception. The documentation should specify the correct strategy for a client-side program to take when that happens, covering the following operations:

  • A failed read ( find(), count(), distinct() )
  • A failed insert()
  • A failed update()
  • A failed upsert
  • A failed batch update()
  • A failed update() that includes a $inc/$dec operation
  • A failed FindAndModify()
  • A failed remove()

When a sharded cluster has a shard which is a replica set, and there is a replica set reconfiguration or election, all write operations for documents on that shard will fail until a new primary is elected. All client operations that perform safe writes will recieve a GLE result. The documentation should specify the correct strategy for a client-side program to take when this happens, covering the following operations:

  • A failed insert()
  • A failed update()
  • A failed upsert
  • A failed batch update()
  • A failed update() that includes a $inc/$dec operation
  • A failed FindAndModify()
  • A failed remove()

This is not covered anywhere in the existing general documentation. There should be documentation on a general strategy that applies to all drivers, and then driver-specific examples of how to handle all of the cases listed above.


Generated at Thu Feb 08 07:40:09 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.