alexey.rassokhin/tet123
1
0
Fork 0
Code Issues Pull Requests 1 Packages Projects Releases Wiki Activity

DBZ-6455: Document Optimal MongoDB Oplog Config for Resiliency

Browse Source 
Addresses/Closes DBZ-6455
This commit is contained in:
Ronak Jain 2023-06-24 10:51:14 +05:30 committed by Jakub Cechacek
parent 17b2db35ce
commit 6006d60120
1 changed files with 2 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
documentation/modules/ROOT/pages/connectors/mongodb.adoc
View File

@ -1116,6 +1116,8 @@ To help prevent failures that are related to missing oplog entries, it's importa
In particular, you should monitor the values of Oplog GB/Hour and Replication Oplog Window.
If {prodname} is offline for an interval that exceeds the value of the replication oplog window, and the primary oplog grows faster than {prodname} can consume entries, a connector failure can result.
See [MongoDB replication metrics] (https://www.mongodb.com/basics/how-to-monitor-mongodb-and-what-metrics-to-monitor#mongodb-replication-metrics) to learn how to monitor these metrics.
It's best to set the maximum oplog size to a value that is based on the anticipated hourly growth of the oplog ([Oplog GB/Hour](https://www.mongodb.com/basics/how-to-monitor-mongodb-and-what-metrics-to-monitor#oplog-gbhour)), multiplied by the time that might be required to address a {prodname} failure.
That is,
@ -1127,10 +1129,6 @@ If {prodname} were to fail during this time, its last oplog position is likely t
If the oplog grows at the rate of 3GB/hour, and {prodname} is offline for two hours, you would thus set the oplog size to (3 GB/hour X 2 hours), or 6GB.
. Additional resources
* [MongoDB replication metrics](https://www.mongodb.com/basics/how-to-monitor-mongodb-and-what-metrics-to-monitor#mongodb-replication-metrics)
// Type: assembly
// ModuleID: deployment-of-debezium-mongodb-connectors
// Title: Deployment of {prodname} MongoDB connectors