数据库复制技术怎么用来同步备份，保证数据不丢失的那些事儿

（根据知乎专栏“技术琐话”、微信公众号“阿里技术”以及多位资深数据库工程师的社区分享综合整理）

说到数据库复制技术怎么用来做同步备份，保证数据不丢失，这事儿其实可以理解成给咱们的重要数据找一个或多个“影子”，而且这些“影子”要跟“真身”保持步调完全一致，不能掉队，核心目标就一个：哪怕主数据库所在的机房突然停电、硬盘全坏掉了，也能立刻从这些“影子”里拉起来一个继续干活,数据几乎没丢。

这事儿的关键在于“日志”。 你可以把数据库的每一次操作，比如小明下单买了个手机，或者管理员修改了商品价格，都想象成一条清晰的指令，数据库不会直接去磁盘上那个巨大的数据文件里翻来翻去找那块数据然后修改，那样太慢了，它通常会先把“小明要买手机”这个操作指令，按顺序记录在一个专门的“流水账”本上，这个“流水账”就是事务日志（比如MySQL的binlog，PostgreSQL的WAL），这个记录操作非常快，记完了日志，就算“确认”了这个操作，然后再慢慢地去更新磁盘上的大数据文件，这个“先记小账本，再更新大账本”的机制,是整个复制备份故事的基石。

复制技术是怎么利用这个“流水账”的呢？ 主数据库会忠实地记录下所有的操作日志，然后像一个广播站一样，把这些日志内容发送给一个或多个备数据库，备数据库收到这些日志后，就会在自己本地，按照完全相同的顺序，重新执行一遍这些操作，比如收到“小明买手机”的日志，它就在自己的数据库里也执行一次扣库存、生成订单的操作，这样，只要网络不中断，备数据库里的数据就会和主数据库几乎实时地保持一致，这就像是主数据库在做事，旁边有个秘书在同步做笔记，而且这个笔记做得非常详细,能完全复现整个过程。

怎么才能确保数据一定不丢失呢？这里有个至关重要的环节，叫做“确认机制”。 光主库把日志发出去还不够，万一备库没收到，或者收到但没处理完，主库就以为万事大吉了，那就会出问题，为了解决这个隐患，工程师们想出了办法，最常见的一种是同步复制模式，在这种模式下，主数据库每执行一个事务、记录一条日志，它不会立刻告诉应用程序“操作成功”，而是会等待，等什么呢？等待至少一个备数据库确认：“喂，老兄，你刚才那条日志我已经收到并且成功写到我自己的日志文件里了！” 只有收到这个确认信号，主数据库才会向应用程序返回“操作成功”。

（根据“阿里技术”对金融级数据库架构的解读）这就好比你要寄一份非常重要的合同，你不是扔进邮筒就完事了，而是必须使用“挂号信”并且要求“回执”，邮局（备库）必须签收并把回执（确认信号）返还给你（主库），你才能放心地说“合同确定寄到了”，这种方式最大程度地保证了数据不会在传输环节丢失，因为任何一方没确认，整个操作就不会最终完成，这么做的代价是性能会受影响，因为每次操作都要等待网络往返的延迟，所以通常在对数据一致性要求极高的场景，比如银行核心交易系统里,会采用这种策略或其变种。

另一种更常见的模式是异步复制，这种模式下，主数据库写完自己的日志后，就会立刻告诉应用程序“成功了”，然后再“异步地”、慢慢地把日志发送给备库，它不会等待备库的确认，这就像你发普通电子邮件，点击“发送”后你的任务就完成了，至于对方什么时候收到、看没看，你无法实时知道，这种方式性能很好，延迟低，但存在一个风险：如果主数据库在日志发送给备库之前突然崩溃，那么最后那一小部分已经告诉用户“成功”的数据，实际上并没有被备库接收到,这就造成了数据丢失。

为了在性能和可靠性之间取得平衡，还有一种折中的半同步复制，它要求主库在提交事务前，必须等待至少一个备库确认收到了日志（但不要求备库已经执行完），如果超过一定时间没收到确认，主库会降级为异步模式，确保业务还能继续,只是这段时间内可能有不一致的风险。

除了复制模式，备份的“阵型”也很重要。 最常见的是“一主一备”，但为了更安全，可以采用“一主多备”，甚至环状复制等更复杂的架构，这样即使一个备库也坏了，还有其他备份可用,提高了系统的鲁棒性。

光有技术还不够，还得有验证。 定期进行“灾备演练”至关重要，就是主动模拟主数据库宕机，然后手动或自动地将一个备库切换成新的主库，让业务系统连接到它上面继续运行，这个过程能检验整个复制备份链路是否真的可靠，切换流程是否顺畅,确保万一真出事时不会手忙脚乱。

数据库复制技术通过“记录操作日志”、“将日志同步给备库”、“备库重放日志”这一套流程来实现同步备份，而要保证数据不丢失，核心在于采用强一致的“确认机制”（如同步复制），确保每一条数据变更都至少在两个地方落盘了才算成功，但这需要根据业务对数据一致性和系统性能的实际要求，来选择合适的复制策略，没有绝对完美的方案,只有最适合的权衡。