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