@@ -16,101 +16,128 @@ Verify Data Transfer
16
16
:depth: 2
17
17
:class: singlecol
18
18
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.
43
22
44
23
.. _c2c-verify-method:
45
24
46
25
Tasks
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.
74
135
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.
114
141
115
142
.. toctree::
116
143
:hidden:
@@ -122,11 +149,6 @@ For more information, see :ref:`c2c-migration-verifier`.
122
149
Learn More
123
150
----------
124
151
125
- For more information, see:
126
-
127
152
- :method:`db.collection.countDocuments`
128
153
129
- - :dbcommand:`dbHash`
130
-
131
-
132
-
154
+ - :dbcommand:`dbHash`
0 commit comments