@@ -16,101 +16,128 @@ Verify Data Transfer
1616 :depth: 2
1717 :class: singlecol
1818
19- When :ref:`mongosync <c2c-mongosync>` has fully committed, verify the
20- successful transfer of your data before you switch your application to using
21- the destination cluster. You can verify your data transfer using document
22- counts, hash comparison, document comparison, or the Migration Verifier.
23-
24- Use Cases
25- ---------
26-
27- You should verify your data after every sync. This is important in
28- cases where you plan to move your application load from the source to the
29- destination cluster.
30-
31- Verification methods:
32-
33- - :ref:`c2c-verify-with-doc-counts`
34-
35- - :ref:`c2c-verify-with-hash-comp`
36-
37- - :ref:`c2c-verify-with-doc-comp`
38-
39- - :ref:`c2c-verify-with-verifier`
40-
41- The specific method you use to verify your data depends on your application
42- workload and the complexity of the data.
19+ Before you switch your application load from the source cluster
20+ to the destination cluster, you should verify that the migration
21+ was successful.
4322
4423.. _c2c-verify-method:
4524
4625Tasks
47- -------
48-
49- .. _c2c-verify-with-doc-counts:
50-
51- Document Counts
52- ~~~~~~~~~~~~~~~
53-
54- The most basic method of verification is to compare the number of documents
55- in each synced collection on the source cluster to the number on the
56- destination cluster.
57-
58- This method only verifies a successful sync when run against clusters with
59- insert-only workloads.
60-
61- For more information, see :ref:`c2c-verify-doc-counts`.
62-
63- .. _c2c-verify-with-hash-comp:
64-
65- Hash Comparison
66- ~~~~~~~~~~~~~~~
67-
68- You can verify sync by comparing MD5 hashes of collections synced from the
69- source cluster to the destination cluster.
70-
71- While hash comparison ensures that the destination cluster has received all
72- changes from the source, the :dbcommand:`dbHash` command locks the cluster,
73- preventing additional writes until it completes.
26+ -----
27+
28+ You should verify your data after every sync. This is important
29+ in cases where you plan to move your application load from the
30+ source to the destination cluster.
31+
32+ .. list-table::
33+ :widths: 20 80
34+ :header-rows: 1
35+ :stub-columns: 1
36+
37+ * - Verification Method
38+ - Description
39+
40+ * - :ref:`Document Counts <c2c-verify-doc-counts>`
41+ - The most basic method of verification is to compare the
42+ number of documents in each synced collection on the
43+ source cluster to the number on the destination cluster.
44+
45+ Before you can verify data transfer with this method,
46+ ``mongosync`` must be in the ``COMMITTED`` state.
47+
48+ This method only verifies a successful sync when run
49+ against clusters with insert-only workloads.
50+
51+ * - :ref:`Hash Comparison <c2c-verify-hash-comp>`
52+ - You can verify sync by comparing MD5 hashes of
53+ collections synced from the source cluster to the
54+ destination cluster.
55+
56+ Before you can verify data transfer with this method,
57+ ``mongosync`` must be in the ``COMMITTED`` state.
58+
59+ While hash comparison ensures that the destination
60+ cluster has received all changes from the source, the
61+ :dbcommand:`dbHash` command locks the cluster, preventing
62+ additional writes until it completes.
63+
64+ Hash comparison is **not** possible with sharded
65+ clusters. It also does not work with standalone servers
66+ and replica sets that use MongoDB 4.4 or earlier
67+ releases, since the document field order can vary.
68+
69+ * - Document Comparison
70+ - You can verify sync by comparing documents on the source
71+ and destination clusters.
72+
73+ Write a script that queries collections on the source
74+ cluster and then checks that the correct documents,
75+ indexes, collections, metadata, and views exist with the
76+ same values on the destination cluster.
77+
78+ Before you can verify data transfer with this method,
79+ ``mongosync`` must be in the ``COMMITTED`` state.
80+
81+ * - .. _c2c-index-comparison:
82+
83+ Index Comparison
84+ - To verify the transfer of indexes, run the
85+ :method:`db.collection.getIndexes` method on the source
86+ and destination clusters and compare the results.
87+
88+ * - .. _c2c-metadata-comparison:
89+
90+ Metadata Comparison
91+ - To verify the transfer of metadata, run the
92+ :method:`db.getCollectionInfos` method on the source and
93+ destination clusters and compare the results.
94+
95+ * - .. _c2c-shardkey-comparison:
96+
97+ Shard Key Comparison
98+ - To verify the transfer of shard keys to a synced collection, run a query on the ``config.collections``
99+ collection to find a document whose ``_id`` value is the namespace of the target collection.
100+ Compare the ``key`` value of this document in the source and destination clusters.
101+
102+ For example, for a collection named ``pets`` in the ``records`` database, you can verify the shard key
103+ using the following query in :binary:`mongosh`:
104+
105+ .. io-code-block::
106+ :copyable: true
107+
108+ .. input::
109+ :language: javascript
110+
111+ db.getSiblingDB("config").collections.find({ _id : "records.pets" })
112+
113+ .. output::
114+ :language: javascript
115+ :emphasize-lines: 5-7
116+ :visible: false
117+
118+ {
119+ "_id" : "records.pets",
120+ "lastmod" : ISODate("2021-07-21T15:48:15.193Z"),
121+ "timestamp": Timestamp(1626882495, 1),
122+ "key" : {
123+ "_id" : 1
124+ },
125+ "unique" : false,
126+ "lastmodEpoch" : ObjectId("5078407bd58b175c5c225fdc"),
127+ "uuid" : UUID("f8669e52-5c1b-4ea2-bbdc-a00189b341da")
128+ }
129+
130+ * - :ref:`Migration Verifier <c2c-migration-verifier>`
131+ - Migration Verifier connects to the source and destination
132+ clusters and performs a series of verification checks,
133+ comparing documents, views, and indexes to confirm the
134+ sync was successful.
74135
75- .. note::
76-
77- Hash comparison is not possible with sharded clusters. It also does not
78- work for standalone servers and replica sets that use MongoDB 4.4 or earlier
79- releases, since the document field order can vary.
80-
81- For more information, see :ref:`c2c-verify-hash-comp`.
82-
83- .. _c2c-verify-with-doc-comp:
84-
85- Document Comparison
86- ~~~~~~~~~~~~~~~~~~~
87-
88- You can verify sync by comparing documents on the source and destination
89- clusters. Write a script that queries collections on the source cluster and
90- then checks that the document exists with the same values on the destination
91- cluster.
92-
93- .. _c2c-verify-with-verifier:
94-
95- Migration Verifier
96- ~~~~~~~~~~~~~~~~~~
97-
98- Migration Verifier connects to the source and destination clusters and performs
99- a series of verification checks, comparing documents, views, and indexes to
100- confirm the sync was successful.
101-
102- .. important::
103-
104- Migration Verifier is an experimental and unsupported tool.
105-
106- For installation instructions, see
107- `GitHub <https://github.com/mongodb-labs/migration-verifier>`__.
108-
109- Unlike other verification methods, Migration Verifier can run concurrent
110- with ``mongosync``, checking documents on the destination cluster as they
111- sync.
112-
113- For more information, see :ref:`c2c-migration-verifier`.
136+ Migration Verifier is an experimental and unsupported
137+ tool.
138+
139+ The specific method you use to verify your data depends on your
140+ application workload and the complexity of the data.
114141
115142.. toctree::
116143 :hidden:
@@ -122,11 +149,6 @@ For more information, see :ref:`c2c-migration-verifier`.
122149Learn More
123150----------
124151
125- For more information, see:
126-
127152- :method:`db.collection.countDocuments`
128153
129- - :dbcommand:`dbHash`
130-
131-
132-
154+ - :dbcommand:`dbHash`
0 commit comments