[SERVER-1456] Two-Phase Commit Created: 21/Jul/10  Updated: 20/Jun/12  Resolved: 21/Jul/10

Status: Closed
Project: Core Server
Component/s: Internal Client, Replication, Sharding
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Leon Mergen Assignee: Eliot Horowitz (Inactive)
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:

 Description   

In addition to a SyncClusterConnection, I suggest implementing TwoPhaseCommit connection (possibly long-term).

The SyncClusterConnection is a nice idea, but doesn't scale in practice: when you have lots of clients performing writes via a SyncClusterConnection, you end up flushing your mongo nodes very often. Each server only has a limited amount of flushes it can do per second, which reduces performance a lot.

Another way to achieve some sort of durability/consistency guarantee with multiple servers is two-phase commit. The flow would be as follows:

  • client issues a "request update" command to all servers;
  • all nodes verify this write wouldn't introduce any errors ("Update-if-Current" comes to mind);
  • client receives verification from all nodes and send commit to all nodes;
  • if some nodes fail during commit, eventual consistency can be used.

This does require some sort of row-level locking mechanism within the core servers, so multiple updates for the same objects will be synchronized between servers. However, this would scale very well with many clients talking to a single replication set.



 Comments   
Comment by auto [ 20/Jun/12 ]

Author:

{u'date': u'2012-06-18T16:52:22-07:00', u'name': u'Spencer T Brody', u'email': u'spencer@10gen.com'}

Message: Always use internal credetials when connecting to the config servers. SERVER-1456
Branch: master
https://github.com/mongodb/mongo/commit/2a2689e7a5823291b125fabddf981ca87ef9a3f0

Comment by Eliot Horowitz (Inactive) [ 21/Jul/10 ]

This is not something we're planning on enhancing at any point.
SyncClusterConnection is only designed for internal use.

For distributed durability, you should use the replication w=N feature.

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