1 主从复制目的

主从复制，是指建立一个和主数据库完全一样的数据库环境（称为从数据库），并将主库的操作行为进行复制的过程。将主数据库的DDL和DML的操作日志同步到从数据库上，然后在从数据库上对这些日志进行重新执行，来保证从数据库和主数据库的数据的一致性

（1）保证数据的热备份，主库宕机后能够及时替换主库，保障业务可用性

（2）在复杂的业务操作中，经常会有操作导致锁行甚至锁表的情况，如果读写不解耦，会很影响运行中的业务，使用主从复制，让主库负责写，从库负责读。即使主库出现了锁表的情景，通过读从库也可以保证业务的正常运行

主从复制分为：异步复制（不关心从库）、同步复制（太关心从库）、半同步复制（先关心超时后不关心从库）

2 主从复制原理

主从复制步骤：

1） MySQL主库在事务提交时把数据变更（insert、delete、update）作为事件日志记录在二进制日志表（binlog）里面

2）从库的 I/O 线程去请求主库的 binlog时，主库会生成一个 log dump 线程，用来给从库 I/O 线程传 binlog日志

3）从库的I/O线程得到的 binlog 日志后，会将其写入到 relay log (中继日志) 文件中去

4）从库的 SQL 线程会读取 relay log 文件中的日志，并解析成具体操作，来实现主从的操作一致，而最终数据一致

3 主从复制搭建过程

搭建主从的话，首先需要从主库备份一致性的数据备份文件。

备份方法一、常用的mysqldump备份虽然没有问题，但是用来搭建主从就不太合适，因为不能记录准确的位点信息或GITD号，搭建过程可能会存在数据冲突或者数据丢失的风险，导致主从同步失败。推荐使用xtrabackup进行搭建主从复制（业务低峰期操作）

备份方法二、xtrabackup在后台线程不断追踪InnoDB的日志文件，然后复制InnoDB的数据文件。数据文件复制完成之后，日志的复制线程也会结束。这样就得到了不在同一时间点的数据副本和开始备份以后的事务日志

xtrabackup工具下载地址：https://www.percona.com/downloads/Percona-XtraBackup-LATEST

对于mysql8.0版本数据库，如果下载的xtrabackup包不能用，可以尝试这个rpm包：https://downloads.percona.com/downloads/Percona-XtraBackup-LATEST/Percona-XtraBackup-8.0.14/binary/redhat/7/x86_64/percona-xtrabackup-80-8.0.14-1.el7.x86_64.rpm

4 主从复制搭建步骤

注：此文以xtrabackup搭建主从为例，也可以使用mydumper工具来搭建主从，参考链接：https://vip.kingdee.com/article/322678304510088704

步骤1、主库授权

登录主库使用root用户创建复制用户并授权

mysql> create user '同步用户'@'%' IDENTIFIED WITH mysql_native_password BY '密码';

mysql> grant replication client,replication slave on *.* to '同步用户'@'%';

mysql> flush privileges;

步骤2、主库备份

# xtrabackup --defaults-file=my.cnf配置文件路径 --user=备份的用户 --password=密码 --no-lock --backup --target-dir=备份文件路径

mysql> show master status\G;

步骤3、将备份文件拷贝到从库

# scp -rp 主库备份路径 从库用户名@从库主机:/从库备份文件路径

# chown mysql. -R 从库备份文件路径

步骤4、从库还原

步骤4.1、清空从库数据和日志（请确认是在从库上执行）

# systemctl stop mysqld  先停止从库

# rm -rf /kingdee/mysql/mysql3306/{data,log}/*

步骤4.2、从库恢复重做日志

# xtrabackup --defaults-file=my.cnf配置文件路径 --parallel=4 --prepare --use-memory=4G --target-dir=备份文件路径

步骤4.3、从库恢复数据

# xtrabackup --defaults-file=my.cnf配置文件路径 --copy-back --target-dir=备份文件路径

# chown -R mysql:mysql 数据路径 日志路径

# rm -rf 数据路径/auto.cnf     # 搭建主从前先删除从库恢复的auto.cnf文件，若无该文件则忽略

# vi my.cnf    #修改server-id，数值需要低于主库

步骤4.4、启动从库服务

# systemctl start mysqld

在xtrabackup的备份目录下查看 xtrabackup_info文件，可以查看到GTID号或位点号

步骤5、配置并开启主从复制（从库执行，下面的GTID和位点方式二选一，推荐GTID方式）

GTID方式：

mysql> reset master;

mysql> SET @@GLOBAL.GTID_PURGED='查询到的gtid号';

mysql> CHANGE MASTER TO MASTER_HOST='主库主机地址',

    MASTER_USER='同步用户',

    MASTER_PASSWORD='同步用户的密码',

    MASTER_PORT=主库端口,

    MASTER_AUTO_POSITION=1;

mysql> start slave;

mysql> show slave status\G;

位点方式（binlog文件号和位点号可在xtrabackup_info文件中查到）：

mysql> reset master;

mysql> CHANGE MASTER TO MASTER_HOST='主库主机地址',

    MASTER_USER='同步用户',

    MASTER_PASSWORD='同步用户的密码',

    MASTER_PORT=主库端口,

    MASTER_LOG_FILE='binlog文件号',

    MASTER_LOG_POS=位点号;

mysql> start slave;

mysql> show slave status\G;

步骤6、从库设为只读模式，避免从库写入业务数据导致主从不一致（请务必将从库设为只读模式）

mysql> set global read_only=ON;

mysql> set global super_read_only=ON;

5 主从复制异常处理

判断数据是否可以追回（依据失败点的binlog是否在主库仍然存在）

mysql> show slave status\G;

查看同步失败位置的binlog文件，在主库是否存在：

如果binlog文件仍然存在主库中，可以通过下面报错的位点，在binlog文件中找到具体语句进行分析；

如果binlog文件已经在主库清理掉了，从库就无法追回数据，需要重新搭建主从。

如果从库数据可以追回情况，需要分析中断在主库的binlog文件

分析主库binlog文件大致步骤：

# mysqlbinlog --no-defaults -v -v --base64-output=decode-rows binlog文件名 > 1.log

# grep -A20 位点号 --color 1.log

判断这条记录是否可以忽略（上图已知是插入了重复值，而这条重复值是完全一致的数据），如果可以忽略就执行下面语句进行忽略

mysql> stop slave;

mysql> set @@SESSION.GTID_NEXT='performance_schema.replication_applier_status_by_worker表

中查的LAST_SEEN_TRANSACTION值';   #MySQL8.0是APPLYING_TRANSACTION字段

mysql> begin;

mysql> commit;

mysql> set @@SESSION.GTID_NEXT = AUTOMATIC;

mysql> start slave;

如果无法追回数据，则按照主从复制搭建过程重新搭建主从。