延时从库
介绍,SQL线程延时:数据已经写入relaylog中了,SQL线程"慢点"运行，一般企业建议3-6小时,具体看公司运维人员对于故障的反应时间
为什么要有延时从
-
物理损坏
-
主从复制非常擅长解决物理损坏.
-
逻辑损坏
-
普通主从复制没办法解决逻辑损坏
配置（在从库上执行以下操作）
mysql>stop slave; mysql>CHANGE MASTER TO MASTER_DELAY = 300; mysql>start slave; mysql> show slave status \G
延时从库的恢复思路
(1) 监控到数据库逻辑故障
(2) 停从库SQL线程,记录已经回放的位置点(截取日志起点)
stop slave sql_thread ; show slave status \G Relay_Log_File: db01-relay-bin.000002 Relay_Log_Pos: 320
(3) 截取relaylog
起点:
show slave status \G Relay_Log_File ,Relay_Log_Pos 终点: drop之前的位置点 show relaylog events in '' 进行截取
(4) 模拟SQL线程回访日志
- 从库 source
(5) 恢复业务
情况一: 就一个库的话
- 从库替代主库工作
情况二:
- 从库导出故障库,还原到主库中.
延时从库处理逻辑故障
故障演练主库
create database delay charset utf8mb4; use delay; create table t1 (id int); insert into t1 values(1),(2),(3); commit; drop database delay;
从库:
1.停止 从库SQL 线程,获取relay的位置点 320， relay_log_file oldboyedu-relay-bin.000002
mysql> stop slave sql_thread; mysql> show slave status \G
2. 找到relay的截取终点 993
mysql> show relaylog events in 'oldboyedu-relay-bin.000002';
3. 截取relay
cd /data/3308/data/ mysqlbinlog --start-position=320 --stop-position=993 oldboyedu-relay-bin.000002 >/tmp/relay.sql
4. 恢复relay到从库
[root@db01 data]# mysql -uroot -p -S /data/3308/mysql.sock mysql> set sql_log_bin=0; mysql> source /tmp/relay.sql
快速恢复测试环境
drop database delay ; stop slave; reset slave all; show slave status \G
主库:
mysql> reset master;
从库:
[root@db01 ~]# mysql -S /data/3308/mysql.sock CHANGE MASTER TO MASTER_HOST='10.0.0.200', MASTER_USER='repl', MASTER_PASSWORD='123', MASTER_PORT=3307, MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154, MASTER_CONNECT_RETRY=10; start slave; show slave status \G
过滤复制应用
从库只复制指定的库
方法一：在主库进行配置，不常用（配置文件都是小写）
vi /data/3307/my.cnf # 白名单需要复制的库 binlog_do_db= # 黑名单忽略的库 binlog_ignore_db=
重启后执行可以看到
show master status;
方法二：在主库进行配置（一样设置白名单和黑名单）
mysql> show slave status \G
配置文件如下，只复制repl库
vim /data/3308/my.cnf replicate_do_db=repl systemctl restart mysqld3308
半同步（了解即可）
目的
解决主从数据一致性问题
半同步复制工作原理的变化
-
1. 主库执行新的事务,commit时,更新 show master status\G ,触发一个信号给
-
2. binlog dump 接收到主库的 show master status\G信息,通知从库日志更新了
-
3. 从库IO线程请求新的二进制日志事件
-
4. 主库会通过dump线程传送新的日志事件,给从库IO线程
-
5. 从库IO线程接收到binlog日志,当日志写入到磁盘上的relaylog文件时,给主库ACK_receiver线程
-
6. ACK_receiver线程触发一个事件,告诉主库commit可以成功了
-
7. 如果ACK达到了我们预设值的超时时间,半同步复制会切换为原始的异步复制.
配置半同步复制
加载插件 主: INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; 从: INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so'; 查看是否加载成功: show plugins; 启动: 主: SET GLOBAL rpl_semi_sync_master_enabled = 1; 从: SET GLOBAL rpl_semi_sync_slave_enabled = 1; 重启从库上的IO线程 STOP SLAVE IO_THREAD; START SLAVE IO_THREAD; 查看是否在运行 主: show status like 'Rpl_semi_sync_master_status'; 从: show status like 'Rpl_semi_sync_slave_status';
MHA环境搭建
GTID复制
介绍
GTID(Global Transaction ID)是对于一个已提交事务的唯一编号，并且是一个全局(主从复制)唯一的编号。 它的官方定义如下： GTID = source_id ：transaction_id 7E11FA47-31CA-19E1-9E56-C43AA21293967:29 什么是sever_uuid，和Server-id 区别？ 核心特性: 全局唯一,具备幂等性
GTID核心参数
gtid-mode=on enforce-gtid-consistency=true log-slave-updates=1 gtid-mode=on --启用gtid类型，否则就是普通的复制架构 enforce-gtid-consistency=true --强制GTID的一致性 log-slave-updates=1 --slave更新是否记入日志
GTID复制配置过程
(1) 清理环境3个节点都执行
pkill mysqld \rm -rf /data/mysql/data/* \rm -rf /data/binlog/*
(2) 准备配置文件
cat > /etc/my.cnf <<EOF [mysqld] basedir=/application/mysql/ datadir=/data/mysql/data socket=/tmp/mysql.sock server_id=51 port=3306 secure-file-priv=/tmp autocommit=0 log_bin=/data/binlog/mysql-bin binlog_format=row gtid-mode=on enforce-gtid-consistency=true log-slave-updates=1 [mysql] prompt=db01 [\\d]> EOF