Mongorestore的archive(归档)模式恢复原理解析

2022-02-12 06:33:23

在上篇Mongodump的archive（归档）模式原理解析中介绍过，Mongodump的archive（归档）模式产生的文件是将多个集合的数据通过一个Multiplexer多路复用混合在一起，因此对应在恢复的时候就需要有一个Demultiplexer来将数据进行解析，是一个多路复用的逆过程。对应于mongodump，MongoDB官方提供了mongorestore这个恢复工具。

归档文件的格式

复习一下归档文件的格式，其最前面有4个字节的magic number，然后是元数据部分（prelude），描述这个归档文件包含哪些集合、索引等信息，最后是body部分，由一个个slice组成，每个slice有一个header、若干个body和一个terminator，其中header和body都是一个bson，terminator是一个4字节的标记。如下图所示：

流程

从一个mongodump备份的归档文件中恢复的过程包括读取归档文件，解析成对应集合的数据，然后再恢复到目标MongoDB。为了同时支持非归档模式和归档模式，这里mongorestore做了一些抽象：主要包括Intent、file接口和DemuxOut。

Intent、file接口

Intent是对备份文件的抽象，一个Intent有可能是某一个集合的数据的备份文件（在非归档模式下是一个BSON文件），也有可能是某一个集合的元数据文件（在非归档模式下是一个JSON文件，其中包含集合创建时指定的option以及索引信息等，以.metadata.json结尾）。访问一个Intent需要通过file接口的Open()、Read()、Write()和Close()方法：

type file interface {
  io.ReadWriteCloser
  Open() error
}

在非归档模式下，对应的file接口的实现是realBSONFile和realMetadataFile。这两个实现的Open()方法调用os.Open()打开对应的文件，使用返回的File进行读取数据。

在归档模式下，mongorestore定义了几个特定的file接口实现，来实现边读取并解析归档文件边恢复。

DemuxOut

之前介绍过，对于归档文件，由于是各个集合的数据按条（slice）混合在一起的，这样我们在顺序读取归档文件时就需要有一个Demultiplexer来将数据进行解混合（甚至进行分发以便可以实现多个集合并发恢复）。DemuxOut也是一组接口定义，主要负责定义Demultiplexer解析归档文件后如何输出数据：

type DemuxOut interface {
  Write([]byte) (int, error)
  Close() error
}

常规集合的Demux恢复流程

主协程通过读取归档文件的prelude，得到需要恢复的集合信息，然后为每个集合创建Intent。之后启动一个Demultiplexer协程（以下简称Demux协程）负责读取归档文件的body部分并进行解析，同时会启动N个Restore协程（根据指定的集合恢复并发度）进行恢复。Demux协程解析出某个集合的数据后调用DemuxOut的Write()方法将数据输出去。Restore协程从Intent的file接口读取数据，并执行恢复到目标MongoDB。

对于需要恢复的常规集合（包括oplog集合），mongorestore定义了一个RegularCollectionReceiver实现了file接口，定义了一个regularCollectionSender实现了DemuxOut接口。regularCollectionSender的Write()方法将这次要发送的数据长度通过一个readLenChan发送出去。RegularCollectionReceiver的Read()方法则等待在这个readLenChan上，等待新数据的通知，当收到数据长度通知时发送一个buf给它。Demux协程会将数据拷贝到这个buf中，再次通过readLenChan通知已拷贝的数据长度，然后继续往下解析。Restore协程收到数据拷贝完毕的通知后，将这些数据恢复到目标MongoDB。恢复的速度通常来说跟不上Demux解析的速度，因此RegularCollectionReceiver在必要时会将Demux发送过来的数据缓存起来慢慢消费。这样Demux协程就可以不停的往下解析，并且可以实现多集合并发恢复。

特殊集合的处理

有一些集合在恢复过程中是需要特殊处理的，这里所说的特殊处理，主要是需要在恢复的特定阶段进行处理。比如对于admin.system.version集合，需要在恢复常规集合之前进行auth版本是否兼容的判断。再比如用户和角色集合，是在恢复的最后阶段进行处理的。对于这些特殊集合，mongorestore的处理方法是，如果在归档文件读取并解析的过程中读取到了，会先缓存在一个buffer中，等到需要的时候再进行处理。在实现上，mongorestore针对这些集合定义了特殊的DemuxOut接口的实现：SpecialCollectionCache。这个实现包含一个bytes.Buffer，利用其Write()方法和Read()方法（这也是其对应的file接口的实现）实现集合数据的暂存和读取。为此，mongorestore为每个Intent都维护了一个对应的DemuxOut，以便可以特殊处理。

如何实现恢复的过程中过滤某些集合

有些集合是不需要进行恢复的，包括system.profile、索引以及不满足用户指定的filter条件的集合等。索引之所以不需要恢复是因为索引是统一通过集合的元数据文件中的描述在集合数据恢复完毕后进行重建的。对于这些不需要恢复的集合，对应的DemuxOut接口的实现是MutedCollection。这个实现的Write()、Close()方法都不干任何事情。这样就实现了过滤恢复。

多集合并发时的恢复优先级

如果在恢复的时候指定了多集合并发进行恢复，mongorestore会在恢复前初始化一个集合恢复优先级调度器。在非归档模式下，会使用一个MultiDatabaseLTF的优先级调度器。这个优先级调度器会在优先恢复大集合的同时兼顾不同数据库集合的并发恢复。在归档模式下，基本就是按照集合的数据在归档文件中的顺序进行恢复。在Demux协程发现一个新的需要恢复的常规集合后，会通过namespaceChan通知主协程，并由主协程转发给归档模式下的优先级调度器，在这里调用RegularCollectionReceiver的Open()方法进行相关初始化，以及注册对应的DemuxOut，建立Demux协程和Restore协程的数据流通通道。

码农公寓