|
| 1 | +--- |
| 2 | +title: Comparing Commit Scope Kinds |
| 3 | +navTitle: Comparing Commit Scope Kinds |
| 4 | +deepToC: true |
| 5 | +--- |
| 6 | + |
| 7 | +## Comparing Group Commit and Synchronous Commit |
| 8 | + |
| 9 | +### How Group Commit works |
| 10 | + |
| 11 | +A Group Commit first writes a prepared transaction to local disk and waits till it is replicated to enough nodes and acknowledged by them before then committing it locally. |
| 12 | + |
| 13 | +This also gives resiliency to failure of N nodes, where N is the number of nodes required to acknowledge the transaction. |
| 14 | +Commit scope syntax allows you to specify N as part of the rule. |
| 15 | + |
| 16 | +### How Synchronous Commit works |
| 17 | + |
| 18 | +A Synchronous Commit first commits to the local disk and then waits till the transaction is replicated to N other nodes, as per rules of the commit scope. |
| 19 | +On receiving confirmation that the transaction has been received, applied or made durable, again based on commit scope settings, the client gets a completion acknowledgement of the transaction. |
| 20 | + |
| 21 | +Synchronous commit increases resiliency - it ensures that the transaction is received by more than N nodes before it is acknowledged to caller. |
| 22 | +This makes it resilient to failure of N nodes. |
| 23 | +When conflicts occur, with Synchronous Commit the conflict resolution is always the default async PGD conflict resolution. |
| 24 | + |
| 25 | +### Network partitions and node crashes |
| 26 | + |
| 27 | +Consider a network partition where the originating node is on one side of the partition and the replicas on the other. |
| 28 | +We will look at the state of each kind, before and after connectivity is restored. |
| 29 | + |
| 30 | +#### Group Commit and network partitions |
| 31 | + |
| 32 | +With Group Commit and before restoration, the origin node will have prepared a transaction and wait for confirmations which will not arrive. |
| 33 | +It could timeout and abort the transaction or just wait if the timeout setting is long enough. |
| 34 | +Writes that are recieved by the replicas will be held back if the nodes have prepared transactions from the now-disconnected origin. If there are no prepared transactions, they can continue to recieve writes. |
| 35 | + |
| 36 | +When connectivity is restored, eventually where the origin node aborted the transaction, the prepared transaction on some or all of the replicas will follow in aborting the transaction. |
| 37 | +If there are prepared transactions on all nodes, including the origin, the reconciliation process will commit them. Until that happens, each prepared transaction will be holding locks that will prevent nodes that have resumed writing from overwriting the transaction's writes from other nodes |
| 38 | + |
| 39 | +#### Synchronous Commit and network partitions |
| 40 | + |
| 41 | +With Synchronous Commit and before restoration, the origin node will have committed the transaction and be waiting for confirmations which won't arrive. |
| 42 | +The client may cancel it or it could timeout, but the transaction stays committed on this node. |
| 43 | +On the other side of the partition, it's possible that one of the replicas becomes write leader and that segment of the cluster starts writing to the other nodes. |
| 44 | + |
| 45 | +As the network restores, and if the commit hasn't reached the other nodes, it is possible that the writes on the non-origin side could conflict with the writes from the origin node. The default async conflict resolution may choose one over the other and give errors or potential inconsistencies. |
| 46 | + |
| 47 | +#### Group Commit and node crashes |
| 48 | + |
| 49 | +A similar situation to Group Commit network partitioning occurs with node crashes. The restored origin node may have a number of locally prepared transactions which it will start replicating as it returns. If conflict resolution is set to eager, and there are conflicts, the transaction can be aborted. |
| 50 | + |
| 51 | +#### Synchronous Commit and node crashes |
| 52 | + |
| 53 | +Like Synchronous Commit network partioning, when a restored origin node returns, it may have a number of locally committed transactions. It will re-commence replicating, including those transactions and there may be conflicts which will be resolve through the default async conflict resolution. Again, this may choose one over the other and result in errors or potential inconsistencies. |
| 54 | + |
| 55 | +### Performance |
| 56 | + |
| 57 | +TBD |
| 58 | + |
| 59 | + |
| 60 | +### Overall result |
| 61 | + |
| 62 | +To compare Group Commit and Synchronous Commit at the highest level, we can look at the effect each has on RPO and RTO. |
| 63 | + |
| 64 | +#### RPO |
| 65 | + |
| 66 | +RPO - Recovery Point Objective - is the term for how much data it is acceptable to lose after a disaster. |
| 67 | +With PGD's default async replication, the amount of data that could be lost is based on replication lag. |
| 68 | +A cluster where the other nodes lag by 100MB behind the write-leader could lose 100MB of data in a disaster. |
| 69 | +If that is acceptable, the RPO is therefore 100MB. |
| 70 | + |
| 71 | +With Group Commit configured for MAJORITY or ALL nodes, there is going to be an RPO of 0 in the case of one node failing. That's because the origin node will not have any data which has not been confirmed as replicated on another node. |
| 72 | + |
| 73 | +With Synchronous Commit, even when MAJORITY OR ALL nodes are configured, the originating node may have committed transactions that the other nodes do not have. Since these transactions have not been acknowledged to the client, it can be thought of as an RPO of 0. When the node recovers though, these transactions will show up as committed and the node will have deal with the conflicts as it recovers. |
| 74 | + |
| 75 | +#### RTO |
| 76 | + |
| 77 | +RTO - Recovery Time Objective - is the term for how much time it is acceptable to wait to regain access to data after a disaster. With PGD's default async replication, RTO is 0 but at the cost of data loss. |
| 78 | + |
| 79 | +With Group Commit, getting access to the data can be immediate, but there will be time take once accessible again, to reconcile the prepared transactions. This only stops access to data that is modified by the prepared transactions and may ony be a few seconds. We can say the RTO is close to 0 |
| 80 | + |
| 81 | +With Synchronous Commit, the RTO can be 0 but will require dealing with conflicts later. |
| 82 | + |
0 commit comments