执行数据库恢复的时候,你想要尽快完成。在灾难恢复的情况下,情况足够压力。和数据库不可用,直到恢复就完成了。所以每一分钟都很重要。与大数据集变得尤其重要。
把物理备份在MongoDB Percona雷竞技下载官网备份(PBM)是一个巨大的一步恢复速度。物理恢复本质上是将数据文件复制到目标节点和开始一个数据库数据目录,而逻辑手段复制数据和运行在数据库插入操作,这让头顶上解析数据,建立索引,等等。我们的测试显示物理数据库恢复到5倍的速度比逻辑的。但是我们可以做得更好吗?让我们试一试。
身体恢复的速度可以归结为我们如何快速复制(下载)数据从远程存储。所以我们决定尝试并行(并发)下载。在物理备份,PBM商店WiredTiger文件差不多,因为它们在数据目录,添加额外的压缩。如果你想下载不同的并行文件吗?它不会完全工作每个MongoDB收集的数据都存储在一个文件中。所以数据不均匀地扩散到整个文件。我们会有瓶颈的大集合。因此,更好的方法是每个文件同时下载。
PBM已经下载的文件块,但是它所做的仅仅是为了重试。所以在网络故障的情况下,我们必须重试最近的一块,而不是整个文件。这个想法是为了同时下载这些块。问题是:阅读无序,我们不能直接写文件(寻求抵消),我们必须先解压缩数据(默认备份中的数据压缩)。因此,尽管我们可以无序的读取数据,我们必须按顺序写下来。为此,我们做了一个特殊的内存缓冲区。块可以同时放和无序,但消费者总是按顺序读取数据。
最终的设计
下载开始工人的数量,等于并发(默认数量的CPU核)。有预先分配领域领域池中为每个工人。的竞技场基本上是一个字节缓冲区空闲插槽位图。每个领域分为跨越。跨度的大小等于下载块大小。当一个工人想下载一块,它获得免费的跨度从舞台上首先和下载数据。当消费者读取这些数据,跨度标记为免费并为下一个块可以重用。工人不等待要读取的数据,一旦下载一块,需要另一个块从任务队列,获得下一个自由跨度,和下载数据。为了防止不受控制的内存消耗,横跨在每个领域的数量是有限的,和工人将不得不等待一个自由跨度下载下一个块如果都忙。
另一方面,我们跟踪的消费者,最后写的字节的数量,为每一个文件。如果下载的块是无序的,它被推到堆或给消费者。在下一次迭代(下一块下载),我们检查堆的顶部,流行的块,还给消费者如果/到块。
看到提交更多的细节变化。
配置选项
一些新选项被添加到PBM配置文件调整并发下载。
numDownloadWorkers——设置并发性。默认值:cpu的数量
downloadChunkMb,块的大小下载Mb。默认值:32
maxDownloadBufferMb——上限可用于下载缓冲区的内存(领域)Mb。默认值:numDownloadWorkers * downloadChunkMb * 16。如果设置,块大小可能会改变以适应最大需求。这并不意味着所有这些内存使用和实际分配的物理RAM。
结果
PBM支持不同存储类型,但是对于这个实现中,我们决定先使用最广泛,S3兼容。我们目的港口Azure团在后续版本和文件系统存储类型。
我们的测试在AWS S3节目x 19提高恢复速度:
实例 |
备份的大小 |
并发性 |
跨度大小 |
恢复时间 |
并发下载 |
||||
i3en。超大(4个vcpu, 16 gb的RAM) |
500 gb |
4 |
32 mb |
45分钟 |
i3en。超大(4个vcpu, 16 gb的RAM) |
500 gb |
8 |
32 mb |
32分钟 |
i3en。3超大(12个vcpu, 96 gb的RAM) |
5结核病 |
12 |
32 mb |
168分钟 |
i3en。3超大(12个vcpu, 96克B RAM) |
5结核病 |
24 |
32 mb |
117分钟 |
释放v2.0.3 |
||||
i3en。超大(4个vcpu, 16 gb的RAM) |
500 gb |
227分钟 |
||
i3en。3超大(12个vcpu 96 gb RAM) |
5结核病 |
~ 2280分钟 |
||
*测试在AWS i3en与S3存储在同一地区的实例。
* *我们不等待5结核病恢复v2.0.3完成并使用“时间上传Gb”率结果外推。
尝试Pe雷竞技下载官网rcona MongoDB的备份恢复更快
这是一个重大的改进,其他新特性雷竞技下载官网为MongoDB Percona备份(PBM)释放。试一试,离开你反馈!
