|
| 1 | +.. _about-mongosync: |
| 2 | + |
| 3 | +==================== |
| 4 | +About ``mongosync`` |
| 5 | +==================== |
| 6 | + |
| 7 | +.. default-domain:: mongodb |
| 8 | + |
| 9 | +.. contents:: On this page |
| 10 | + :local: |
| 11 | + :backlinks: none |
| 12 | + :depth: 2 |
| 13 | + :class: singlecol |
| 14 | + |
| 15 | +The ``mongosync`` binary is the primary process used in {+c2c-product-name+}. |
| 16 | +``mongosync`` migrates data from a source cluster to a destination cluster and |
| 17 | +keeps the clusters in continuous sync until you |
| 18 | +:ref:`finalize <c2c-about-finalizing>` the sync. |
| 19 | + |
| 20 | +You can use ``mongosync`` to create |
| 21 | +dedicated analytics, development, or testing clusters that mirror your |
| 22 | +production environment. |
| 23 | + |
| 24 | +``mongosync`` keeps track of its current actions through |
| 25 | +:ref:`states <c2c-states>`. ``mongosync`` enters different states depending on |
| 26 | +the requests it receives. The current ``mongosync`` state determines which API |
| 27 | +operations you can run. |
| 28 | + |
| 29 | +.. include:: /includes/fact-state-transitions.rst |
| 30 | + |
| 31 | +To view the current state of ``mongosync``, use the :ref:`/progress |
| 32 | +<c2c-api-progress>` endpoint. |
| 33 | + |
| 34 | +The following diagram illustrates the relationship between ``mongosync`` states |
| 35 | +and API operations: |
| 36 | + |
| 37 | +.. figure:: /images/mongosync.drawio.bakedsvg.svg |
| 38 | + :alt: Diagram of relationship between ``mongosync`` states and API operations |
| 39 | + :figwidth: 600px |
| 40 | + |
| 41 | +Details |
| 42 | +------- |
| 43 | + |
| 44 | +Connect Source and Destination Clusters |
| 45 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 46 | + |
| 47 | +You must create an initial connection to the source and destination |
| 48 | +clusters before ``mongosync`` can start to sync data. For more information, see |
| 49 | +:ref:`c2c-connecting`. |
| 50 | + |
| 51 | +When ``mongosync`` connects to the source and destination clusters, the |
| 52 | +synchronization process enters the :ref:`IDLE <c2c-state-idle>` state. |
| 53 | + |
| 54 | +Start Sync |
| 55 | +~~~~~~~~~~ |
| 56 | + |
| 57 | +To start the synchronization process, call the :ref:`start <c2c-api-start>` |
| 58 | +endpoint. |
| 59 | + |
| 60 | +The ``start`` endpoint begins the ``RUNNING`` state, which is when ``mongosync`` |
| 61 | +syncs data from the source cluster to the destination cluster. If you |
| 62 | +make subsequent writes to the source cluster, ``mongosync`` applies the |
| 63 | +operations to the destination cluster. |
| 64 | + |
| 65 | +For every source collection that syncs, |
| 66 | +``mongosync`` creates a corresponding collection on the destination. |
| 67 | + |
| 68 | +``mongosync`` temporarily alters some of the replicated collection |
| 69 | +characteristics in the destination cluster. It changes these destination cluster |
| 70 | +characteristics back to the source cluster characteristics during the ``COMMIT`` |
| 71 | +state. For more information, see |
| 72 | +:ref:`Collection Characteristic Changes <c2c-collection-changes>`. |
| 73 | + |
| 74 | +The ``RUNNING`` state includes two phases: |
| 75 | + |
| 76 | +- :ref:`Collection copy <c2c-collection-copy>` |
| 77 | + |
| 78 | +- :ref:`Change event application <c2c-cea>` |
| 79 | + |
| 80 | +.. _c2c-collection-copy: |
| 81 | + |
| 82 | +Collection Copy |
| 83 | +''''''''''''''' |
| 84 | + |
| 85 | +During the collection copy phase, ``mongosync`` executes the initial data |
| 86 | +transfer from the source cluster to the destination |
| 87 | +cluster. ``mongosync`` performs this data transfer by splitting the |
| 88 | +source collections into partitions and copying the partitions to their |
| 89 | +corresponding destination collections. |
| 90 | + |
| 91 | +.. _c2c-cea: |
| 92 | + |
| 93 | +Change Event Application |
| 94 | +'''''''''''''''''''''''' |
| 95 | + |
| 96 | +The change event application (CEA) phase starts after the collection copy phase |
| 97 | +ends. |
| 98 | + |
| 99 | +During the CEA phase, ``mongosync`` continuously |
| 100 | +updates the destination cluster when you make changes to the source cluster. |
| 101 | + |
| 102 | +To make continuous updates to the destination cluster, ``mongosync`` opens a |
| 103 | +:ref:`change stream <changeStreams>` on the source cluster and applies the |
| 104 | +:ref:`change events <change-events>` it receives to the destination cluster. |
| 105 | + |
| 106 | +When the CEA phase begins, ``mongosync`` applies the change events |
| 107 | +that are received during the collection copy phase before processing the |
| 108 | +events that are received during the CEA phase. |
| 109 | + |
| 110 | +Pause Sync |
| 111 | +~~~~~~~~~~ |
| 112 | + |
| 113 | +To pause the sync process and enter the :ref:`PAUSED <c2c-state-paused>` state, |
| 114 | +call the :ref:`pause <c2c-api-pause>` endpoint. |
| 115 | + |
| 116 | +To resume a paused sync process and return ``mongosync`` to the |
| 117 | +``RUNNING`` state, call the :ref:`resume <c2c-api-resume>` endpoint. |
| 118 | + |
| 119 | +.. _c2c-about-finalizing: |
| 120 | + |
| 121 | +Finalize Sync |
| 122 | +~~~~~~~~~~~~~ |
| 123 | + |
| 124 | +To finalize the sync between the source and destination clusters, |
| 125 | +call the :ref:`commit <c2c-api-commit>` endpoint. |
| 126 | + |
| 127 | +The ``commit`` endpoint starts the :ref:`COMMITTING <c2c-state-committing>` |
| 128 | +state, which is when ``mongosync`` stops continuous sync between the source and |
| 129 | +destination clusters. |
| 130 | + |
| 131 | +When the ``COMMITTING`` state begins, ``mongosync`` retrieves the |
| 132 | +commit timestamp, which is the time of the most recent operation on the source |
| 133 | +cluster. |
| 134 | + |
| 135 | +If there are no errors, ``mongosync`` sends a success message and exits CEA by |
| 136 | +processing events up until the commit timestamp. ``mongosync`` also restores |
| 137 | +collection characteristics that ``mongosync`` temporarily alters during |
| 138 | +synchronization. |
| 139 | + |
| 140 | +When the above process is completed, ``mongosync`` enters the |
| 141 | +:ref:`COMMITTED <c2c-state-committed>` state. The ``COMMITTED`` state indicates |
| 142 | +that the :ref:`cutover process <c2c-cutover-process>` is finished. |
| 143 | + |
| 144 | +.. _c2c-about-reversing: |
| 145 | + |
| 146 | +Reverse Sync |
| 147 | +~~~~~~~~~~~~ |
| 148 | + |
| 149 | +To reverse the direction of a committed sync operation, call the |
| 150 | +:ref:`reverse <c2c-api-reverse>` endpoint. |
| 151 | + |
| 152 | +The ``reverse`` endpoint starts the :ref:`REVERSING <c2c-state-reversing>` |
| 153 | +state. ``mongosync`` swaps the source and destination clusters and resumes |
| 154 | +applying change events. |
| 155 | + |
| 156 | +If the reverse sync is successful, ``mongosync`` enters the ``RUNNING`` state. |
| 157 | +The synchronization continues in the reverse direction from the original |
| 158 | +sync job. |
| 159 | + |
| 160 | +Learn More |
| 161 | +---------- |
| 162 | + |
| 163 | +To learn more about ``mongosync``, see: |
| 164 | + |
| 165 | +- :ref:`mongosync <c2c-mongosync>` |
| 166 | +- :ref:`mongosync States <c2c-states>` |
0 commit comments