我正在研究如何实现从主数据中心到灾难恢复站点的近实时复制。要复制的数据包括：
- KVM 虚拟机映像
- MySQL 和 PostgreSQL 数据库
为了简单起见，我们假设总数据量少于 10 TB，平均写入速度低于 100MB/s，峰值为 1500MB/s，主数据中心和备份数据中心之间的链接吞吐量为 10gbit/s。
异步复制是可以接受的，也是我们所希望的——在发生突发写入或两个数据中心之间的连接短暂中断的情况下——我们不想降低本地写入速度，并且愿意牺牲最新的数据部分，以防在发生影响主数据中心的灾难性故障时丢失。
我的理解是我们可以选择：
- 具有复制功能并可提供 iSCSI LUN 的专有 SAN 硬件
- DRBD 可能需要与 DRBD 代理结合使用，以确保两个数据中心之间可用带宽的暂时下降或延迟峰值不会影响源的写入性能。
- 基于软件的解决方案，例如http://schoebel.github.io/mars/遗憾的是，在最好的情况下，它也需要相当长一段时间才能合并到主线内核中
- 对于数据库，数据库级复制也是一种选择，但我们希望偶尔进行灾难恢复测试，以便在数据中心之间切换所有工作负载。从灾难恢复站点故障恢复到主站点将非常麻烦。
还有其他值得考虑的解决方案吗？
谢谢你！
答案1
对于 DB 和 DB 感知及依赖应用程序，由于多种原因，它们的专有复制始终优于“通用”块级复制，DB 一致性就是其中之一。因此，使用 SQL Server 可用性组 (AG)，即使使用 2014 年或 2015 年推出的标准版 SQL Server，也存在一些限制，使用 MS Exchange DAG、SAP HANA、AeroSpike 副本等。我不会在 2020 年使用 DRBD，因为它的 I/O 性能相当差，尤其是在全闪存配置下，DRBD 显然是为 2000 年代初期的旋转磁盘和高延迟非 RDMA 网络而设计的，并且对裂脑问题的保护非常差。您可以作为主要虚拟机管理程序的一部分找到的虚拟 SAN 技术是 DB 内置复制技术的另一个不错的选择。
答案2
您可以考虑地理复制的 SDS 解决方案，例如 Gluster 和 Ceph，利用 ZFS 或 LVM 复制。
对于 KVM，qemu 现在具有 CDC 功能，并且正在构建各种解决方案以通过网络链路传输更改的块，而无需复制整个底层块设备。
对于任何其他软件（您提到数据库），使用数据库可能提供的本机工具确实是一种更好的方法。许多现代 NoSQL 数据库都是无主的，可以简单地在多 DC 模式下运行，副本按 DC 或机架推送。