我们使用 RocksDB 作为我们的引擎已经有一段时间了，现在我们正在尝试迁移到 WiredTiger。我们有一些相当大的数据库，大约有 4~12 TB 的数据，根据文档中描述的过程，我们添加了一个带有 WiredTiger 的新节点，并尝试让它从头开始复制。
对于数据量，复制时间非常长，很多时候我们遇到的情况是 WiredTiger 节点决定更改它从中复制的节点，只是删除所有数据并重新从头开始。只有一次我们成功完成了复制，但与 oplog 相比，节点最终落后了很多。
同样，对于如此大量的数据，拥有足够大的 oplog 来保存数周的事务变得令人望而却步，并且该过程也非常脆弱、单线程、缓慢且容易失败。
所以我的问题如下：
是否有更好的方法来进行此迁移？
有没有办法加速复制（即多线程复制）？
有没有办法告诉新的 WiredTiger 节点在发生事故时停止丢弃所有数据？
我们正在使用 Percona MongoDB 3.4.13 版的 3 和 5 个节点副本集，并尝试迁移到开源 MongoDB 3.4.13（我们的想法是在 WiredTiger 中升级到 4.x 并完全放弃 RocksDB 和 Percona） .
小智 1
如果复制跟不上主复制并且无法扩展 oplog，我会尝试对部署进行分片并...
让较小的分片复制得更快
或者
耗尽原始分片，然后将其从部署中删除 - 这解决了您的存储引擎问题，但使复制像以前一样滞后
| 归档时间： |
|
| 查看次数： |
487 次 |
| 最近记录： |