DOC-12487 Maintain durable writes #3810
Conversation
… topics before adding content for the maintain durability feature.
ggray-cb
requested review from
dave-finlay,
BenHuddleston,
hyunjuV,
shivaniguptasf and
a team
| @@ -108,6 +108,21 @@ and limits the number of metrics to 100. | |||
| Additional information sent by clients at connection time can be found in the logs. | |||
|
|
|||
|
|
|||
| [[new-feature-800-maintain-durable-writes]] | |||
| https://jira.issues.couchbase.com/browse/MB-43068[MB-43068] Optionally Maintain Durable Writes During Single Replica Failovers:: | |||
There was a problem hiding this comment.
I don't think that this title accurately reflects what this does. Things do not behave differently if there is a "Single" failover, or more. "Replica" is somewhat overloaded as we don't fail over replicas. It also does not state what we "Maintain".
Suggest:
"Optionally Maintain Durable Write Availability Without Majority After Failover"
| .Potential Data Loss | ||
| ==== | ||
| Enabling `durabilityImpossibleFallback` degrades the promise that durable writes offer: that Couchbase Server has persisted the data in a way that should survive node failure. | ||
| When enabled for a bucket, this setting makes durable writes to it during a replica failover no more safe from data loss than regular asynchronous writes. |
There was a problem hiding this comment.
Same comment as before on "replica" failover.
|
|
||
| Overrides Couchbase Server's default behavior when it cannot meet a durable write's majority requirement. | ||
| When set to the default `disabled` setting, Couchbase Server reports to clients that a durable write that cannot meet its majority requirement has failed. | ||
| It also rolls back any data changes by the write across all nodes in the cluster. |
There was a problem hiding this comment.
It does not roll back anything. This check is performed before even attempting to contact a replica based on the configuration that the cluster manager passes to the data service.
There was a problem hiding this comment.
@ggray-cb
I've looked at the changes in this PR, and Ben Huddleston's comments. I do not have additional comments.
@BenHuddleston
Thank you for reviewing!
| |=== | ||
|
|
||
| [WARNING] | ||
| ==== | ||
|
|
||
| In consequence of the correspondences listed above, if a bucket is configured with one replica, and a node fails, durable writes are immediately unavailable for any vBucket whose data resides on the failed node. | ||
|
|
||
| As shown by the table, if you configure a bucket with one replica and a node fails, you cannot perform durable write for any vBucket whose data was on the failed node. |
There was a problem hiding this comment.
Can it be changed to:
"... you cannot perform durable write for any vBucket data that was on the failed node."
| [[maintaining-durable-writes]] | ||
| == Maintaining Durable Writes During Single Replica Failovers | ||
|
|
||
| As described in <<#majority>>, a bucket with one replicas must meet a majority requirement of two nodes for a durable write to succeed. |
There was a problem hiding this comment.
Change to:
".. a bucket with one replica must meet..."
| | Durable writes succeed | ||
|
|
||
| | Two nodes fail over | ||
| | Durable writes fail |
There was a problem hiding this comment.
Only to vBuckets on failed over nodes
|
|
||
| | One node fails over | ||
| | Durable writes fail due to lack of majority | ||
| | Durable writes succeed |
There was a problem hiding this comment.
'Durable writes "succeed" without replication' or similar, a new status code is returned
This PR incorporates changes for the Morpheus feature MB-43068 Maintain Durable Write Availability after losing replica
Changes in this PR (links lead to preview site. See this page for username & password)