这事说起来有点意思。前天一个朋友半夜给我打电话，说他们的数据库服务器硬盘报警了，需要紧急把数据复制到另一台备用的机器上。电话那头声音焦虑，毕竟数据就是一家公司的命根子。我一边安抚他，一边脑子里快速过了一遍那些年踩过的坑。数据库复制这事儿，看着简单，真干起来，十个有八个要翻车。你以为是冷备份拷贝文件就完事了？太天真。数据一致性、网络带宽、表锁机制，随便一个环节出问题，就能让整个系统停摆。
先说最基础的物理复制。就是把数据库的物理文件直接拷贝到另一台服务器上，比如MySQL的ibdata1文件或者PostgreSQL的data目录。这方法适合停机维护的场景，操作起来也直接。但你得注意，拷贝前必须确保数据库完全关闭，否则文件可能处于不一致状态。我见过有人图省事，在数据库运行时就复制，结果目标服务器启动后提示“磁盘损坏”，数据全部乱码。更坑的是，如果你用的是InnoDB引擎，事务日志和表空间文件必须同步，光拷数据文件没用。所以物理复制的关键就是三个字：先停库。
再说逻辑复制，比如用mysqldump或者pg_dump导出SQL脚本，再导入到新服务器。这个方法灵活，你可以选择只导出特定表或指定条件的数据。而且不需要停机，用--single-transaction参数就能保证一致性快照。但缺点也很明显：数据量一大，导出导入的时间长得让人崩溃。我有个客户，500GB的数据库，mysqldump跑了整整13个小时，中间网络闪断一次，前功尽弃。而且大事务导入时，目标服务器的redo log和undo log会被撑爆，直接导致宕机。所以逻辑复制适合小规模或增量数据的迁移，全量的话，你得做好通宵的心理准备。
现在很多公司都转向了基于日志的实时复制，比如MySQL的主从复制、PostgreSQL的流复制，或者用CDC工具像Debezium、Canal来同步。这类方案的核心是抓取数据库的binlog或WAL日志，在目标服务器上重放，实现接近实时的同步。好处是源库几乎零影响，业务可以继续跑。但坑也不少：网络延迟会导致主从数据不一致，一旦发生主库故障，从库可能还差几条日志没追上。我见过一个电商团队，双十一当天的数据库主库挂了，从库延迟了3秒，结果订单数据对不上，客服被骂了三天。所以用日志复制，一定要配置半同步复制并监控延迟指标，别以为配完就万事大吉。
如果你觉得这些太复杂，还有更粗暴的方法：用数据库自带的导入导出工具，比如SQL Server的BCP命令或者Oracle的Data Pump，直接通过网络传输数据。这类工具支持并行导出，速度比mysqldump快很多。但问题在于，它们对网络带宽的占用是突发的，容易把生产网的带宽打满。我有个做金融的朋友，用Data Pump迁移200GB数据，结果办公网的视频会议全部卡死，老板直接打电话骂人。更关键的是，这些工具对字符集和时区的处理经常有bug，导出的数据到新库后，中文变乱码，时间戳对不上。所以用之前，一定要先在测试环境跑一遍，确认字符集设置完全一致。
还有一种邪门歪道：用文件系统快照。比如用LVM的快照功能，或者存储阵列的快照，先创建一个数据库文件的一致性快照，然后把快照挂载到新服务器上。这个方法速度快，几乎零停机，但要求你的存储系统支持快照，而且快照本身也需要空间。我见过有人用这个方案，快照创建完后忘了删除，结果磁盘空间被快照写满，生产库直接写不进去。更麻烦的是，快照恢复后的数据库，通常需要做一次完整性检查，因为快照捕获的数据可能包含未提交的事务，需要回滚。所以快照方案适合对停机窗口要求极严的场景，但后续的清理和检查工作一点不能省。
说了这么多，其实我想表达的是：数据库复制这件事，没有银弹。每个方案都有它的适用场景和潜在风险。物理复制简单直接，但需要停机；逻辑复制灵活，但慢得像蜗牛；日志复制实时性强，但依赖网络和监控；工具导入速度快，但容易出字符集问题；快照方案零停机，但依赖基础设施。你在选方案时，得先想清楚自己的核心诉求是什么：是数据一致性优先，还是可用性优先？是允许少量停机，还是必须7×24小时？把这些想明白了，再去动手。别像我那个朋友一样，半夜急眼了才想起来问怎么复制——提前规划好，才是真省心。
