MySQL 第八章 主从复制

企业高可用性方案

负载均衡：有一定的高可用性
LVS Nginx
主备系统：有高可用性，但是需要切换，是单活的架构
KeepAlive，MHA******，MMM
真正高可用（多活系统）：
NDB Cluster Oracle RAC Sysbase cluster，InnoDB Cluster（MGR 5.7.17）****，PXC，MGC

一、普通主从复制

1.主从复制简介

1）基于二进制日志复制的
2）从库的修改操作会记录二进制日志
3）从库会请求新的二进制日志并回放，最终达到主从数据同步
4）主从复制核心功能：
辅助备份，处理物理损坏
扩展新型的架构：高可用，高性能，分布式架构

2.主从复制前提（主从复制的规划，实施过程）

1）至少两个数据库实例
2）主库开启binlog ，不同的server_id，server_uuid（gtid模式）
3）主库要有一个专门用作复制的用户（replication slave）
4）通过备份将源库数据补偿到从库
5）告知从库，用户名，密码，ip，port，自动复制起点
6）需要专门的复制线程（start slave）

3.实操--主从复制

>>>>3.1>准备多实例环境，启动数据库
 systemctl restart mysqld3307.service
 systemctl restart mysqld3308.service

>>>>>.3.2登录
mysql -S /data/3307/mysql.sock
mysql -S /data/3308/mysql.sock

>>>>>3.3检查 主库binlog  不同
server_id ,server_uuid
mysql -S /data/3307/mysql.sock -e" select @@server_id;select @@log_bin ;"
mysql -S /data/3308/mysql.sock -e" select @@server_id;select @@log_bin ;"

>>>>>3.4主库创建复制用户
[root@db01 ~]# mysql -S /data/3307/mysql.sock -e "grant replication slave on *.* to repl@'10.0.0.%' identified by '123';"
[root@db01 ~]# mysql -S /data/3307/mysql.sock -e "select user,host from mysql.user where user='repl';"

>>>>>3.5 通过备份将源库数据补偿到从库
[root@db01 ~]# mysqldump  -S /data/3307/mysql.sock -A  -R -E --triggers --master-data=2 --single-transaction --max-allowed-packet=128M   >/tmp/full.sql

>>>>>3.6 告知从库,用户名,密码,ip,port,自动复制的起点
# change master to 
mysql[(none)]>help change master to(查看帮助)
从库语句：
CHANGE MASTER TO
  MASTER_HOST='10.0.0.51',
  MASTER_USER='repl',
  MASTER_PASSWORD='123',
  MASTER_PORT=3307,
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=154,
  MASTER_CONNECT_RETRY=10;
log文件查看：
[root@db01 /data/3307]# vim /tmp/full.sql 
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000008', MASTER_LOG_POS=734;
>>>>>3.7启动主从线程
mysql[(none)]>start slave;
Query OK, 0 rows affected (0.00 sec)



3.8 检测主从状态
[root@db01 /data/3307]#  mysql -S /data/3308/mysql.sock -e "show slave status \G"|grep Yes
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes


3.9.排错
oldguo[(none)]>stop slave ;
oldguo[(none)]>reset slave all;

4.主从复制原理

4.1主从复制过程中涉及到的文件

>>主库：
>
> ----------binlog日志
存放/data/3307/
      mysql-bin.000001
      mysql-bin.000002
>>从库：
relaylog 中继日志
存放/data/3308/data/
      db01-relay-bin.000001
      db01-relay-bin.000002
      master.info   信息文件(主库信息文件)
      relay-log.info 信息文件（中继日志信息文件）

4.2主从复制过程中涉及到的线程

>>>>主库:
Binlog_Dump_Thread(二进制日志投递线程)

>>>>从库：
Slave_IO_Thread
Slave_SQL_Thread

4.3主从复制原理

(1) 从库,change master to(ip port user password binlog pos),存master.info
(2) 从库,start slave,开启 IO和SQL 
(3) 从库IO,读master.info,连接主库,主库开启binlog_dump_T
(4) 从库IO,读master.info,根据记录的位置号,请求最新的.
(5) 主库dump进行TP,最新的binlog,给从库IO 
(6) 从库IO接收,存储到TCP/IP缓存,在TCP/IP层面返回ACK给主库
(7) 从库IO,将缓存数据,落地到relay-log中,并更新master.info 二进制日志信息
(8) 从库SQL,读取relay.info ,获取上次已经执行 到的relay-log的信息,继续回放最新的relay
(9) SQL更新relay.info为最新状态
(10) 补充1: relay-log会自动被定时清理
(11) 补充2: 主库一旦有新的binlog更新,dump会有信号通知,告知IO线程来取新的,来保证复制实时性.

4.主从复制的监控

1.1 线程状态
[root@db01 ~]# mysql -S /data/3308/mysql.sock -e "show slave status \G"|grep "Running:"
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

1.2 线程报错具体信息
[root@db01 ~]# mysql -S /data/3308/mysql.sock -e "show slave status \G"|grep "Last"
Last_Errno: 0
Last_Error: 
Last_IO_Errno: 0
Last_IO_Error: 
Last_SQL_Errno: 0
Last_SQL_Error: 
Last_IO_Error_Timestamp: 
Last_SQL_Error_Timestamp: 
[root@db01 ~]# 

1.3 查看主库连接信息有关

[root@db01 ~]# mysql -S /data/3308/mysql.sock -e "show slave status \G"|grep "Master"
Master_Host: 10.0.0.51
Master_User: repl
Master_Port: 3307
Master_Log_File: mysql-bin.000012
Read_Master_Log_Pos: 154
Relay_Master_Log_File: mysql-bin.000012
Exec_Master_Log_Pos: 154
.......
[root@db01 ~]# 

1.4 从库和主库延时的时间
 mysql -S /data/3308/mysql.sock -e "show slave status \G"|grep "Seconds_Behind_Master"

1.5 过滤复制相关状态
[root@db01 ~]#  mysql -S /data/3308/mysql.sock -e "show slave status \G"|grep " Replicate_"
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
  Replicate_Ignore_Server_Ids: 
         Replicate_Rewrite_DB: 
[root@db01 ~]# 

1.6 延时从库的状态信息
[root@db01 ~]# mysql -S /data/3308/mysql.sock -e "show slave status \G"|grep "Delay:"
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL

1.7 监控Gtid复制状态信息
[root@db01 ~]# mysql -S /data/3308/mysql.sock -e "show slave status \G"|grep "Gtid"
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 

1.8 中继日志的监控
[root@db01 /data/3308]# mysql -S /data/3308/mysql.sock -e "show slave status\G " |grep  'Relay'
               Relay_Log_File: db01-relay-bin.000005
                Relay_Log_Pos: 367
        Relay_Master_Log_File: mysql-bin.000009
              Relay_Log_Space: 739

5.主从复制故障

5.1 IO线程故障

1）>>>>>>读取maser.info
损坏
信息错误 change master to信息错误

2) >>>>>连接主库
网络
防火墙
主库没启动
连接数上限了

以上问题报错：
以上问题:
Slave_IO_Running: Connecting
Last_IO_Error:  xxxxxx

排查方法: 
通过复制用户,手工连接主库,看报错信息.

修复: 
stop slave 
reset slave all
change master to
start slave

3）>>>>>请求日志
master.info 复制起点
主库损坏，误删除等（错误码：1236）


4）>>>>>接受日志
relaylog损坏

修复：
stop slave;
reset slave all;
change master to .......
start  slave;

5）>>>>>更新master.info

5.2 SQL线程故障

1) relay.info
2)回放relaylog中的日志
SQL语句为什么会失败？
1）语法，SQL_Mode
版本，sql_mode不一致
2) DDL   DML为什么会失败
create database table  创建的对象已经存在了
从库被提前写入了    

drop database errdb；要删除和修改的对象不存在（alter insert  updata delete）

处理方法(以从库为核心的处理方案)：
方法一：
stop slave;  
set global sql_slave_skip_counter = 1;
#将同步指针向下移动一个，如果多次不同步，可以重复操作。
start slave;


方法二：
/etc/my.cnf
slave-skip-errors = 1032,1062,1007
常见错误代码:
1007:对象已存在
1032:无法执行DML
1062:主键冲突,或约束冲突

但是，以上操作有时是有风险的，最安全的做法就是重新构建主从。把握一个原则,一切以主库为主.
2.3 防止从库写入
(1) 可以设置从库只读.
oldguo[(none)]>show variables like '%read_only%';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_read_only      | OFF   |
| read_only             | OFF   |
| super_read_only       | OFF   |
| transaction_read_only | OFF   |
| tx_read_only          | OFF   |
+-----------------------+-------+
5 rows in set (0.01 sec)

注意：
只会影响到普通用户，对管理员用户无效。


(2)加中间件
读写分离。

扩展项

检查主从数据一致性
实现主从数据同步

6，主从延时

6.1什么是主从延时

主库做的是，从库很久才执行

6.2主从延时的现象

1）最直观：主库做更改，从库看数据状态
2）Seconds_Behind_Master:0（只能证明，或者没有）
3）计算日志的差异

6.2主从延时的原因

6.2.1外部因素

网络，硬件，参数差异，版本差异

6.2.1内部因素

主库：

1)二进制日志方面
二进制日志落地不及时 

解决：
sync_binlog=1（ 防止日志堆积   <双一>）
可以将binlog单独存放高性能存储中

2）Dump_T(默认串行
主库的事务量大
主库发生大事务

解决：
GTID 模式
双一的保证

从库：

1）IO  线程方面
relaylog写入 
解决：
写入快，可以将relaylog单独存放高性能存储中
2）SQL线程方面（只有一个，串行回放）
默认SQL线程，只能逐条的回放SQL
事务并发高
大事务


5.6 版本 加入了多SQL复制
按照库级别，进行并发回放SQL
` slave_parallel_workers=16`
` slave_parallel_type=DATABASE`

5.7版本 进行了多SQL复制加强
` slave_parallel_workers=16`
` slave_parallel_type=logical_clock`
\
注意：必须依赖于GTID复制

>>>>>>>>如何监控
(1) 监控取了多少日志 
    show slave status \G
    Master_Log_File: mysql-bin.000001
    Read_Master_Log_Pos: 1084

(2) 回放了多少日志
[root@db01 /data/3308/data]# cat relay-log.info 
7
./db01-relay-bin.000003
920
mysql-bin.000001
1084