mysql主备配置（对比postgresql）
mysql主备对比postgresql主备
mysql主流模式是逻辑复制，下面的区别其实就是逻辑和物理复制的区别。
mysql
- 灵活、生态成熟、跨版本兼容，当前业界CDC与异构同步的事实标准。
- 一致性较弱，事务粒度同步延迟高。
pgsql
- 一致性强、延迟低，适合同构环境数据订阅；
- 灵活性差、生态不完善、对版本和 slot 管理要求高。
mysql8主备配置实例
主库
关键参数
- log-bin=/data/my/myroot15/mydata1501/mysql-bin
- server-id=1
- gtid-mode=ON
- enforce-gtid-consistency=ON
[mysqld]
basedir=/data/my/myroot15/myhome
datadir=/data/my/myroot15/mydata1501
socket=/data/my/myroot15/mydata1501/mysql.sock
pid-file=/data/my/myroot15/mydata1501/mysql.pid
port=1501
bind-address=0.0.0.0log-error=/data/my/myroot15/mydata1501/mysql.err
log-bin=/data/my/myroot15/mydata1501/mysql-bin
server-id=1
gtid-mode=ON
enforce-gtid-consistency=ONdefault-storage-engine=InnoDB
innodb_buffer_pool_size=256M
innodb_log_file_size=64M
innodb_flush_log_at_trx_commit=1sql_mode=STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION
character-set-server=utf8mb4
collation-server=utf8mb4_general_cimax_connections=200
table_open_cache=400
tmp_table_size=64M
max_allowed_packet=64M[client]
port=1501
socket=/data/my/myroot15/mydata1501/mysql.sock
user=root
备库
关键参数
- relay_log=relay-bin
- server-id=2
- read-only=1
- gtid-mode=ON
- enforce-gtid-consistency=ON
[mysqld]
basedir=/data/my/myroot15/myhome
datadir=/data/my/myroot15/mydata1502
socket=/data/my/myroot15/mydata1502/mysql.sock
pid-file=/data/my/myroot15/mydata1502/mysql.pid
port=1502
bind-address=0.0.0.0log-error=/data/my/myroot15/mydata1502/mysql.err
relay_log=relay-bin
server-id=2
read-only=1
gtid-mode=ON
enforce-gtid-consistency=ONdefault-storage-engine=InnoDB
innodb_buffer_pool_size=256M
innodb_log_file_size=64M
innodb_flush_log_at_trx_commit=1sql_mode=STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION
character-set-server=utf8mb4
collation-server=utf8mb4_general_cimax_connections=200
table_open_cache=400
tmp_table_size=64M
max_allowed_packet=64M[client]
port=1502
socket=/data/my/myroot15/mydata1502/mysql.sock
user=root
常用命令
SHOW MASTER STATUS;
SHOW REPLICA STATUS\G
START REPLICA;-- 跳过当前gtid
set gtid_next='a9b61050-be16-11f0-a2c1-5254001952d8:1'-- 查看复制错误
select * from performance_schema.replication_applier_status_by_worker\G-- 创建复制槽（新）
CHANGE REPLICATION SOURCE TOSOURCE_HOST='127.0.0.1',SOURCE_PORT=1501,SOURCE_USER='root',SOURCE_PASSWORD='',SOURCE_AUTO_POSITION=1;-- 创建复制槽（旧）
CHANGE REPLICATION SOURCE TOSOURCE_HOST='127.0.0.1',SOURCE_USER='root',SOURCE_PASSWORD='',SOURCE_LOG_FILE='mysql-bin.000003',SOURCE_LOG_POS=154;
GTID
旧机制（非 GTID 模式）
传统主从复制是这样工作的：
主库写 binlog：mysql-bin.000003, position=154
从库通过：
CHANGE REPLICATION SOURCE TOSOURCE_LOG_FILE='mysql-bin.000003',SOURCE_LOG_POS=154;
告诉主库：从这个文件的这个位置开始拉取事件。
IO 线程开始从这个偏移点读事件（Event），并写入 relay log。
这种方式的问题是：
一旦主库切换（比如做 failover），新的主库 binlog 文件名和 pos 都不同；你必须重新人工指定从哪里开始同步；如果复制链较复杂，维护成本很高；容易出错（指定错文件或 pos，数据错乱或重复）。
GTID 模式的核心思想
每个事务都有一个全局唯一ID：GTID = server_uuid:transaction_id
例如：
主库A: 3E11FA47-71CA-11E1-9E33-C80AA9429562:100
主库B: 9E88CC47-88BB-44EE-9E33-AB01CC3321FF:27
主库记录：每个事务写入 binlog 时都会带上：
SET @@SESSION.GTID_NEXT=‘3E11FA47-71CA-11E1-9E33-C80AA9429562:100’;
从库执行：从库在执行时会维护一个集合：
Executed_Gtid_Set: a9b61050-be16-11f0-a2c1-5254001952d8:1-4
从库启动时，会从本地的 mysql.gtid_executed 表加载它执行过的所有 GTID 集；
连上主库后，发送自己的 Executed_Gtid_Set 给主库；
主库计算：要发送的事务 = 主库所有GTID集合 - 从库已执行集合
主库自动只推送缺的那些事务。
具体例子：
事务 主库 GTID 从库执行情况
trx1 UUID:1 已执行
trx2 UUID:2 已执行
trx3 UUID:3 ❌ 未执行
当从库重连时，它告诉主库：
I have UUID:1-2
主库比对：
I have UUID:1-3
于是主库只发 UUID:3 对应的事务。无需文件名、无偏移量，直接按逻辑事务集合同步。
所以，GTID后不需要手动指定 binlog 文件和位置。