DOCSP-46893: Destination-only Write-blocking #581
Conversation
✅ Deploy Preview for docs-cluster-to-cluster-sync ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
mayaraman19
changed the title
There was a problem hiding this comment.
This is a great start @mayaraman19 ! I left a couple suggestions for your consideration
There was a problem hiding this comment.
Thanks for taking this tedious ticket 😅 Left some suggestions. Also tagging @mvankeulen94 for input
source/includes/live-upgrade.rst
Outdated
| restarting data synchronization operations from the beginning. You can | ||
| only live upgrade to ``mongosync`` 1.7.3 or later from ``mongosync`` | ||
| 1.7.2 or later. | ||
| 1.7.2 or later. You cannot live upgrade to ``mongosync`` 1.11. |
There was a problem hiding this comment.
I think it might be clearer to have a small table to lay out what upgrades are supported. This could be similar to what we have for our server versions compatibility matrix; https://www.mongodb.com/docs/cluster-to-cluster-sync/current/reference/supported-server-version/#synchronize-data-between-clusters-with-different-mongodb-server-major-versions
There was a problem hiding this comment.
I ended up removing the sentence on 1.7.2 since, unless I'm misunderstanding, it's not adding any additional limitations?
There was a problem hiding this comment.
The upgrade paths are a little complicated - this table lays out what we support. We might want to still document that we support 1.7.3 --> 1.10.0 for example. @mvankeulen94 do you think including a table like this is necessary? Or are we fine with just saying that we don't support live upgrade to 1.11
There was a problem hiding this comment.
thanks @ajayvijayakumar123 , I think we can keep it as saying we don't support live upgrade to 1.11 for simplicity. The table here may imply that we have individual support schedules for these incremental versions when really it's just the latest version that we support.
There was a problem hiding this comment.
sounds good, I'm good with what we have in this section then.
Starting in mongosync 1.7.0, you can upgrade mongosync without restarting data synchronization operations from the beginning.
Important: mongosync does not support upgrades to version 1.11.
I think it's a little conflicting to say that we support live upgrade but don't currently support live upgrade to 1.11. I'm fine with this though (since we might start supporting live upgrade to 1.12)
source/includes/live-upgrade.rst
Outdated
| restarting data synchronization operations from the beginning. You can | ||
| only live upgrade to ``mongosync`` 1.7.3 or later from ``mongosync`` | ||
| 1.7.2 or later. | ||
| 1.7.2 or later. You cannot live upgrade to ``mongosync`` 1.11. |
There was a problem hiding this comment.
The upgrade paths are a little complicated - this table lays out what we support. We might want to still document that we support 1.7.3 --> 1.10.0 for example. @mvankeulen94 do you think including a table like this is necessary? Or are we fine with just saying that we don't support live upgrade to 1.11
| - You can't enable the ``enableUserWriteBlocking`` option in the ``/start`` | ||
| request. Ensure that no writes are made to the source or destination cluster | ||
| during the migration. | ||
| request, so dual write-blocking is not supported. Destination-only |
There was a problem hiding this comment.
can we keep the note that users should ensure that no writes are made to the source cluster after commit has been issued?
| required permissions on the source and destination clusters. The | ||
| permissions vary depending on your environment and if you want to run a | ||
| write-blocking or reverse sync. | ||
| dual write-blocking or reverse sync. |
There was a problem hiding this comment.
'if you want to run a dual write-blocking' -> 'if you want to modify write-blocking settings or use reverse sync'
There was a problem hiding this comment.
yup this sounds good
| - On the destination cluster during sync. | ||
| - On the source cluster when ``commit`` is received. | ||
| You can enable dual write-blocking, which blocks | ||
| writes on both the source and destination clusters. |
There was a problem hiding this comment.
can we delete ", which blocks writes on both the source and destination clusters. " from this sentence in favor of the explanations below?
|
|
||
| - On the destination cluster during sync. | ||
| - On the source cluster when ``commit`` is received. | ||
| You can enable dual write-blocking, which blocks |
There was a problem hiding this comment.
'You can enable' -> 'You also have the option to enable'
source/includes/live-upgrade.rst
Outdated
| restarting data synchronization operations from the beginning. You can | ||
| only live upgrade to ``mongosync`` 1.7.3 or later from ``mongosync`` | ||
| 1.7.2 or later. | ||
| 1.7.2 or later. |
There was a problem hiding this comment.
can we link to the 1.11 limitation here?
source/reference/cutover-process.txt
Outdated
| - If you start ``mongosync`` with ``enableUserWriteBlocking`` set | ||
| to ``"destinationOnly"``, ``mongosync`` only blocks writes on the | ||
| destination and unblocks them right before ``canWrite`` is | ||
| set to ``true``. |
There was a problem hiding this comment.
can we add a note that this is the default?
* initial commit.. * little fix * changes * release notes * feedback * little changes * feedback * table first draft * typo * de-modify * small fix * feedback
5 participants
https://jira.mongodb.org/browse/DOCSP-46893
Document: https://docs.google.com/document/d/1aGSzqekj5-ui8PZnem1ND_SV7__gYNfn64ROtELD4l4/edit?tab=t.0
Staging (search for "block" to narrow down changed sections):