[DOCS-5289] How is 2-phase commit done to update config servers? Created: 26/Apr/15  Updated: 24/Feb/16  Due: 15/May/15  Resolved: 04/May/15

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

Type: Bug Priority: Major - P3
Reporter: Mark Callaghan Assignee: Kay Kim (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:
Days since reply: 8 years, 41 weeks, 2 days ago

 Description   

The manual claims that 2-phase commit is used for changes to config servers. A property that 2-phase commit provides is that changes are not visible on any of the servers until all servers have agreed to commit. From reading source in src/mongo/s and src/mongo/s/catalog I don't see how that is provided.

Assuming I am correct, can the manual be updated to explain the behavior that is provided?

What I do see is this pattern for updates which runs in two phases but isn't 2-phase commit:
1) ping all config servers to confirm they are running
2) send write to all config servers
3) collect responses from writes. If all fail, then report that (which is OK). If all succeed then report OK. Else report inconsistent write because write was done to some but not all config servers.

Two questions:
1) Is there code to cleanup from inconsistent write? Cleanup code won't avoid the race from inconsistent reads, but will shrink the window.

2) What is done to avoid inconsistent read after inconsistent write? If this were 2-phase commit then inconsistent read (read after inconsistent write) wouldn't be possible.

Code I read to understand this includes:

  • CatalogManagerLegacy::writeConfigServerDirect
  • ConfigCoordinator::executeBatch
  • SSVRequest::combineResponses
  • DBClientMultiCommand::sendAll


 Comments   
Comment by Githook User [ 04/May/15 ]

Author:

{u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}

Message: DOCS-5289 fix config server write descriptions
Branch: master
https://github.com/mongodb/docs/commit/52905ddedff53675fc140d4259c66b7db2a92e68

Comment by Githook User [ 04/May/15 ]

Author:

{u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}

Message: DOCS-5289 fix config server write descriptions
Branch: v2.6
https://github.com/mongodb/docs/commit/e00c5a854a853fd6c41246a055ca6c97fa10376b

Comment by Githook User [ 04/May/15 ]

Author:

{u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}

Message: DOCS-5289 fix config server write descriptions
Branch: v2.4
https://github.com/mongodb/docs/commit/4c4427c30bf5368110b5d006bd597feceee6dcfe

Comment by Kay Kim (Inactive) [ 01/May/15 ]

Hi Mark – Thanks so much for filing this ticket! Definitely need to update the docs.

Comment by Mark Callaghan [ 26/Apr/15 ]

Claim from manual is at http://docs.mongodb.org/manual/core/sharded-cluster-config-servers/
"Config servers use a two-phase commit to ensure immediate consistency and reliability."

Also spoke about this claim in a mongo-users group discussion. Other operations also write to the config servers, like replacing a shard server.

"Read and Write Operations on Config Servers
MongoDB only writes data to the config server in the following cases:
To create splits in existing chunks. For more information, see chunk splitting.
To migrate a chunk between shards. For more information, see chunk migration."

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