MySQL主从复制

  1. 搭建主从复制
  2. 主从原理熟悉
  3. 主从的故障处理
  4. 主从延时
  5. 主从的特殊架构的配置使用
  6. 主从架构的演变

主从复制介绍

  1. 主从复制基于binlog来实现的
  2. 主库发生新的操作,都会记录binlog
  3. 从库取得主库的binlog进行回放
  4. 主从复制的过程是异步

主从复制的前提

  1. 2个或以上的数据库实例
  2. 主库需要开启二进制日志
  3. server_id要不同,区分不同的节点
  4. 主库需要建立专用的复制用户 (replication slave)
  5. 从库应该通过备份主库,恢复的方法进行"补课"
  6. 人为告诉从库一些复制信息(ip port user pass,二进制日志起点)
  7. 从库应该开启专门的复制线程

主从复制搭建过程

准备多实例

模拟生产环境中主从的搭建,使用1台服务器上多个端口来模拟多实例,生产环境中不会出现1台服务器上有多个MySQL,多实例的搭建过程参考该链接

  • 同一台服务器上同时运行多个MySQL,需要设置不同端口,登录采用socket方式
  • 保证数据统一性,主从数据库版本最好一致,数据一致,如果有遗留的数据可以通过删除数据目录和日志,重新初始化数据库
#删除数据和日志
rm -rf /data/3308/data/*
rm -rf /data/3308/mysql-bin.*
#初始化数据库(正式环境数据库初始化时需要配置密码)
mysqld --initialize-insecure --user=mysql --basedir=/application/mysql --datadir=/data/3308/data
#启动数据库
systemctl start mysqld3308
#查看端口号
mysql -S /data/3308/mysql.sock -e "select @@port"

检查配置文件

#检查两个数据库实例的配置文件
#检查server_id和二进制日志
cat /data/330{7,8}/my.cnf

[mysqld]
basedir=/application/mysql
datadir=/data/3307/data
socket=/data/3307/mysql.sock
log_error=/data/3307/mysql.log
port=3307
server_id=7
log_bin=/data/3307/mysql-bin
[mysqld]
basedir=/application/mysql
datadir=/data/3308/data
socket=/data/3308/mysql.sock
log_error=/data/3308/mysql.log
port=3308
server_id=8
log_bin=/data/3308/mysql-bin

主库创建复制用户

mysql -S /data/3307/mysql.sock -e "grant replication slave on *.* to repl@'10.0.0.%' identified by '123456'"

通过备份同步一次数据

  • 从3306库获得数据
mysqldump -S /data/3307/mysql.sock -A --master-data=2 --single-transaction -R -E --triggers >/tmp/full.sql
  • 使用3307库的数据,使用3307库和3308库做主从同步
#同步3308库数据
mysql -S /data/3308/mysql.sock
set sql_log_bin=0;
source /tmp/full.sql
set sql_log_bin=1;

从库设置同步信息

#可以通过help change master to命令查看相关参数
#/tmp/full.sql中二进制文件记录如下
#-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;

#从库配置同步信息如下

CHANGE MASTER TO 
MASTER_HOST='10.0.0.51',
MASTER_USER='repl',
MASTER_PASSWORD='123456',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=154,
MASTER_CONNECT_RETRY=10;

#设置完成后开启复制线程(IO,SQL)
start slave;
#检查主从复制状态
show slave status \G
  • Slave_IO_Running: Yes,Slave_SQL_Running: Yes这两个参数为yes时,主从配置成功

验证主从同步

#主库创建一个新库
mysql -S /data/3307/mysql.sock -e "create database alexsb"
#查看从库是否增加一个alexsb库
mysql -S /data/3308/mysql.sock -e "show databases"

主从复制原理

主库

  • binlog : 二进制日志
  • Binlog_Dump Thread : DUMP_T

从库

  • relaylog : 中继日志
  • master.info : 主库信息文件
  • relaylog.info : relaylog应用的信息
  • SLAVE_IO_THREAD : IO_T
  • SLAVE_SQL_THREAD : SQL_T

QQ图片20200406152210.png

  1. 从库执行change master to命令(主库的连接信息+复制的起点)
  2. 从库会将以上信息,记录到master.info文件
  3. 从库执行start slave命令,立即开启IO_TSQL_T
  4. 从库IO_T,读取master.info文件中的信息,获取到IP,PORT,User,Pass,binlog的位置信息
  5. 从库IO_T请求连接主库,主库专门提供一个DUMP_T,负责和IO_T交互
  6. IO_T根据binlog的位置信息(mysql-bin.000001,154),请求主库新的binlog
  7. 主库会开启一个DUMP_T,通过DUMP_T将最新的binlog,通过网络发送给从库的IO_T
  8. IO_T接收到新的binlog日志,存储到TCP/IP缓存,立即返回ACK给主库,并更新master.info
  9. IO_T将TCP/IP缓存中数据,转储到磁盘relaylog
  10. SQL_T读取relay.info中的信息,获取到上次已经应用过的relaylog的位置信息
  11. SQL_T会按照上次的位置点回放最新的relaylog,再次更新relay.info信息
  12. 从库会自动清理同步过relaylog进行定期清理

一旦主从复制构建成功,主库当中发生了新的变化,都会通过DUMP_T发送信号给IO_T,增强了主从复制的实时性

主从复制监控

#从库执行命令查看主从状态(主库执行该命令为空)内容如下
show slave status \G

               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.0.0.51
                  Master_User: repl
                  Master_Port: 3307
                Connect_Retry: 10
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 319
               Relay_Log_File: db01-relay-bin.000002
                Relay_Log_Pos: 485
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 319
              Relay_Log_Space: 691
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 7
                  Master_UUID: dda9c57a-6279-11ea-8d13-000c293555ca
             Master_Info_File: /data/3308/data/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 192ae722-6e3e-11ea-9164-002170ee9a77:1-21
                Auto_Position: 0
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
  • Master_Host : 主库地址,主库有关的信息(master.info)
  • Master_User : 主库用户,主库有关的信息(master.info)
  • Master_Port : 主库端口,主库有关的信息(master.info)
  • Connect_Retry : 连接重试次数,主库有关的信息(master.info)
  • Master_Log_File : 主库当前二进制日志文件,可以在主库中使用show master status;对比该结果,主库有关的信息(master.info)
  • Read_Master_Log_Pos : 主库当前二进制日志文件记录点,可以在主库中使用show master status;对比该结果,主库有关的信息(master.info)
  • Relay_Log_File : 从库relay应用信息有关的(relay.info)
  • Relay_Log_Pos : 从库relay应用信息有关的(relay.info)
  • Relay_Master_Log_File : 从库relay应用信息有关的(relay.info)
  • Slave_IO_Running : 从库线程运行状态(排错)
  • Slave_SQL_Running : 从库线程运行状态(排错)
  • Last_IO_Errno : 从库线程运行状态(排错)
  • Last_IO_Error : 从库线程运行状态(排错)
  • Last_SQL_Errno : 从库线程运行状态(排错)
  • Last_SQL_Error : 从库线程运行状态(排错)
  • Replicate_Do_DB : 过滤复制有关的信息
  • Replicate_Ignore_DB : 过滤复制有关的信息
  • Replicate_Do_Table : 过滤复制有关的信息
  • Replicate_Ignore_Table : 过滤复制有关的信息
  • Replicate_Wild_Do_Table : 过滤复制有关的信息
  • Replicate_Wild_Ignore_Table : 过滤复制有关的信息
  • Seconds_Behind_Master : 从库延时主库的时间(秒)
  • SQL_Delay : 延时从库
  • SQL_Remaining_Delay : 延时从库
  • Retrieved_Gtid_Set : GTID复制有关的状态信息
  • Executed_Gtid_Set : GTID复制有关的状态信息
  • Auto_Position : GTID复制有关的状态信息

主从复制故障

IO线程故障

  • 连接主库失败,show slave status \G查看,结果为Slave_IO_Running: Connecting,Last_IO_Error: error reconnecting to master 'repl@10.0.0.51:3307' - retry-time: 10 retries: 10

网络问题连接失败,连接信息错误或连接信息变更,防火墙,连接数上限

#解决方法1:可以先停止再启动后,再查看同步状态
stop slave;
start slave;

#解决方法2:先停止同步,再清空同步信息,重新构建change master to,再启动,并查看同步状态
stop slave;
reset slave all;
CHANGE MASTER TO 
MASTER_HOST='10.0.0.51',
MASTER_USER='repl',
MASTER_PASSWORD='123456',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=154,
MASTER_CONNECT_RETRY=10;
start slave;
  • 请求binlog失败,show slave status \G查看,结果为Slave_IO_Running: No,Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'could not find next log; the first event 'mysql-bin.000003' at 154, the last event read from '/data/3307/mysql-bin.000003' at 123, the last byte read from '/data/3307/mysql-bin.000003' at 154.'

binlog损坏,binlog被清除或者不存在

#解决方法:先停止同步,再清空同步信息,去主库中确认binlog是否开启,获取正确的pos号,重新构建change master to,再启动,并查看同步状态
#主库命令行执行
mysqlbinlog --no-defaults mysql-bin.000003 >> /tmp/123.log

#导出日志后,查看故障点,重新写入change master语句开启同步

stop slave;
reset slave all;
CHANGE MASTER TO 
MASTER_HOST='10.0.0.51',
MASTER_USER='repl',
MASTER_PASSWORD='123456',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000003',
MASTER_LOG_POS=123,
MASTER_CONNECT_RETRY=10;
start slave;
show slave status \G
  • 2021.11.18 1236报错真实案例,因为主库磁盘空间不足binlog报错Got fatal error 1236 from master when reading data from binary log: 'binlog truncated in the middle of event; consider out of disk space on master; the first event 'mysql-bin.000313' at 124505094, the last event read from 'mysql-bin.000313' at 124505094, the last byte read from 'mysql-bin.000313' at 124506131.'
#解决方法:先停止同步,再清空同步信息,去主库中确认binlog是否开启,获取正确的pos号,重新构建change master to,再启动,并查看同步状态
#主库命令行执行
mysqlbinlog --no-defaults mysql-bin.000313 >> /tmp/313.log

#可以看到,从库要读取的Position比主库上此binlog日志的最后一个Position还要大。此由于主机磁盘空间不足binlog未及时同步到磁盘。从库读取了主库binlog file中的不存在的binlog position ,一般比binlogfile 的end position 的值还要大。断电等其他未能写入binlog也可能引起这个问题
#在从库重新指向到主库下一个可用的binlog file 且从binlog file初始化的位置开始即可,我这里选择指向了报错binlog文件的末尾位置

# at 124504997
#211118  1:03:24 server id 6  end_log_pos 124505024     Xid = 18649216
COMMIT/*!*/;
# at 124505024
#211118  1:03:26 server id 6  end_log_pos 124505094     Query   thread_id=6325  exec_time=0     error_code=0
SET TIMESTAMP=1637168606/*!*/;
BEGIN
/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

#查看到具体日志操作位置为124505094,报错信息的位置是124506131,这里选择从结束位置124506131开始构建语句

#找到位置后,停止同步,重置同步语句后开启同步
stop slave;
reset slave all;
CHANGE MASTER TO 
MASTER_HOST='172.16.*.*',
MASTER_USER='repl',
MASTER_PASSWORD='******',
MASTER_PORT=3306,
MASTER_LOG_FILE='mysql-bin.000313',
MASTER_LOG_POS=124506131,
MASTER_CONNECT_RETRY=10;
start slave;
show slave status \G

SQL线程故障

relay-log回放时出错,也就是sql语句执行失败,有以下几种可能,回放relay-log执行增删改操作的表不存在,回放relay-log执行建表建库操作时该库该表已存在,主键唯一键非空等约束冲突

  • 解决方法1:根据情况进行改变,把握一个原则,一切以主库为准进行解决,如果出现问题,尽量进行反操作,必要时可以重新构建主从
  • 解决方法2:直接跳过当前报错的行(不推荐)
#虽然有时候可以解决问题,但是长期以往会出现问题,例如建表冲突并且建表语句不同可能带来的问题
#以下操作有时是有风险的,最安全的做法就是重新构建主从.把握一个原则,一切以主库为主

#停止同步
stop slave;
#将同步指针向下移动一个,如果多次不同步,可以重复操作
set global sql_slave_skip_counter = 1;
#开始同步
start slave;
  • 解决方法3:直接跳过对应的错误代码(不推荐)
#虽然有时候可以解决问题,但是长期以往会出现问题,例如建表冲突并且建表语句不同可能带来的问题
#以下操作有时是有风险的,最安全的做法就是重新构建主从.把握一个原则,一切以主库为主

vi /etc/my.cnf

# 1007:对象已存在
# 1032:无法执行DML
# 1062:主键冲突,或约束冲突

slave-skip-errors = 1032,1062,1007

为了很程度的避免SQL线程故障有以下方法

  1. 从库只读
#配置文件中加入以下参数并重启,控制普通用户只读和root用户只读
vi /etc/my.cnf

read_only
super_read_only
  1. 使用读写分离中间件
  • atlas
  • mycat
  • ProxySQL
  • MaxScale

主从延时监控及原因

主库方面原因

  1. binlog写入不及时
  • 设置sync_binlog=1,双1标准中的一个,该参数具体内容参考该链接
  1. 默认情况下DUMP_T是串行传输binlog,在并发事务量大时或者大事务,导致传送日志较慢
  • 必须开启GTID,使用Group commit方式.可以支持DUMP_T并行
  1. 主库设置了binlog_group_commit_sync_delaybinlog_group_commit_sync_no_delay_count参数
  • binlog_group_commit_sync_delay全局动态变量,单位微妙,默认0,范围:0~1000000(1秒)表示binlog提交后等待延迟多少时间再同步到磁盘,默认0,不延迟设置延迟可以让多个事务在用一时刻提交,提高binlog组提交的并发数和效率,提高slave的吞吐量
  • binlog_group_commit_sync_no_delay_count全局动态变量,单位个数,默认0,范围:0~1000000.表示等待延迟提交的最大事务数,如果上面参数的时间没到,但事务数到了,则直接同步到磁盘.若binlog_group_commit_sync_delay没有开启,则该参数也不会开启
  1. 主库极其繁忙,比如慢语句,锁等待,从库个数,网络延时

从库方面原因

  1. 传统复制(Classic)中,如果主库并发事务量很大,或者出现大事务,由于从库是单SQL线程,导致,不管传的日志有多少,只能一次执行一个事务

5.6版本,有了GTID,可以实现多SQL_T线程,但是只能基于不同库(database)的事务进行并发回放

5.7 版本中,有了增强的GTID,增加了seq_no,增加了新型的并发SQL线程模式(logical_clock),MTS技术

  1. 主从硬件差异太大
  2. 主从的参数配置
  3. 从库和主库的索引不一致
  4. 版本有差异

主从延时的监控

  • 从库中,执行show slave status\G命令查看Seconds_Behind_Master参数的值

主库方面原因的监控

  • 主库中,执行show master status;命令查看Position对比从库中执行show slave status\G命令的Read_Master_Log_Pos参数,如果Position大于Read_Master_Log_Pos,就是主库延时,没有同步到从库

从库方面原因监控

  1. 从库中,可以查看relay-log.info中的Position对比主库中的binlog来判断
  2. 从库中,执行show master status;命令,对比以下参数来确认是否是从库造成的延时
  • Master_Log_File : 读取的主库的binlog文件
  • Read_Master_Log_Pos : 读取到主库的binlog文件的Pos
  • Relay_Log_File : 当前从库的Relaylog文件
  • Relay_Log_Pos : 当前从库的Relaylog文件的Pos
  • Exec_Master_Log_Pos : 执行到从库的Relaylog文件的Pos
  • Relay_Log_Space : 当前从库的Relaylog文件的大小

对比Read_Master_Log_PosExec_Master_Log_Pos的值,如果Read_Master_Log_Pos大于Exec_Master_Log_Pos,就是从库延时,Relaylog没有及时被SQL_T执行写入从库磁盘