10 MySQL-主从复制高级进阶

主从高级功能

延时从

介绍
是我们认为配置的一种特殊从库.人为配置从库和主库延时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

延时从库应用
思路 : 1主1从,从库延时5分钟,主库误删除1个库

5分钟之内 侦测到误删除操作
停从库SQL线程
截取relaylog
起点 :停止SQL线程时,relay最后应用位置
终点:误删除之前的position(GTID)
恢复截取的日志到从库
从库身份解除,替代主库工作
模拟故障:

主库数据操作

db01 [(none)]>create database relay charset utf8;
db01 [(none)]>use relay
db01 [relay]>create table t1 (id int);
db01 [relay]>insert into t1 values(1);
db01 [relay]>drop database relay;

停止从库SQL线程

stop slave sql_thread;

找relaylog的截取起点和终点
起点:

Relay_Log_File: db01-relay-bin.000002
Relay_Log_Pos: 482

终点:

show relaylog events in 'db01-relay-bin.000002'
| db01-relay-bin.000002 | 1046 | Xid            |         7 |        2489 | COMMIT /* xid=144 */                  |
| db01-relay-bin.000002 | 1077 | Anonymous_Gtid |         7 |        2554 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'  |

mysqlbinlog --start-position=482 --stop-position=1077  /data/3308/data/db01-relay-bin.000002>/tmp/relay.sql

从库恢复relaylog

source /tmp/relay.sql

5.从库身份解除

db01 [relay]>stop slave;
db01 [re