MySQL 异步主从复制配置过程和原理

一、环境

1. 介绍：生成环境中几乎没有 MySQL 单例支撑整个业务，由 MySQL 集群多台 MySQL 实例共同支撑，MySQL 集群技术分为两种，一种为 MySQL 原生的主从复制，直接配置即可，还有一种就是依赖插件的 MySQL 高可用解决方案如：MHA 等。
2. 操作系统 MacOS 下使用虚拟机 CentOS7 三台 MySQL 5.7+ 实例

二、配置条件

1. 主从实例之前网络互通 3306 端口开放；
2. 专用的复制用户，拥有对应的复制权限；
3. 主库开启 binlog 日志，主从 Server-id 独立；
4. 主从数据库起点相同(开启前保证数据一致);
5. 从库开启专用到复制线程，并且正常运行。

三、配置过程

1. 接下来模拟刚刚装好的三台 MySQL 实例配置传统的主从复制环境，首先检查系统防火墙 3306 端口是否打开，如果没有打开那么就无法从 3306 端口连接数据库。

   # 直接关闭防火墙（慎用）或将 3306 添加到开放端口配置中
   systemctl stop firewalld.service
   

2. 主库配置 binlog 日志，并重启 MySQL 数据库。

   vi /etc/my.cnf
   

   # 设置 server-id
   server-id=1
   # binlog 存储路径
   log-bin=/var/log/binlogs/mysql-bin
   # binlog 刷写策略
   sync-binlog=1
   # binlog 刷写格式
   binlog-format=row
   # binlog 文件存储大小
   max_binlog_size=1G
   

   binlog 配置参数如上，具体需求可以自行修改，可能会需要的问题就是 binlog 目录没有权限导致 MySQL 关闭后无法启动，需要设置目录权限给 MySQL。

   chown -R mysql.mysql /var/
   

   然后配置或者检查从库的 server-id 是否不同，如果相同需要在配置中修改。

   select @@server_id;
   

   @@server_id
   3

3. 从库配置主库的连接信息。

   help change master to\G
   

   使用如上命令会输出很多信息，对配置真正有用的如下(配置模版)：

   CHANGE MASTER TO
     MASTER_HOST='master2.example.com',
     MASTER_USER='replication',
     MASTER_PASSWORD='password',
     MASTER_PORT=3306,
     MASTER_LOG_FILE='master2-bin.001',
     MASTER_LOG_POS=4,
     MASTER_CONNECT_RETRY=10;
   

   接下来我们只需要对 change master to 进行修改即可完成配置。

   MASTER_HOST：主库地址(必填)
   MASTER_USER：主库复制用户名(必填)
   MASTER_PASSWORD：密码(必填)
   MASTER_PORT：端口(必填)
   MASTER_LOG_FILE：主库 binlog 文件(必填)
   MASTER_LOG_POS：文件偏移量(必填)
   MASTER_CONNECT_RETRY：重连睡眠时间

   可以看到配置过程中需要得到主库的连接信息和 binlog 日志数据，数据同步过程中如果使用 mysqldump 将主库数据迁移那么通过设置 master-data 参数就可以得到主库的 binlog 信息。或者主库直接使用 show master status ; 即可得到 MASTER_LOG_FILE 和 MASTER_LOG_POS 的参数结果，前提是主从配置前数据已经是同步状态，如果不是那么需要先使用备份进行同步。

   show master status ;
   

   File	Position	Binlog_Do_DB	Binlog_Ignore_DB	Executed_Gtid_Set
   mysql-bin.000001	783727

   上表为我测试使用的数据库 binlog 位置点信息，通过上表修改 change master to；

   CHANGE MASTER TO
   MASTER_HOST='172.16.177.128',
   MASTER_USER='rep',
   MASTER_PASSWORD='XHUWNFWIUDNEI@',
   MASTER_PORT=3306,
   MASTER_LOG_FILE='mysql-bin.000001',
   MASTER_LOG_POS=783727,
   MASTER_CONNECT_RETRY=10;
   

   -- 开启专用的复制线程
   start slave
   

   修改完 change master to 后，分别在每个从库运行并启动专用的复制线程，即可。

四、验证主从环境

1. 介绍：如何确定自己的主从环境搭建完成，主库有可以通过 show processlist ; 看到 binlog dump 线程的状态，从库可以通过 show slave status; 查看 IO Thread 和 SQL Thread 的状态信息。

2. 主库：查看主从复制状态

   show processlist ;
   

   Id	User	Host	db	Command	Time	State	Info
   2	cooh	172.16.177.1:51308	NULL	Sleep	54917		NULL
   3	rep	172.16.177.129:54836	NULL	Binlog Dump	61010	Master has sent all binlog to slave; waiting for more updates	NULL
   5	rep	172.16.177.130:60158	NULL	Binlog Dump	60931	Master has sent all binlog to slave; waiting for more updates	NULL

   -- 查看从库的连接信息
   show slave hosts;
   

   Server_id	Host	Port	Master_id	Slave_UUID
   3		3306	1	ecd6a9b5-ca59-11ea-a191-000c299d422b
   2		3306	1	d21deb80-ca58-11ea-b7c5-000c299fe687

3. 从库：查看主从环境状态信息

   show slave status\G
   

   
   从库查看主从环境主要看两个线程是否正常运行

   Slave_IO_Running: Yes
   Slave_SQL_Running: Yes
   

五、主从复制原理

1. 介绍：主从环境主要依赖三个线程资源和四个文件资源，我们将分别介绍。
2. 线程资源：
   主库：binlog dump 线程，负责截取 binlog 数据发送给从库；
   从库：IO Thread 线程，负责接收主库发送的 binlog 数据，然后存储到主库 relay log 文件中；
   从库：SQL Thread 线程，负责回放 relay log 中的 SQL 语句。
3. 文件资源：
   主库：binlog 日志；
   从库：relay log 存储接收到主库的 binlog 数据；
   从库：Master.info 存储主库的连接信息和接收到 binlog 的位置信息；
   从库：relay log.info 记录 SQL 线程回放 relay log 的位置点。
4. 过程：主从复制的过程就由这几个资源和线程相互配合完成，架构图如下：
   
5. 传统主从复制的过程（主库发生变化后发送信号给从库，从库主动发起复制）
   1. 从库：通过 Master.info 中的连接信息和主库 binlog 位置点信息由 Slave IO 线程向主库发送请求；
   2. 主库：通过从库发送的位置点信息截取 binlog 日志，由 binlog dump 线程发送给从库；
   3. 从库：接收到 binlog 日志后，由 Slave IO 线程将数据存储到从库的 relay-log.00000N 文件中，并更新 Master.info 中的位置点信息。
   4. 从库：由 Slave SQL 线程回放从库中 relay-log.00000N 中的日志数据，并更新 relay-log.info 文件中的位置点信息。

六、主从复制故障

• 以下是配置过程或运行过程中可能会发送的故障：
  1. 网络问题，如未开放 3306 端口，SSH 可以连接到实例，无法通过 3306 端口连接；
  2. 从库的 MySQL 实例直接克隆主库，或者直接拷贝，导致数据库 uuid 相同；
  3. 主库最大连接数达到峰值，无法连接主库 max_connections；
  4. 主从库之间存在版本差异，密码解析方式不同，导致无法连接。