Skip to content

DOCS-41102 added code snippets cutover page #341

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jul 10, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions source/quickstart.txt
Original file line number Diff line number Diff line change
Expand Up @@ -247,6 +247,15 @@ documentation provides details on using the following endpoints:
* - :ref:`c2c-api-reverse`
- Reverses the direction of a committed sync operation.

Finalize Cutover Process
------------------------
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that we've fixed this, could you replace the build log link in the PR description? Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry about that, just fixed!


You can finalize a migration and transfer your application
workload from the source to the destination cluster using the
``mongosync`` cutover process.

For more information, see :ref:`c2c-cutover-process`.

One-Time Sync
-------------

Expand Down
124 changes: 117 additions & 7 deletions source/reference/cutover-process.txt
Original file line number Diff line number Diff line change
Expand Up @@ -36,12 +36,29 @@ Steps
Ensure that the ``mongosync`` process status indicates the
following values:

- ``canCommit`` is ``true``.

- ``lagTimeSeconds`` is small (near ``0``).

If ``lagTimeSeconds`` isn't close to ``0`` when the cutover
starts, cutover might take a long time.

- ``canCommit`` is ``true``.
The following example returns the status of the synchronization process.

Request
~~~~~~~

.. literalinclude:: /includes/api/requests/progress.sh
:language: shell

Response
~~~~~~~~

.. literalinclude:: /includes/api/responses/progress.json
:language: json
:copyable: false
:emphasize-lines: 5, 8


.. step:: Stop any write operations to the synced collections on the source.

Expand All @@ -50,8 +67,16 @@ Steps
the entire source cluster during the commit (step 4) for you.
- If you didn't start ``mongosync`` with
``enableUserWriteBlocking``, ensure that writes are disabled.
For example, run the ``setUserWriteBlockMode`` command on the
source cluster.
For example, run the :dbcommand:`setUserWriteBlockMode` command on the
source cluster:

.. code-block:: javascript

db.adminCommand( {
setUserWriteBlockMode: 1,
global: true
} )

- If ``mongosync`` uses filtered sync, it's not necessary to
disable writes to the entire source cluster. But you must ensure
that write operations are stopped for the collections included
Expand All @@ -63,19 +88,67 @@ Steps
migration, you must issue a commit request for each ``mongosync``
instance.

Request
~~~~~~~~

.. literalinclude:: /includes/api/requests/commit.sh
:language: shell

Response
~~~~~~~~

.. literalinclude:: /includes/api/responses/success.json
:language: json
:copyable: false

.. note::

Ensure that the ``mongosync`` process response for the
``commit`` request indicates that the ``mongosync`` state is
``COMMITTING`` or ``COMMITTED``, which is the correct
``mongosync`` state when you send a ``commit`` request.
After you submit a ``commit`` request, call the ``progress`` endpoint
to ensure that the ``mongosync`` state is ``COMMITTING`` or
``COMMITTED``.

.. step:: Wait until you can perform writes on the destination cluster.

Call the ``progress`` endpoint to determine if ``canWrite`` is
``true``. If ``canWrite`` is ``false``, wait until ``progress``
shows ``canWrite`` is ``true``.

Request
~~~~~~~

.. literalinclude:: /includes/api/requests/progress.sh
:language: shell

Response
~~~~~~~~

.. code-block:: json
:emphasize-lines: 6
:copyable: false

{
"progress":
{
"state":"COMMITTED",
"canCommit":true,
"canWrite":true,
"info":"change event application",
"lagTimeSeconds":0,
"collectionCopy":
{
"estimatedTotalBytes":694,
"estimatedCopiedBytes":694
},
"directionMapping":
{
"Source":"cluster0: localhost:27017",
"Destination":"cluster1: localhost:27018"
}
},
"success": true
}


.. step:: Verify data transfer.

Verify the successful sync of data from the source to the
Expand All @@ -102,6 +175,43 @@ Steps
``mongosync`` state is ``COMMITTED``, the cutover process is
complete.

Request
~~~~~~~

.. literalinclude:: /includes/api/requests/progress.sh
:language: shell

Response
~~~~~~~~

.. code-block:: json
:emphasize-lines: 4
:copyable: false

{
"progress":
{
"state":"COMMITTED",
"canCommit":true,
"canWrite":false,
"info":"change event application",
"lagTimeSeconds":0,
"collectionCopy":
{
"estimatedTotalBytes":694,
"estimatedCopiedBytes":694
},
"directionMapping":
{
"Source":"cluster0: localhost:27017",
"Destination":"cluster1: localhost:27018"
}
},
"success": true
}



Learn More
----------

Expand Down