diff options
author | Samyukta Lanka <samy.lanka@mongodb.com> | 2019-10-17 19:39:51 +0000 |
---|---|---|
committer | evergreen <evergreen@mongodb.com> | 2019-10-17 19:39:51 +0000 |
commit | 1daf063435aa3f748840c476f8fa3bd13d7d2a68 (patch) | |
tree | 7504aabbcbc343b13079a28b85fe7c960c9325b2 /src | |
parent | ec0bf809b1b60c4edc32146ed971222c30f9d8fa (diff) | |
download | mongo-1daf063435aa3f748840c476f8fa3bd13d7d2a68.tar.gz |
SERVER-43779 Add section on Two Phase Drops to the Replication Architecture Guide
Diffstat (limited to 'src')
-rw-r--r-- | src/mongo/db/repl/README.md | 33 |
1 files changed, 33 insertions, 0 deletions
diff --git a/src/mongo/db/repl/README.md b/src/mongo/db/repl/README.md index 4d016eb3cf0..a9a6c33a63f 100644 --- a/src/mongo/db/repl/README.md +++ b/src/mongo/db/repl/README.md @@ -748,3 +748,36 @@ where we cannot assume a drop will come and fix them, we abort and retry initial The oplog application phase concludes when the node applies `minValid`. The node checks its sync source's Rollback ID to see if a rollback occurred and if so, restarts initial sync. Otherwise, the `DataReplicator` shuts down and the `ReplicationCoordinator` starts steady state replication. + +# Dropping Collections and Databases + +In 3.6, the Two Phase Drop Algorithm was added in the replication layer for supporting collection +and database drops. It made it easy to support rollbacks for drop operations. In 4.2, the +implementation for collection drops was moved to the storage engine. This section will cover the +behavior for the implementation in the replication layer, which currently runs on nodes where +<!-- TODO SERVER-43788: Link to the section describing enableMajorityReadConcern=false --> +`enableMajorityReadConcern` is set to false. + +## Dropping Collections + +Dropping an unreplicated collection happens immediately. However, the process for dropping a +replicated collection requires two phases. + +In the first phase, if the node is the primary, it will write a "dropCollection" oplog entry. The +collection will be flagged as dropped by being added to a list in the `DropPendingCollectionReaper` +(along with its OpTime), but the storage engine won't delete the collection data yet. Every time the +`ReplicationCoordinator` advances the commit point, the node will check to see if any drop's OpTime +is before or at the majority commit point. If any are, those drops will then move to phase 2 and +the `DropPendingCollectionReaper` will tell the storage engine to drop the collection. + +By waiting until the "dropCollection" oplog entry is majority committed to drop the collection, it +guarantees that only drops in phase 1 can be rolled back. This means that the storage engine will +still have the collection's data and in the case of a rollback, it can then easily restore the +collection. + +## Dropping Databases + +When a node receives a `dropDatabase` command, it will initiate a Two Phase Drop as described above +for each collection in the relevant database. Once all collection drops are replicated to a majority +of nodes, the node will drop the now empty database and a `dropDatabase` command oplog entry is +written to the oplog.
\ No newline at end of file |