Skip to content

Commit 70e3343

Browse files
authored
(DOCSP-45308) Convert page to table, removing embedded verifier. (#531)
1 parent a6b502e commit 70e3343

File tree

1 file changed

+118
-96
lines changed

1 file changed

+118
-96
lines changed

source/reference/verification.txt

Lines changed: 118 additions & 96 deletions
Original file line numberDiff line numberDiff line change
@@ -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

4625
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.
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`.
122149
Learn 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

Comments
 (0)