延时从库
介绍与作用
介绍:是我们认为配置的一种特殊从库.人为配置从库和主库延时N小时.
作用:处理逻辑损坏,误删除
实现方法
SQL线程延时:数据已经写入relaylog中了,SQL线程"慢点"运行
一般企业建议3-6小时,具体看公司运维人员对于故障的反应时间
延时从库配置
# 停止从库
stop slave;
# 设置延时时长
CHANGE MASTER TO MASTER_DELAY = 300;
# 开启从库
start slave;
# 查看状态(是否配置成功)
show slave status G
SQL_Delay: 300
SQL_Remaining_Delay: NULL
延时从库应用
故障恢复思路
(1) 感知到故障.
(2) 停相关业务,挂维护页.
(3) 停延时从库SQL线程.
(4) 手工模拟SQL线程恢复后续的relaylog
起点: relaylog.info
终点: drop
(5) 直接解除从库替代主库工作
或者,导出故障数据库,倒回到生产.
``
#### 故障模拟
```MYSQL
-- 1)数据模拟 -- 主库操作
create database oldboy charset utf8mb4;
use oldboy;
create table t1(id int);
insert into t1 values(1);
insert into t1 values(11);
insert into t1 values(111);
insert into t1 values(1111);
-- 2) 误删除模拟 -- 主库操作
drop database oldboy;
-- 3)停止从库线程 -- 从库操作
stop slave sql_thread;
-- 4)截取relaylog日志 -- 从库操作
# 找到relaylog 起始位置
mysql[(none)]>show slave statusG
Relay_Log_File: db01-relay-bin.000002
Relay_Log_Pos: 482
# 找到relaylog 结束位置
mysql[(none)]>show relaylog events in 'db01-relay-bin.000002'
1922
# 将截取数据导出
mysqlbinlog --start-position=476 --stop-position=2174 /data/3308/data/db01-relay-bin.000002 >/tmp/relay.sql
-- 5)恢复数据 -- 从库操作
mysql> set sql_log_bin=0;
mysql> source /tmp/relay.sql
过滤复制
过滤复制分类
1)根据业务垂直拆分的过滤复制
2)复制主库下指定库到从库的过滤复制
通过IO 线程的控制,接受指定库的binlog日志,不接受其他库的binlog日志,从而实现指定库的过滤复制
主库方面实现
binlog_do_db= # 白名单,再此参数中的库,记录二进制日志
binlog_ignore_db= # 黑名单,在此参数中的库,不记录二进制日志
从库方面实现
# 库级别的控制 -- 应用多
Replicate_Do_DB: # 白名单,在此参数中的库,复制
Replicate_Ignore_DB: # 黑名单,在此参数中的库,不复制
# 表级别的控制
Replicate_Do_Table: # 白名单,复制
Replicate_Ignore_Table: # 黑名单,不复制
# 模糊的表名字
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
'说明:为不同的库中,这些表必须无关联,不测就要进行业务上的判断,比较麻烦,不如使用中间件的架构。'
过滤复制实现
例子:只复制至oldboy库的数据(从库)
vim /data/3308/my.cnf
replicate_do_db=oldguo
# 多个库的话,需要写多行
# 修改完my.cnf文件后需要重启服务
复制
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复制配置
清理环境
pkill mysqld
m -rf /data/mysql/data/*
m -rf /data/binlog/*
mkdir -p /data/mysql/data
chown -R mysql.mysql /data/*
准备配置文件
#主库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
#slave1(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
# slave2(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
初始化数据()
mkdir -p /data/mysql/data
chown -R mysql.mysql /data/*
mysqld --initialize-insecure --user=mysql --basedir=/application/mysql --datadir=/data/mysql/data
启动数据库
/etc/init.d/mysqld start
构建主从:
master:51
slave:52,53
51:
mysql -e "grant replication slave on *.* to repl@'10.0.0.%' identified by '123';"
5253:
mysql -e "change master to master_host='10.0.0.51',master_user='repl',master_password='123' ,MASTER_AUTO_POSITION=1;"
mysql -e "start slave;"
# 查看状态
[root@db02 ~]# mysql -e "show slave status G"|grep "Running:"
复制和普通复制的区别
CHANGE MASTER TO
MASTER_HOST='10.0.0.51',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=444,
MASTER_CONNECT_RETRY=10;
change master to
master_host='10.0.0.51',
master_user='repl',
master_password='123' ,
MASTER_AUTO_POSITION=1;
start slave;
(0)在主从复制环境中,主库发生过的事务,在全局都是由唯一GTID记录的,更方便Failover
(1)额外功能参数(3个)
(2)change master to 的时候不再需要binlog 文件名和position号,MASTER_AUTO_POSITION=1;
(3)在复制过程中,从库不再依赖master.info文件,而是直接读取最后一个relaylog的 GTID号
(4)mysqldump备份时,默认会将备份中包含的事务操作,以以下方式
SET @@GLOBAL.GTID_PURGED='8c49d7ec-7e78-11e8-9638-000c29ca725d:1';
告诉从库,我的备份中已经有以上事务,你就不用运行了,直接从下一个GTID开始请求binlog就行。
半同步复制
ACK
ACK_Receiver
扩展:
MGR
PXC