在异构数据库架构中，将MySQL的数据实时同步到PostgreSQL，或者反向同步，是许多团队在系统迁移、报表分离和容灾建设中会遇到的实际需求。两种数据库内部的存储引擎与日志机制完全不同，因此不能简单地用文件拷贝或定时批量导出来实现实时性。我们需要依赖日志解析、逻辑复制或中间件来捕获数据变更并应用到对端。
一、MySQL与PostgreSQL复制机制差异
MySQL的主从复制主要基于binlog（二进制日志）。binlog有三种格式：statement、row和mixed。在实时同步场景中，row格式最为安全，因为它记录的是每一行实际变更前后的数据，而不是SQL语句，能避免函数不确定性导致的主从不一致。PostgreSQL则使用WAL（Write-Ahead Log）来保证事务持久性，并提供了物理复制和逻辑复制两种模式。逻辑复制通过解析WAL生成逻辑变更流，允许按表级粒度订阅，且目标端可以是不同版本的PostgreSQL甚至其他支持逻辑协议的系统。
理解两者差异是设计同步方案的前提。MySQL的binlog是MySQL专属格式，需要特定解析器；PostgreSQL的逻辑复制输出的是一种约定的逻辑协议，生态工具更容易对接。如果我们要在MySQL和PostgreSQL之间打通，通常的做法是以其中一个为源库，提取其日志变更，再转换为对端可执行的SQL。
1.1 MySQL binlog核心字段
binlog事件中包含了库名、表名、操作类型（insert、update、delete）以及行数据。通过开启GTID（全局事务ID），我们可以精确定位消费进度，在同步中断后从正确的位置恢复，而不会重复或遗漏事务。
在PostgreSQL侧，逻辑复制的发布（publication）和订阅（subscription）机制让同步配置更声明式。但需注意，PostgreSQL逻辑复制不会复制DDL，因此表结构变更需要额外处理，否则会出现目标表字段不匹配。
二、基于Debezium的实时同步方案
Debezium是一个开源的分布式CDC（变更数据捕获）平台，它首先通过MySQL连接器读取binlog，将变更转换为统一的事件结构（JSON或Avro），发送到Kafka等消息队列。我们再编写一个消费者服务，把这些事件翻译为PostgreSQL的INSERT、UPDATE、DELETE语句执行。
这种架构解耦了抓取与写入，即使PostgreSQL暂时不可用，Kafka中仍保留位点，恢复后继续消费即可。下面是一段简化版的Java消费者逻辑，演示如何将Debezium的变更事件转为PostgreSQL写入。
// 伪代码：将Debezium事件应用到PostgreSQL
public void applyChange(ChangeEvent event) {
String op = event.getOperation(); // insert/update/delete
String table = event.getTable();
Map<String, Object> data = event.getAfter();
if ("insert".equals(op)) {
String sql = buildInsertSql(table, data);
postgresTemplate.update(sql);
} else if ("update".equals(op)) {
Map<String, Object> before = event.getBefore();
String sql = buildUpdateSql(table, before, data);
postgresTemplate.update(sql);
} else if ("delete".equals(op)) {
String sql = buildDeleteSql(table, event.getBefore());
postgresTemplate.update(sql);
}
}
2.1 方案优缺点
优点在于实时性好，通常延迟在秒级以内；支持断点续传，可靠性高；对业务代码无侵入，源库只需开启binlog。缺点是需要维护Kafka、Debezium和消费者三组组件，运维成本不低，并且要处理schema演进，比如MySQL增加字段时，PostgreSQL端也要自动ALTER TABLE。
此外，数据类型映射是常见坑点。例如MySQL的DATETIME与PostgreSQL的TIMESTAMP含义略有不同，MySQL的TINYINT(1)常被误当作布尔值。消费者中必须显式声明转换规则，否则会出现写入失败或数据偏差。
三、使用逻辑复制与中间桥接
如果源库是PostgreSQL，目标库是MySQL，可以利用PostgreSQL的逻辑复制输出插件（如pgoutput），配合一个桥接程序将逻辑变更翻译成MySQL语法。由于MySQL没有内建消费逻辑复制流的能力，桥接程序需使用libpq的复制协议接收WAL变更。
下面是一段Python示例，展示如何通过逻辑解码槽读取PostgreSQL变更，并构造MySQL的REPLACE语句实现幂等写入。
import psycopg2
# 建立逻辑复制连接
conn = psycopg2.connect("dbname=src user=replicator")
cur = conn.cursor()
cur.start_replication(slot_name='bridge_slot', decode=True)
def handle_change(msg):
change = parse_logical(msg.payload) # 解析逻辑变更
for row in change.rows:
if change.op == 'INSERT':
# 构造MySQL的REPLACE以实现幂等
sql = build_replace(change.table, row.new)
mysql_execute(sql)
msg.cursor.send_feedback(flush_lsn=msg.data_start)
cur.consume_stream(handle_change)
3.1 性能与一致性考量
该方式避免了消息队列中转，链路更短，延迟可能更低。但桥接程序是单点，需要自己实现高可用和位点持久化。一致性方面，由于跨库无法用分布式事务，建议只在允许最终一致的场景使用，并对关键表增加校验任务，定期比对两端行数或哈希。
对于双向同步，要特别防范循环复制：A库变更同步到B库，B库的写入又触发回A库。可通过在变更事件中打上来源标记，或在目标端关闭触发器与binlog记录来规避。
四、字段类型与DDL同步策略
在真实项目中，表结构不是一成不变的。MySQL的ALTER TABLE会写binlog，Debezium可捕获到结构变更事件；而PostgreSQL的逻辑复制不传递DDL，需要额外用迁移工具（如Flyway）在两端顺序执行。
推荐的策略是：所有DDL先在与业务解耦的迁移脚本中定义，源库执行后，通过事件通知目标库执行等价DDL。字段类型映射表应作为配置外置，例如将MySQL的VARCHAR(255)映射为PostgreSQL的VARCHAR(255)，将JSON映射为JSONB，减少手工干预。
4.1 常见类型映射示例
| MySQL类型 | PostgreSQL类型 | 注意点 |
|---|---|---|
| INT | INTEGER | 范围一致 |
| BIGINT | BIGINT | 无符号需转NUMERIC |
| TEXT | TEXT | 直接对应 |
| DECIMAL(10,2) | NUMERIC(10,2) | 精度需显式声明 |
上表列出了部分基础映射。实际同步中，建议先在小表验证类型转换，再推广到核心业务表，避免大字段或特殊字符集导致目标端报错。
五、监控与断点恢复
实时同步系统必须可观测。对于MySQL源，应监控binlog留存时间，防止消费滞后导致日志被清理而无法续传。对于PostgreSQL，要监控复制槽的已确认LSN与当前LSN的差距。
断点恢复时，MySQL使用GTID集合或binlog文件名加位置；PostgreSQL使用slot的confirmed_flush_lsn。以下命令可查看PostgreSQL复制槽状态：
SELECT slot_name,
confirmed_flush_lsn,
pg_current_wal_lsn()
FROM pg_replication_slots;
当发现差距持续扩大，说明消费者处理慢，需要增加并发写入线程或优化目标库索引。切忌在同步表上建过多索引，因为每次变更都要维护索引，会拖慢应用端吞吐量。
六、总结与实践建议
MySQL与PostgreSQL的实时同步没有银弹。若团队已有Kafka，Debezium方案最成熟；若追求轻量，可用逻辑复制加自研桥接。无论哪种，都要把类型映射、DDL处理和监控当做一等公民来设计。
起步阶段可挑选一张只读报表表做双向验证，观察延迟与错误日志，再逐步覆盖交易类数据。只要变更捕获与写入应用解耦清晰，即使后端数据库替换，同步层也无需推倒重来。
MySQLPostgreSQLdata_replication修改时间：2026-08-05 05:54:16