第九章 主从复制之高级进阶

延时从库

介绍与作用

介绍:是我们认为配置的一种特殊从库.人为配置从库和主库延时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 status\G        
               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
 \rm -rf /data/mysql/data/*
 \rm -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';"

52\53:
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

posted @ 2019-12-21 16:36  OneLpc  阅读(210)  评论(0编辑  收藏  举报