Rollbacks During Replica Set Failover副本集故障转移期间的回滚

Configure Rollback Data配置回滚数据

The createRollbackDataFiles parameter controls whether or not rollback files are created during rollbacks.createRollbackDataFiles参数控制回滚期间是否创建回滚文件。

Rollback Data回滚数据

By default, when a rollback occurs, MongoDB writes the rollback data to BSON files.默认情况下，当发生回滚时，MongoDB会将回滚数据写入BSON文件。

removed.<timestamp>.bson

<dbpath>/rollback/20f74796-d5ea-42f5-8c95-f79b39bad190/removed.2020-02-19T04-57-11.0.bson

grep "rollback file" /var/log/mongodb/mongod.log

var mydatabases=db.adminCommand("listDatabases").databases;
var foundcollection=false;

for (var i = 0; i < mydatabases.length; i++) {
   let mdb = db.getSiblingDB(mydatabases[i].name);
   collections = mdb.getCollectionInfos( { "info.uuid": UUID("20f74796-d5ea-42f5-8c95-f79b39bad190") } );

   for (var j = 0; j < collections.length; j++) {   // Array of 1 element
      foundcollection=true;
      print(mydatabases[i].name + '.' + collections[j].name);
      break;
   }

   if (foundcollection) { break; }
}

removed.<timestamp>.bson

<dbpath>/rollback/reporting.comments/removed.2019-01-31T02-57-40.0.bson

Rollback Data Exclusion回滚数据排除

If the operation to roll back is a collection drop or a document deletion, the rollback of the collection drop or document deletion is not written to the rollback data directory.如果回滚操作是删除集合或文档，则不会将删除集合或删除文档的回滚写入回滚数据目录。

Read Rollback Data读取回滚数据

To read the contents of the rollback files, use bsondump. 要读取回滚文件的内容，请使用bsondump。Based on the content and the knowledge of their applications, administrators can decide the next course of action to take.管理员可以根据应用程序的内容和知识来决定下一步的操作。

Journaling and Write Concern majority记者和写入关注majority

To prevent rollbacks of data that have been acknowledged to the client, run all voting members with journaling enabled and use { w: "majority" } write concern to guarantee that the write operations propagate to a majority of the replica set nodes before returning with acknowledgement to the issuing client.若要防止回滚已向客户端确认的数据，请在启用日志记录的情况下运行所有投票成员，并使用{ w: "majority" }写入关注，以确保写入操作在返回到发出确认的客户端之前传播到大多数副本集节点。

Starting in MongoDB 5.0, { w: "majority" } is the default write concern for most MongoDB deployments. 从MongoDB 5.0开始，{ w: "majority" }是大多数MongoDB部署的默认写入关注。See Implicit Default Write Concern.请参阅隐式默认写入关注。

With writeConcernMajorityJournalDefault set to false, MongoDB does not wait for w: "majority" writes to be written to the on-disk journal before acknowledging the writes. 在writeConcernMajorityJournalDefault设置为false的情况下，MongoDB不会等待w: "majority"写入到磁盘日志中，然后再确认写入。As such, "majority" write operations could possibly roll back in the event of a transient loss (e.g. crash and restart) of a majority of nodes in a given replica set.因此，在给定副本集中的大多数节点发生瞬时丢失（例如崩溃和重新启动）的情况下，"majority"写入操作可能会回滚。

Visibility of Data That Can Be Rolled Back可回滚数据的可见性

• Regardless of a write's write concern, other clients using "local" or "available" read concern can see the result of a write operation before the write operation is acknowledged to the issuing client.无论写入的写入关注如何，使用"local"或"available"读取关注的其他客户端都可以在向发出请求的客户端确认写入操作之前看到写入操作的结果。
• Clients using "local" or "available" read concern can read data which may be subsequently rolled back during replica set failovers.使用"local"或"available"读取关注的客户端可以读取数据，这些数据随后可能在副本集故障切换期间回滚。

For operations in a multi-document transaction, when a transaction commits, all data changes made in the transaction are saved and visible outside the transaction. 对于多文档事务中的操作，当事务提交时，事务中所做的所有数据更改都将保存并在事务外部可见。That is, a transaction will not commit some of its changes while rolling back others.也就是说，事务在回滚其他更改时不会提交某些更改。

Until a transaction commits, the data changes made in the transaction are not visible outside the transaction.在事务提交之前，在事务中所做的数据更改在事务外部是不可见的。

However, when a transaction writes to multiple shards, not all outside read operations need to wait for the result of the committed transaction to be visible across the shards. 然而，当一个事务写入多个分片时，并不是所有的外部读取操作都需要等待提交的事务的结果在分片中可见。For example, if a transaction is committed and write 1 is visible on shard A but write 2 is not yet visible on shard B, an outside read at read concern "local" can read the results of write 1 without seeing write 2.例如，如果事务已提交，并且写1在分片a上可见，但写2在分片B上还不可见，则外部读取时关注"local"可以读取写1的结果，而不会看到写2。

User Operations用户操作

Starting in version 4.2, MongoDB kills all in-progress user operations when a member enters the ROLLBACK state.从4.2版本开始，当成员进入ROLLBACK状态时，MongoDB会终止所有正在进行的用户操作。

Index Builds索引构建

• For feature compatibility version (fcv) "4.2", MongoDB waits for any in-progress index builds to finish before starting a rollback.对于功能兼容性版本（fcv）"4.2"，MongoDB会等待任何正在进行的索引构建完成，然后再启动回滚。

For more information on the index build process, see Index Builds on Populated Collections.有关索引生成过程的详细信息，请参阅填充集合上的索引生成。

Index Operations When "majority" Read Concern is Disabled禁用"majority"读取关注时的索引操作

Disabling "majority" read concern prevents collMod commands which modify an index from rolling back. 禁用"majority"读取关注可防止修改索引的collMod命令回滚。If such an operation needs to be rolled back, you must resync the affected nodes with the primary node.如果需要回滚这样的操作，则必须将受影响的节点与primary节点重新同步。

Size Limitations尺寸限制

MongoDB does not limit the amount of data you can roll back.MongoDB不限制您可以回滚的数据量。

Rollback Elapsed Time Limitations回滚运行时间限制

The rollback time limit defaults to 24 hours and is configurable using the rollbackTimeLimitSecs parameter.回滚时间限制默认为24小时，可使用rollbackTimeLimitSecs参数进行配置。

MongoDB measures elapsed time as the time between the first common operation in the oplogs to the last entry in the oplog of the member being rolled back.MongoDB测量运行时间，即从oplog中的第一个常用操作到被回滚成员的oplog中最后一个条目之间的时间。