你有没有想过，为什么你在电商网站下单后，哪怕服务器出问题，订单信息也不会丢？这背后很可能就是数据库主从复制在起作用。
主从复制，简单说就是一个数据库（主库）把数据变动告诉另一个或多个数据库（从库），让它们保持同步。就像你在一个笔记本上记账，同时让朋友拿着另一个本子抄一遍，你的每一笔收入支出他都跟着写，这样就算你丢了本子，朋友那儿还有备份。
它是怎么工作的？
以 MySQL 为例，主从复制分三步走。主库记录每次写操作到二进制日志（binlog），从库的 I/O 线程去主库读取这些日志并保存到自己的中继日志里，然后从库的 SQL 线程再一条条执行中继日志里的命令。整个过程几乎是实时的，延迟通常在毫秒级别。
这种机制不只是为了防丢数据。比如在新闻网站，每天有上百万人刷首页，如果所有请求都打到同一个数据库，早就扛不住了。这时候就可以用主库处理用户评论、投稿等写操作，而把几十个从库专门用来响应查询请求，分摊压力。
配置长什么样？
下面是一个简单的 MySQL 主库配置片段：
server-id = 1
log-bin = mysql-bin
binlog-format = row从库则需要指定连接主库的信息：
server-id = 2
relay-log = mysql-relay-bin
read-only = 1接着执行 CHANGE MASTER TO 命令，告诉从库主库的地址、用户名、密码和日志位置，启动复制就行了。
当然，现实没那么理想。网络抖动可能导致从库延迟，有时候你刚发完朋友圈，刷新一下发现内容没出来，可能就是因为读到了还没同步完成的从库。为了避免这种情况，关键操作可以直接走主库读，或者监控延迟情况动态调整路由。
还有一种常见场景是数据库升级或迁移。你可以先搭好新版本的从库，让它同步老数据，等一切稳定后再切换流量，大大降低风险。
主从复制也不是万能的。它不能自动解决主库挂掉的问题，得靠额外的工具判断故障并提升从库为主库。而且一旦中间断了太久，从库可能无法继续增量同步，只能重新全量复制一次，费时费力。
尽管如此，主从结构仍是现代应用最常用的数据库架构之一。小到个人博客，大到银行系统，都能看到它的影子。理解它的工作方式，能帮你更清楚地知道数据是怎么流动和保护的。