1 线程相关监控
主库:
show full processlist;
每个从库都会有一行dump相关的信息
HOSTS:
db01:47176
State:
Master has sent all binlog to slave; waiting for more updates
如果现实非以上信息,说明主从之间的关系出现了问题
从库:
db01 [(none)]>show slave status \G
主从复制故障分析
1. IO
连接主库
(1) 用户 密码 IP port
Last_IO_Error: error reconnecting to master '[email protected]:3307' - retry-time: 10 retries: 7
[root@db01 ~]# mysql -urepl -p123333 -h 10.0.0.51 -P 3307
ERROR 1045 (28000): Access denied for user 'repl'@'db01' (using password: YES)
原因:
密码错误
用户错误
skip_name_resolve
地址错误
端口
处理方法
stop slave
reset slave all ---解除从库关系
change master to
start slave
主库连接数上线,或者是主库太繁忙
show slave staus \G
Last_IO_Errno: 1040
Last_IO_Error: error reconnecting to master '[email protected]:3307' - retry-time: 10 retries: 7
处理思路:
拿复制用户,手工连接一下
[root@db01 ~]# mysql -urepl -p123 -h 10.0.0.51 -P 3307
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1040 (HY000): Too many connections
处理方法:
db01 [(none)]>set global max_connections=300;
(3) 防火墙,网络不通
请求二进制日志
主库缺失日志
从库方面,二进制日志位置点不对
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.000001' at 154, the last event read from '/data/3307/data/mysql-bin.000002' at 154, the last byte read from '/data/3307/data/mysql-bin.000002' at 154.'
注意: 在主从复制环境中,严令禁止主库中reset master; 可以选择expire 进行定期清理主库二进制日志
解决方案:
重新构建主从
SQL 线程故障
SQL线程功能：
(1)读写relay-log.info
(2)relay-log损坏,断节,找不到
(3)接收到的SQL无法执行
导致SQL线程故障原因分析：
1. 版本差异，参数设定不同，比如：数据类型的差异，SQL_MODE影响
2.要创建的数据库对象,已经存在
3.要删除或修改的对象不存在
4.DML语句不符合表定义及约束时.
归根揭底的原因都是由于从库发生了写入操作.
Last_SQL_Error: Error 'Can't create database 'db'; database exists' on query. Default database: 'db'. Query: 'create database db'
处理方法(以从库为核心的处理方案)：
方法一：
stop slave;
set global sql_slave_skip_counter = 1; ---跳过复制错误
将同步指针向下移动一个，如果多次不同步，可以重复操作
start slave;
方法二：
/etc/my.cnf
slave-skip-errors = 1032,1062,1007
常见错误代码:
1007:对象已存在
1032:无法执行DML
1062:主键冲突,或约束冲突
但是，以上操作有时是有风险的，最安全的做法就是重新构建主从。把握一个原则,一切以主库为主
永久修改的方法：
(1) 可以设置从库只读.
db01 [(none)]>show variables like '%read_only%';
临时设置：
>slect @@read_only;
>set global read_only=1;
注意：
只会影响到普通用户，对管理员用户无效。
(2)加中间件
读写分离。
主从延时
主库做了修改操作，从库比较长时间才能追上
1.1外在因素
网络
主从硬件差异大
版本差异
参数因素
1. 2.主库
主库写binlog不及时写入
select @@sync_binlog;
传统复制(CR)的主从复制中，binlog_dump线程，以事件为单元，串行传送二进制日志(5.6 5.5)
1.主库并发事务量大，主库可以并行，传送时是串行
2.主库发生了大事务，由于是串行传送，会产生阻塞后续的事务
控制binlog从内存写入磁盘的控制开关
每次事务提交都立即刷新binlog到磁盘(双一标准中的其一)
sync_binlog=1
解决方案：
5.6开始，加入了GTID,实现了GC(group commit)机制，可以并行传输日志给从库IO
5.7开始，不开启GTID，会自动维护匿名的GTID,也能实现GC，建议开启GTID
大事务拆成多个小事务，可以有效的减少主从延时
group commit （需要配合GTID来实现的）
3.从库
SQL线程导致的主从延时
在CR（传统模式）复制情况下，从库默认情况下只有一个SQL线程，只能串行回放事务SQL
1.从库默认情况下只有一个SQL，只能串行回放事务SQL
2.主库如果并发事务量较大，从库只能串行回放
3.主库发生大事务，会阻塞后续的所有的事务的运行
解决方案：
1 5.6版本开启GTID之后，加入了SQL多线程的特性，但是只能针对不同库（database）下的事务进行并发回放
2 5.7版本开启GTID之后，在SQL方面，提供了基于逻辑时钟(logical_clock),binlog加入了sql_no机制，真正 实现了基于事务级别的并发回放，这种技术称之为MTS(enhanced multi-threaded slave)
大事务拆成多个小事务，可以有效的减少主从延时
1. 延时从库
介绍
是我们认为配置的一种特殊从库.人为配置从库和主库延时N小时
为什么要有延时从
数据库故障
物理损坏
主从复制非常擅长解决物理损坏.
逻辑损坏
普通主从复制没办法解决逻辑损坏
配置延时从库
SQL线程延时:数据已经写入relaylog中了,SQL线程"慢点"运行
一般企业建议3-6小时,具体看公司运维人员对于故障的反应时间
mysql>stop slave;
mysql>CHANGE MASTER TO MASTER_DELAY = 300;
mysql>start slave;
mysql> show slave status \G
SQL_Delay: 300
SQL_Remaining_Delay: NULL
2 延时从库应用
逻辑故障的恢复思路
1.及时发现主库发生了逻辑损坏
2.立即停止延时从库的SQL线程
3.挂维护页
4.截取relay进行恢复(人为模拟SQL线程工作，直到drop之前)
起点：stop sql线程时的relaylog位置点
终点：drop 之前的位置点
5.截取的日志恢复到从库
6.从库替代主库工作
故障模拟及恢复案例
1.确定延时从库开启
[(none)]>show slave status\G
SQL_Delay: 300
SQL_Remaining_Delay: NULL
2.对数据库进行修改及故障模拟
主库：
[(none)]>create database delay charset utf8;
[(none)]>use delay;
[delay]>create table t1 (id int);
[delay]>insert into t1 values(1),(2),(3);
[delay]>commit;
3.删除测试库
[delay]>drop database delay;
4.发现故障，并立即停止从库SQL线程
[(none)]>stop slave sql_thread;
截取从库relaylog
起点:
show slave status\G
Relay_Log_File: db01-relay-bin.000002
Relay_Log_Pos: 476
或者：
cd /data/3308/data/
cat relay-log.info
db01-relay-bin.000002
476
终点:
[(none)]>show relaylog events in 'db01-relay-bin.000010';
db01-relay-bin.000002 | 1302 | Query | 7 | 1992 | drop database delay
进行截取
mysqlbinlog --start-position=476 --stop-position=1302 /data/3308/data/db01-relay-bin.0000010>/tmp/relay.sql
从库恢复数据
mysql -S /data/3308/mysql.sock
set sql_log_bin=0
source /tmp/relay.sql
解除从库身份
[delay]>stop slave;
[delay]>reset slave all;
还原环境
1. 删除从库delay库
mysql -S /data/3308/mysql.sock
drop database delay;
2. 确认主库二进制日志位置
mysql -S /data/3307/mysql.sock
show master status;
3. 构建主从
CHANGE MASTER TO
MASTER_HOST='10.0.0.51',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000010',
MASTER_LOG_POS=1115,
MASTER_CONNECT_RETRY=10;
>start slave;