1. 主从复制前提

(1) 两台节点
(2) 二进制日志
(3) server_id不同,uuid
(4) 复制用户
(5) 备份恢复数据到从
(6) 复制信息提供(change master to)
(7) 开线程(start slave)

2. 主从复制的原理

(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线程来取新的,来保证复制实时性.

================================================================================

1.

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: 

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.000006
          Read_Master_Log_Pos: 444
        Relay_Master_Log_File: mysql-bin.000006
          Exec_Master_Log_Pos: 444

1.4 从库和主库延时时间

[root@db01 ~]#mysql -S /data/3308/mysql.sock -e "show slave status \G"|grep "Seconds_Behind_Master"
        Seconds_Behind_Master: 0

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: 

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: 

中继日志监控

[root@db01 ~]#mysql -S /data/3308/mysql.sock -e "show slave status \G"|grep "Relay"
               Relay_Log_File: db01-relay-bin.000002
                Relay_Log_Pos: 320
        Relay_Master_Log_File: mysql-bin.000006
              Relay_Log_Space: 526

2 主从复制故障

2.1 IO线程故障

[root@db01 ~]# mysql -S /data/3308/mysql.sock -e "show slave status \G"|grep "Running:"
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
(1) 读取master.info 
损坏 
信息错误 change master to信息错误
(2) 连接主库
网络
防火墙
主库没启动
连接数上限了

以上问题:
Slave_IO_Running: Connecting
Last_IO_Error:  xxxxxx

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

修复: 
stop slave 
reset slave all
change master to
start slave
（3）请求日志
maste.info 复制起点
主库发生了日志的损坏、误删除等
（4）接收日志
relaylog损坏

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

（5）更新master.info

2.2 SQL线程故障 *****

(1) relay.info 
(2) 回放relaylog中的日志  *****
SQL语句为什么会失败?
(1) 语法,SQL_Mode 
版本,sql_mode不一致
(2) DDL DML 为什么会失败
create database /table  创建的对象已经存在了.
从库被提前写入了
drop database errdb;   要删除和修改的对象不存在.
alter 
insert
update 
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)加中间件
读写分离。

2.4 自己扩展

pt-xxx  关于主从方面的工具
检查主从数据一致性
实现主从数据同步

3 主从延时 *****

3.1 什么是主从延时

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

3.2 主从延时的现象

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

3.3 主从延时的原因

3.3.1 外部原因

网络
硬件
主库的繁忙程度
版本差异
参数差异

3.3.2 内部原因

主库：
（1）二进制日志方面
二进制日志落地不及时
解决方案：
sync_binlog=1
可以将binlog单独存放高性能存储中
(2) Dump_T （默认是串行工作模式）
主库的事务量大
主库发生大事务
解决方案：
1. GTID 模式
2.  双一的保证
如何监控:
    主库: show master status;
    
    从库: show slave status \G
    Master_Log_File: mysql-bin.000001
    Read_Master_Log_Pos: 484    

从库：
（1） IO线程方面
relaylog 写入
解决方案：
可以将relaylog 单独存放高性能存储中
relay_log_basename           | /data/3308/data/db01-relay-bin       
relay_log_index              | /data/3308/data/db01-relay-bin.index 
（2）SQL线程方面（只有一个，串行回放）
默认SQL线程，只能逐条的回放SQL
事务并发高
大事务
5.6 版本 加入了多SQL复制 
    按照库(database)级别,进行并发回放SQL
    slave_parallel_workers=16
    slave_parallel_type=DATABASE 
    
    5.7 版本 进行了多SQL复制加强(MTS)
    真正按照事务级别,实现了多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

4. 主从基础小结

4.1 主从前提

4.2 主从原理 *****

4.3 主从监控

  show master status;
    show processlist;
    show slave status\G
    master.info 
    relay.info

4.4 主从故障

    IO 
        连接 
        binlog
    SQL 
        从库写入
        DML,insert ,update ,delete

4.5 主从延时

    主
        dump 串行 : GTID,双一 并行
        show slave status\G 
        Master_Log_File: mysql-bin.000001
        Read_Master_Log_Pos: 1084       
        
        show master status \G
        
    从
        SQL 串行  : MTS 
        已经拿过来的日志: 
        show slave status\G 
        Master_Log_File: mysql-bin.000001
        Read_Master_Log_Pos: 1084
        已经执行过的:
        ./db01-relay-bin.000003
        920
        mysql-bin.000001
        800