bigywater.tech
MySQL / InnoDB · 91

主从复制初始化

从零真实搭建一主一从的复制关系,验证从配置命令到数据真实同步的完整闭环是怎么跑通的。

0秒延迟
真实的Seconds_Behind_Source
完整重放
从GTID起点真实重放了全部历史DDL和数据

做的事:真实起两个独立的MySQL实例,从零配置复制

代码-- source:server-id=1,开binlog+GTID mysqld --server-id=1 --log-bin=source-bin --gtid-mode=ON --enforce-gtid-consistency=ON ... -- replica:server-id=2,同样开binlog+GTID(自己也要能产生GTID记录本地事件) mysqld --server-id=2 --log-bin=replica-bin --gtid-mode=ON --enforce-gtid-consistency=ON ... -- source上真实建复制专用账号 CREATE USER 'repl'@'%' IDENTIFIED BY 'ReplPass123!'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';

验证:真实配好连接信息,一条命令启动复制

代码(在replica上执行)CHANGE REPLICATION SOURCE TO SOURCE_HOST='127.0.0.1', SOURCE_PORT=19310, SOURCE_USER='repl', SOURCE_PASSWORD='ReplPass123!', SOURCE_AUTO_POSITION=1; START REPLICA;
实测 · 本机SHOW REPLICA STATUS真实输出
Source_Host: 127.0.0.1        Source_Port: 19310
Replica_IO_Running: Yes       Replica_SQL_Running: Yes
Last_Error: (空)             Seconds_Behind_Source: 0
Auto_Position: 1

两个线程都真实显示Yes,没有任何错误——SOURCE_AUTO_POSITION=1真实是关键的一步,它让replica用GTID自动判断"我应该从source的哪个位置开始拉取",不需要像传统复制那样手动去查、手动指定binlog文件名和偏移量。

验证:source写的数据,真实立刻出现在replica上

实测 · 本机执行输出
-- source
CREATE DATABASE shop;
CREATE TABLE shop.orders (id INT PRIMARY KEY AUTO_INCREMENT, item VARCHAR(50), qty INT);
INSERT INTO shop.orders (item, qty) VALUES ('apple', 10), ('banana', 5);

-- replica(几乎同时查询)
SELECT * FROM shop.orders;
→ 1  apple   10
  2  banana  5     ← 真实一模一样,包括数据库和表结构本身也是复制过来的
这次真实搭建从头到尾没有用mysqldump导初始快照——因为replica是全新初始化的空实例,从GTID的起点(1)开始复制,source上所有的历史操作(包括CREATE DATABASE、CREATE TABLE这些DDL)都真实作为binlog事件的一部分被重放了一遍。真实的生产环境里,如果source已经运行了很久、积累了大量历史数据,通常需要先用mysqldump或者Clone Plugin(后面文章会讲)做一次一致性快照,再从快照对应的GTID位置开始接上增量复制,而不是从头重放全部历史。

分步演示:从两个空实例到数据真实同步的完整过程

每一步都是本文上面用真实两节点复制环境跑出来的原始结果。

从零到一,一次真实的复制闭环
这一步新完成的配置

    本文用到的工具

    • 本机真实搭建的独立复制实验环境:两个MySQL 26.7.0实例(source端口19310,replica端口19311),全程未使用共享的生产实例
    • CHANGE REPLICATION SOURCE TO ... SOURCE_AUTO_POSITION=1 + START REPLICA
    京ICP备2026067502号-1京公网安备11010502063487号