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.0

log-error=/data/my/myroot15/mydata1501/mysql.err
log-bin=/data/my/myroot15/mydata1501/mysql-bin
server-id=1
gtid-mode=ON
enforce-gtid-consistency=ON

default-storage-engine=InnoDB
innodb_buffer_pool_size=256M
innodb_log_file_size=64M
innodb_flush_log_at_trx_commit=1

sql_mode=STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION
character-set-server=utf8mb4
collation-server=utf8mb4_general_ci

max_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.0

log-error=/data/my/myroot15/mydata1502/mysql.err
relay_log=relay-bin
server-id=2
read-only=1
gtid-mode=ON
enforce-gtid-consistency=ON

default-storage-engine=InnoDB
innodb_buffer_pool_size=256M
innodb_log_file_size=64M
innodb_flush_log_at_trx_commit=1

sql_mode=STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION
character-set-server=utf8mb4
collation-server=utf8mb4_general_ci

max_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 TO
  SOURCE_HOST='127.0.0.1',
  SOURCE_PORT=1501,
  SOURCE_USER='root',
  SOURCE_PASSWORD='',
  SOURCE_AUTO_POSITION=1;

-- 创建复制槽（旧）
CHANGE REPLICATION SOURCE TO
  SOURCE_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 TO
  SOURCE_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 文件和位置。