延时从库

延时从库介绍

  • SQL线程延时:数据已经写入relaylog中了,SQL线程还没有进行回放,可以用于误操作后快速恢复业务,一般企业建议3-6小时,具体看公司运维人员对于故障的反应时间

延时从库设置

#停止从库
stop slave;
#设置延时
CHANGE MASTER TO MASTER_DELAY = 300;
#开启从库
start slave;
#查看状态
show slave status \G

延时从库处理逻辑故障

主库出现误操作后,通过延时从库进行恢复

  • 误操作内容
create database relay charset utf8mb4;
use relay;
create table t1 (id int);
insert into t1 values(1),(2),(3);
commit;
drop database relay;
  • 停从库SQL线程,记录已经回放的位置点(截取日志起点)
#停从库SQL线程
stop slave sql_thread;
#记录Relay_Log_File和Relay_Log_Pos
show slave status \G
  • 查看relaylog日志,记录日志到drop database delay;操作之前
show relaylog events in 'db01-relay-bin.000002';
  • 根据relaylog的起点和中间截取日志
#进入到relaylog目录下,截取日志
mysqlbinlog --start-position=320 --stop-position=993 db01-relay-bin.000002 > /tmp/relay.sql
  • 登录后恢复到从库

如果无其他意外可以将恢复的从库变为主库,也可以将恢复后的数据导出后恢复到主库再开启业务

#登录从库后关闭日志进行恢复,完成后开启日志
set sql_log_bin=0;
source /tmp/relay.sql
set sql_log_bin=1;

过滤复制

主库

  • Binlog_Do_DB : binlog记录的库,即白名单,show master status;命令可以看到该参数的值
  • Binlog_Ignore_DB : binlog忽略的库,即黑名单,show master status;命令可以看到该参数的值

从库

  • Replicate_Do_DB : relaylog回放的库
  • Replicate_Ignore_DB : relaylog忽略回放的库
  • Replicate_Do_Table : relaylog回放的表
  • Replicate_Ignore_Table : relaylog忽略回放的库
  • Replicate_Wild_Do_Table : relaylog回放的表,可以模糊指定某个字符串开头的表
  • Replicate_Wild_Ignore_Table : relaylog忽略回放的库,可以模糊指定某个字符串开头的表
#以上所有参数在my.cnf设置时需要小写,1个库写一行,否则会认为是同一个库.黑名单和白名单选择使用其中1个即可
#错误示范
binlog_do_db=db1,db2,db3
binlog_ignore_db=db1,db2,db3

#正确示范
binlog_do_db=db1
binlog_do_db=db2
binlog_do_db=db3
binlog_ignore_db=db1
binlog_ignore_db=db2
binlog_ignore_db=db3

GTID复制

GTID(Global Transaction ID)是对于一个已提交事务的唯一编号,并且是一个全局(主从复制)唯一的编号

  • 它的官方定义如下：
  • GTID = source_id ：transaction_id
  • 7E11FA47-31CA-19E1-9E56-C43AA21293967:29
  • 什么是sever_uuid和Server-id区别是什么
  • 核心特性:全局唯一,具备幂等性

GTID核心参数

  • gtid-mode=on : 启用gtid类型,否则就是普通的复制架构
  • enforce-gtid-consistency=true : 强制GTID的一致性
  • log-slave-updates=1 : slave更新是否记入日志

GTID复制配置过程

清理环境

#杀掉mysql进程
pkill mysqld
#删除数据和二进制日志
rm -rf /data/mysql/data/*
rm -rf /data/binlog/*

准备配置文件

  • db01
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
  • db02
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/application/mysql
datadir=/data/mysql/data
socket=/tmp/mysql.sock
server_id=52
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=db02 [\\d]>
EOF
  • db03
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/application/mysql
datadir=/data/mysql/data
socket=/tmp/mysql.sock
server_id=53
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=db03 [\\d]>
EOF

初始化数据后启动数据库

mysqld --initialize-insecure --user=mysql --basedir=/application/mysql  --datadir=/data/mysql/data
systemctl status mysqld

构建主从

  • 主:db01
#创建同步用户
grant replication slave  on *.* to repl@'10.0.0.%' identified by '123456';
  • 从:db02,db03
#配置主库信息后开启同步
change master to 
master_host='10.0.0.51',
master_user='repl',
master_password='123456',
MASTER_AUTO_POSITION=1;
start slave;
#查看主从状态,查看IO和SQL的结果为yes即完成主从配置
show slave status\G

参数说明

  • MASTER_AUTO_POSITION=1 : 会读取relaylog最后一个事务的GTID,从该事务的下一个GTID进行读取MySQL官方文档

GTID复制和普通复制的区别

  • 在主从复制环境中,主库发生过的事务,在全局都是由唯一GTID记录的,更方便Failover
  • change master to的配置的参数不同
  • change master to的参数不再需要binlog文件名和position,只需要MASTER_AUTO_POSITION=1;
  • 在复制过程中,从库不再依赖master.info文件,而是直接读取最后一个relaylog的GTID
  • mysqldump备份时,默认会将备份中包含的事务操作,以记录当前GTID告诉从库(#### SET @@GLOBAL.GTID_PURGED='8c49d7ec-7e78-11e8-9638-000c29ca725d:1-11';),备份中已经有以上事务,你就不用运行了,直接从下一个GTID开始请求binlog就行

半同步

解决主从复制数据一致性问题

  • 原理:主库推送binlog等待从库relaylog写入磁盘后,IO线程返回的ack信号,主库的事务才会提交,如果主库一直没有收到ack,超过一定时间后(默认10秒),会切换为异步复制