【Linux 34】Linux-主从复制

一、主从复制基础知识

在 标准的 MySQL 主从复制架构 中，主从复制默认是单向的，且遵循 “主库可写、从库只读” 的核心原则。

1.作用

• 避免数据库单点故障，实现高可用作用
• 实现多个MySQL间的数据一致
• 读写分离：主库负责写操作，从库承担读操作
• 数据备份：从库可作为主库的实时备份，避免备份操作对主库性能的影响（如锁表

2.工作原理

1. 主从复制的核心是通过二进制日志（binlog）实现数据同步，完整流程如下：

（1）主库生成 binlog：主库执行写操作（增删改）后，会将操作以事件（event）形式记录到二进制日志中，并维护一个 binlog 索引文件（.index）记录所有 binlog 文件列表。

（2）从库 I/O 线程连接主库：从库启动后，从库的I/O 线程会根据配置的主库信息（IP、用户、密码）建立 TCP 连接，请求主库发送 binlog。

（3）主库 dump 线程响应：主库接收到从库请求后，启动 dump 线程，根据从库指定的 binlog 文件名和位置，将后续的 binlog 事件推送给从库（或从库主动拉取）。

（4）从库写入中继日志：从库 I/O 线程将接收到的 binlog 事件写入本地中继日志（Relay log），并记录当前同步到的 binlog 位置（便于中断后继续同步）。

（5）从库 SQL 线程执行同步：从库 SQL 线程读取中继日志中的事件，按顺序在从库中重新执行（模拟主库的写操作），最终保证主从数据一致。

核心：数据一致、同步

存在的问题：时间复制延迟（不能过大）（无法避免）

① 延迟原因

• 网络延迟：主从库跨机房或网络带宽不足，导致 binlog 传输缓慢。
• 主库写入密集：主库短时间内大量写操作（如批量插入），binlog 生成速度超过从库同步速度。
• 从库负载过高：从库同时承担大量查询或其他任务，导致 SQL 线程执行缓慢。
• 大事务影响：主库执行长事务（如耗时 10 分钟的更新），从库需等整个事务 binlog 传输完成后才能执行，造成一次性延迟。
• 参数配置不合理：如从库 innodb_buffer_pool_size 过小，导致 SQL 线程执行时频繁磁盘 IO。

② 解决方法（详细措施）

• 优化网络：主从库部署在同一机房，增加网络带宽（使用万兆网络）；通过压缩 binlog（MySQL 8.0 支持 binlog 压缩）减少传输量。
• 从库性能升级：提升从库硬件配置（如使用高IO的磁盘，SSD），避免从库承担非必要查询。
• 并行复制：MySQL 5.6 + 支持基于库的并行复制，MySQL 5.7 + 支持基于组提交的并行复制，让 SQL 线程多线程并行执行，缩短同步时间。
• 拆分大事务：将主库大事务拆分为多个小事务，避免单次同步阻塞。
• 半同步复制：主库开启半同步复制（需安装插件），确保至少一个从库接收 binlog 后，主库才返回写操作成功，减少数据丢失风险（但会增加主库写延迟，需权衡）。
• 监控延迟并告警：通过 Seconds_Behind_Master 监控延迟，超过阈值（如 10 秒）时告警，及时排查。

3.常见复制架构

1.一主一从

2.一主多从

3.双主复制：双向的主从复制（两个主句库互为对方的主从，两个数据库都可以执行写操作并且都可以复制给对方）

二、主从复制的配置

（一）一主一从

前提配置：两个机子，不同ip和Mysql数据库。

关闭SELinux、时间同步

1、主库配置

（前提：主从库 MySQL 版本一致，建议 8.0+）

①开启二进制日志       //编辑主库配置文件（my.cnf ，之后systemctl restart mysqld重启

② 登录主库 ，创建允许从库连接的用户（限制从库 IP，增强安全性

• >CREATE USER '用户名'@'从库IP' IDENTIFIED WITH mysql_native_password BY '123456';
• //创建用户（repl为用户名，从库IP替换为实际地址）
• //明确使用mysql_native_password函数  便于从库连接
• >GRANT REPLICATION SLAVE ON *.* TO '用户名'@'从库IP';        //授权复制权限
• 这是 MySQL 专门用于主从复制的权限，作用只有一个 —— 允许客户端（从库 IO 进程）连接主库，拉取主库的二进制日志（binlog），没有其他任何权限。
• 用户被限制在 “从库 IP” 登录，登录主体是 “从库进程”，不是人，权限仅够 “复制”，无其他权限。
• >FLUSH PRIVILEGES;            // 刷新权限
• 

③主库完全备份               //master-data=2会在备份文件中记录binlog文件名和位置

• # mysqldump -uroot -p --all-databases --master-data=2 --single-transaction > full_backup.sql
• # mysqldump -uroot -p --lock-all-tables --source-data=2 --all-databases > /Log/data.sql
• //替换过时的 --master-data 为 --source-data
  --single-transaction 是 “快照读”（适合 InnoDB，不阻塞写），--lock-all-tables 是 “全局锁”（适合全引擎，阻塞写）。
  
  

备份文件中会包含类似如下记录（后续从库需用到）：
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;

• 检查
• (1)基础检查
• # ls -lh /Log/data.sql         //输出中能看到该文件
• # du -sh /Log/data.sql       //正常备份文件大小应 远大于 0 字节
• # head -n 20 /Log/data.sql      //正常的 MySQL 备份文件头部会包含版本信息和备份参数
• 
• (2)深度检查

• 创建临时数据库（测试用）

• # mysql -uroot -p         //登录MySQL

• >CREATE DATABASE test_backup; exit;          //创建测试库

• 恢复备份到测试库

• # mysql -uroot -p test_backup < /Log/data.sql     //将备份文件恢复到test_backup库

• // 若恢复过程无报错（如 “语法错误”“表已存在” 等），说明备份文件无损坏。

• 验证恢复的数据

• # mysql -uroot -p test_backup      //登录测试库，检查关键表和数据是否完整

• >SHOW TABLES;     //查看库中表是否存在

• >SELECT COUNT(*) FROM user;      //查看表数据量（与原库对比）

• >SELECT * FROM user WHERE username = 'admin';     //查看具体数据（与原库对比）

• // 若表结构、数据量、具体记录与原库一致，说明备份完全有效。

• # scp /opt/data.sql root@从库ip:/opt/           //将备份文件拷贝到从库

2、从库配置

用从库的普通账号登录 MySQL，该账号没有 SUPER、REPLICATION_SLAVE_ADMIN 等权限，无法执行 CHANGE MASTER TO、START SLAVE 等复制操作，提示 Access denied。
解决：改用从库的 root 账号（拥有最高权限）操作，才能执行复制配置命令。

前提：安装Mysql并设置开启自启动

①配置从库基础参数             //编辑从库配置文件并且重启,修改密码

MySQL 主从复制要求主库和从库的 server_id 必须唯一（用于识别主从身份）

②从库恢复主库的备份          //将主库的 /opt/data.sql 复制到从库，恢复数据

• # mysql -u root -p < /opt/data.sql

③从库连接主库         //登录从库 MySQL，设置主库信息（备份文件中的 binlog 文件名和位置）

去10机子搜

• # head -n 100 /Log/data.sql | grep "CHANGE MASTER TO"      
• 此记录通常位于备份文件的 前 100 行内（因为--source-data=2 或 --master-data=2参数会在备份开头记录主库的 binlog 位置），可以直接查看文件头部

④启动从库复制线程

• >START SLAVE;         //启动I/O线程和SQL线程

⑤验证复制线程启动成功            //查看复制线程（IO线程和SQL线程）的状态

• >SHOW SLAVE STATUS\G;

若异常

// 通过这两个值的差，判断数据是否一致    数字一样就是同步了，不一样就是延迟很大

>SHOW SLAVE HOSTS;     //在主库上查看连接的从库信息验证

（二）双主复制

1、基础配置（两台服务器均需设置）

• vim /etc/my.cnf

2、互相授权复制用户

3、配置双向复制

4、验证双主复制状态

二、基于 GTID 的主从复制

（一）GTID介绍

        GTID（Global Transaction Identifier，全局事务 ID）是 MySQL 5.6 及以上版本引入的核心特性，用于替代传统基于 “binlog 文件名 + 位置” 的复制方式，从根本上简化主从复制的配置、故障切换和数据一致性校验。

① 核心构成

GTID 由两部分组成，格式为 uuid:id

• server_uuid：主库的唯一标识（MySQL 实例初始化时自动生成，存储在 auto.cnf 文件中），确保不同主库的事务不会产生 ID 冲突。
• transaction_id：主库上事务的自增编号（从 1 开始累加），同一主库内每个事务的编号唯一，可直观反映事务执行顺序。

② GTID 的核心优势（对比传统复制）

（二）基于 GTID 的主从复制部署全流程

1、前置准备

环境清理与基础检查（主库、从库均执行）

① 停止 MySQL 服务

• # systemctl stop mysqld 

② 清理现有数据目录（若为全新部署，或需重置主从关系）

• # mv /var/lib/mysql /var/lib/mysql_bak         //先备份重要数据（生产环境可选）
• # mkdir -p /var/lib/mysql        //重建空数据目录并授权
• # chown -R mysql:mysql /var/lib/mysql

③ 检查 MySQL 版本

• # mysqld --version           // 输出需包含 "5.6." 及以上版本

2、主库

① 配置

• # vim /etc/my.cnf       //配置主库 my.cnf（先修改配置文件）

[mysqld]
# 基础配置（确保主从库唯一）
server-id = 10  # 主库ID，从库需不同（如20）
datadir = /var/lib/mysql
socket = /var/lib/mysql/mysql.sock# GTID核心配置（必选）
gtid_mode = ON  # 启用GTID模式
enforce_gtid_consistency = true  # 强制GTID事务一致性（防止非GTID事务干扰）
log_slave_updates = ON  # 从库同步时也记录binlog（用于级联复制或主从切换，必选）# binlog配置（GTID依赖binlog，需开启）
log_bin = master-bin  # binlog日志文件名前缀
binlog_format = ROW  # 推荐ROW格式（避免SQL_MODE差异导致的同步问题）
expire_logs_days = 7  # binlog保留7天，避免磁盘占满# 其他优化配置（可选）
max_connections = 1000
innodb_flush_log_at_trx_commit = 1  # 事务安全优先
sync_binlog = 1

② 启动主库服务（配置文件修改后必须先启动，否则无法登录 MySQL 创建用户）

• # systemctl start mysqld         //因为之前删除了，所以要重新设置初始化密码
• # grep 'temporary password' /var/log/mysqld.log
• # mysql -uroot -p        

③ 创建复制用户并授权

3、 从库

① 配置

• vim /etc/my.cnf       //配置主库 my.cnf（先修改配置文件）

[mysqld]
# 基础配置（server-id需与主库不同）
server-id = 20  # 从库唯一ID
datadir = /var/lib/mysql
socket = /var/lib/mysql/mysql.sock# GTID核心配置（与主库一致）
gtid_mode = ON
enforce_gtid_consistency = true
log_slave_updates = ON  # 若从库未来需作为主库，此配置必选# binlog与relay log配置
log_bin = slave-bin  # 从库也需开启binlog（用于主从切换）
relay_log = slave-relay-bin  # 中继日志文件名前缀
read_only = ON  # 从库设为只读（super用户可写，生产推荐）
super_read_only = ON  # MySQL 8.0+新增，限制super用户写操作（更严格）# 其他优化配置（与主库保持一致）
max_connections = 1000
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1

② 启动从库服务（配置文件修改后必须先启动，否则无法登录 MySQL 创建用户）

• # systemctl start mysqld         //因为之前删除了，所以要重新设置初始化密码
• # grep 'temporary password' /var/log/mysqld.log
• # mysql -uroot -p        

③ 配置主从连接并启动复制

4、验证 GTID 配置生效（主从库均执行）

• # mysql -uroot -p -e "SHOW VARIABLES LIKE '%gtid%';"
• //需看到 gtid_mode = ON，enforce_gtid_consistency = ON

5、 复制状态验证：确认 GTID 同步正常

• # mysql -uroot -p -e "SHOW SLAVE STATUS\G"

三、读写分离

（一）读写分离介绍

1、作用

• 加快数据库工作效率
• 在主从复制环境 ，主库执行写操作，从库执行读操作，写操作（如订单创建）和读操作（如数据分析）在不同库执行，避免长查询阻塞事务提交。尤其适合读多写少场景（如电商商品详情页、新闻资讯）。
• 提升查询性能：多从库可分担读请求（横向扩展），用户查询可被分发到不同从库，减少单库负载。

2、实现方案

（二）前置环境准备

ProxySQL

        核心功能：读写分离、 支持基于 “用户、Schema（数据库）、SQL 语句特征” 的多层路由、结果缓存（减轻后端压力）、健康状态检测（保障高可用）

1、环境描述

192.168.140.10 作为主库 MySQL 8.0
192.168.140.20 作为从库 MySQL 8.0
192.168.140.30 作为 proxysql

2、基础配置

（1）主库（192.168.140.10）、从库（192.168.140.20）已完成主从复制。

（2）从库已添加read_only参数（避免从库写入）。

   ①临时

• # mysql -uroot -pRoot@548165 -h192.168.140.11
• >SET GLOBAL read_only = 1;    //开启只读模式（限制普通用户写入，root 等超级用户仍可写入）
• >SET GLOBAL super_read_only = 1;       //同时开启 `super_read_only`，限制超级用户写入

      ②永久        

• read_only=1   // 限制非超级用户（没有 SUPER 权限的普通用户）执行写入操作
• super_read_only=1   //MySQL 8.0+ 新增在 read_only=1 的基础上，进一步限制超级用户（包括 root）执行写入操作，实现 “彻底只读”。
• >SELECT @@read_only, @@super_read_only;       //查看当前只读状态

3、30机安装proxysql并启动

cat > /etc/yum.repos.d/proxysql.repo << EOF
[proxysql]
name=ProxySQL YUM repository
baseurl=https://repo.proxysql.com/ProxySQL/proxysql-2.6.x/centos/\$releasever
gpgcheck=1
gpgkey=https://repo.proxysql.com/ProxySQL/proxysql-2.6.x/repo_pub_key
EOF

• # yum clean all      //清理 YUM 缓存
• // 当 YUM 源配置修改后（如更换了 proxysql.repo 内容），旧缓存可能导致 YUM 读取到过时的源信息，从而安装失败或版本错误；清理缓存可以释放磁盘空间（尤其是长期使用的服务器，缓存的 .rpm 文件可能占用较多空间）。
• # yum makecache   //生成 YUM 缓存
• // YUM 安装软件时，需要先读取软件包的元数据来确认版本、依赖等信息。makecache 提前将这些信息缓存到本地，后续安装时无需重复从网络获取，加快操作速度；在修改 YUM 源配置后（如添加了 ProxySQL 源），执行 makecache 可以让新配置的源立即生效，确保能获取到对应的软件包列表。
• # yum install -y proxysql mariadb    

• // ProxySQL 本身是中间件，不自带 mysql 客户端工具。而后续配置 ProxySQL 时，必须使用 mysql 客户端工具。mariadb 包提供的 mysql 命令与 MySQL 客户端完全兼容，因此在安装 ProxySQL 时，通常会一并安装 mariadb 以满足后续操作需求。
• # systemctl enable --now proxysql     //启动

• netstat -tunlp | grep proxysql      //验证端口监听（6032=管理端，6033=业务端）

• 6032端口: proxysql管理端口，管理和配置 ProxySQL，或查看其运行状态与统计信息等。
• 6033端口: proxysql业务连接端口，是 ProxySQL 面向应用程序提供数据库服务的端口。

proxysql的后台

• # mysql -uadmin -padmin -h127.0.0.1 -P6032        //连接 ProxySQL 管理端口 ，默认账号admin 密码：admin，端口：6032
• > show databases;        //ProxySQL 内置的核心库

4、主库

①创建 ProxySQL 授权用户（192.168.140.10）

 ②主库上配置健康用户

5、ProxySQL 管理端（6032 端口）

配置后端数据库、用户、路由规则

核心步骤：添加服务器组 → 配置连接用户 → 健康检查 → 读写路由。

（1）添加后端数据库服务器

//（区分读写组）

（2）配置连接后端数据库的用户

// username 和 password 必须与主库（及从库）中实际存在的用户完全一致

（3）配置健康检查用户

//（监控后端数据库状态）

（4）添加读写分离路由规则

• 规则 1：SELECT ... FOR UPDATE（行锁查询）→ 路由到写组（主库）
• 规则 2：普通 SELECT → 路由到读组（从库）

6、读写分离测试

•  # mysql -upart -pPart@548165 -h127.0.0.1 -P6033  // 连接 ProxySQL 业务端口

①写/读操作

②  验证读写分离效果（ProxySQL 管理端）

• >mysql -uadmin -padmin -h127.0.0.1 -P6032       // 注意参数间无特殊字符

• SELECT hostgroup, digest_text FROM stats.stats_mysql_query_digest;   //查询 stats 库中表

7、WordPress 配置 ProxySQL 连接

修改 WordPress 配置文件 wp-config.php，将数据库连接指向 ProxySQL 业务端（192.168.140.12:6033）

验证 WordPress 连接

1. 访问 WordPress 前端页面，确认能正常加载；
2. 在 WordPress 后台发布一篇文章（写操作，路由到主库）；
3. 前端刷新页面查看文章（读操作，路由到从库）；
4. 通过 ProxySQL 管理端 stats_mysql_query_digest 确认路由记录。