mysql_10 特殊的主从复制

mysql_10 特殊的主从复制

标签（空格分隔）： mysql

---

延迟从库

普通的主从复制，只能帮忙处理物理故障
如果主库出现了drop database操作。
延迟从库，主库做了某项操作之后，从库延迟多长时间回放(sql).可以处理逻辑损坏。

配置

从库

stop slave;
change master to master_delay = 300 #秒为单位
start slave
show slave status G

恢复思路:

1.先停业务，挂维护页
2.停止从库
stop slave sql_thread;
看relay.info 位置点信息
stop slave

3.追加后续缺失部分的日志到从库
日志在那？ 从库的relay-log
范围： relay.info ---> drop +drop之后到发觉时间的日志
起点 relay.info
终点：show relaylog events in 'db01-relay-bin.000002'
drop之前的起点 作为终点

mysqlbinlog --start-position=xxx --stop-position=xxx relaylog 日志 > /tmp/xx.sql

set sql_log_bin = 0
source xx.sql
set sql_log_bin = 1

4.方案
a 导出sql 恢复至主库
b 从变主 其他服务指向从库

过滤复制

配置方法1

主库不记录

my.cnf修改
主库：

binlog_do_db=world,test,my    #白名单 只复制这些库
binlog_ignore_db  #黑名单  不复制这些库

配置方法2

从库接受但是sql线程不回放

my.cnf修改

#库级别
replicate_do_db=world
replicate_ignore_db=

#表级别
replicate_do_table=world.t1
replicate_ignore_table=

#world下的t开头的表
replicate_wild_do_table=world.t*
replicate_wild_ignore_table=

半同步复制

classic replication： 传统异步复制 非gtid复制工作模型下，会导致主从数据不一致情况。
5.5 版本为了保证主从数据的一致性问题。
加入了半同步复制的组件（插件）

主从结构中，都加入了半同步复制的插件
控制从库io是否将relaylog落盘，一旦落盘通过插件返回ack给主库ack_rec。接受ACK之后，主库的事务才能提交成功。在默认情况下，如果超过10秒没有返回ack，此次复制行为会切换为异步复制。
在5.6 5.7 当中也加入了一些比较号的特性，也不能完全保证100%的数据一致。
如果生产业务比较关注主从最终一致。推荐使用MGR的架构，或则PXC等一致性架构。

会对性能产生影响，所以也只是个暂时使用的方法。后面推出了mgr用以代替了

GTID复制

作用：主要保证主从复制中高级的特性。
5.6 开始出现的 没有默认开启
5.7 默认开启匿名gtid dump传输可以并行，sql线程并发回访提供了保障，5.7.17+的版本以后几乎都是GTID模式了

搭建：

三台虚拟机
三个ip

生成配置文件

cat > /etc/my.cnf << EOF
[mysqld]
basedir= /app/database/mysql
datadir= /data/mysql/
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=db1 [\d]>
EOF

#初始化数据
mysqld --initialize-insecure --user=mysql --basedir=/app/database/mysql --datadir=/data/mysql/

basedir= /app/database/mysql
datadir= /data/mysql/
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=db2 [\d]>
EOF

#初始化数据
mysqld --initialize-insecure --user=mysql --basedir=/app/database/mysql --datadir=/data/mysql/

注意 mariadb 10.3以上 默认开启gtid 下面两条无需添加 添加了会报错
gtid_mode=on
enforce-gtid-consistency=true

检查关键信息

检查server_id
mysql -S /tmp/mysql.sock -e "select @@server_id;"
mysql -S /tmp/mysql.sock -e "select @@server_id;"

检查binlog
mysql -S /tmp/mysql.sock -e "select @@log_bin"

主库建立复制用户

mysql -S /tmp/mysql.sock -e "grant replication slave on . to repl@'10.0.%' identified by '123' "
mysql -S /tmp/mysql.sock -e "select user,host from mysql.user"

主库备份恢复到从库

备份
mysqldump -S /tmp/mysql.sock -A --master-data=2 --single-transaction > /tmp/full.sql

恢复到从库中
mysql -S /tmp/mysql.sock < /tmp/all.sql
mysql -S /tmp/mysql.sock < /tmp/all.sql

告知从库信息

mysql

CHANGE MASTER TO
MASTER_HOST='10.0.0.60',           #地址
MASTER_USER='repl',             # 复制用户
MASTER_PASSWORD='Mysql@repl',                #密码
MASTER_PORT=3306,                       # 端口号
MASTER_AUTO_POSITION = 1,              # 自动索引gtid号
MASTER_CONNECT_RETRY=20;            # 重试次数

mariadb

CHANGE MASTER TO
MASTER_HOST='10.0.0.60',           #地址
MASTER_USER='repl',             # 复制用户
MASTER_PASSWORD='Mysql@repl',                #密码
MASTER_PORT=3306,                       # 端口号
MASTER_USE_GTID=current_pos,             # 自动索引gtid号
MASTER_CONNECT_RETRY=20;            # 重试次数

开启专用的复制线程

mysql -S /tmp/mysql.sock
start slave

mysql -S /tmp/mysql.sock
start slave

验证主从的状态

show slave statusG;
两个yes 表示主从成功
Slave_IO_Running:YES
Slave_SQL_Running:YES

Retrieved_Gtid_Set: 接收到的gtid
Executed_Gtid_Set:运行到的gtid

有了gtid position号就不用重点关注了

如果失败 去除主从

stop slave;
reset slave all;

主从复制架构演变

原生态支持：

1主1从
1主多从（3-4）
多级主从
双主结构
延时从库
过滤复制
MGR组复制(5.7.17+)

非原生

安全： 高可用
全年无故障率：
99% 一般级别
99.9% 普通高可用
99.99% 准高可用

MHA 高可用
99.999% 金融级别

mysql cluster、innodb cluster、pxc、mgc、oracle rac、sysbase cluster
99.9999% 超金融级别

性能

读多写少： 读写分离
altas、proxysql、maxscale、mycat

什么都多： 分布式方案
mycat(DBLE) atlas_sharding, sharding-jdbc

高可用和读写分离 mha

三个以上的节点 1主2从，不能是多实例
多节点ssh互通

manager 管理软件
masterha_manager #启动mha
masterha_check_ssh #mha ssh配置情况
masterha_check_repl #mysql复制情况
masterha_check_monitor #master是否宕机
masterha_check_status #mha 运行状态
masterha_master_switch #控制故障转移
masterha_conf_host #添加或删除配置的server信息

node: 被管理软件
这些工具通常由mha manager的脚本触发，无需人为操作
save_binary_logs 保存和复制master的二进制日志
apply_diff_relay_logs 识别差异的中继日志时间并将其差异的事件应用于其他的
purge_relay_logs 清除中继日志(不会堵塞sql线程)

规划

主库
51 node
从库
52 node
53 node manager

准备

1主2从 gtid

配置关键程序软连接（所有节点）
ln -s /sort/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
ln -s /sort/mysql/bin/mysql /usr/bin/mysql

配置各节点互通（密钥对）

rm -rf /root/,ssh
ssh-keygen
cd /root/.ssh
mv id_rsa.pub authorized_keys
scp -r /root/,ssh  10.0.0.52:/root/
scp -r /root/,ssh  10.0.0.53:/root/

ssh 10.0.0.51
ssh 10.0.0.52
ssh 10.0.0.53

下载安装软件

github
https://github.com/yoshinorim/mha4mysql-manager

node 都要安装
https://github.com/yoshinorim/mha4mysql-node/releases/tag/v0.58

manager 单独节点安装
https://github.com/yoshinorim/mha4mysql-manager/releases/tag/v0.58

8.0版本 -》 密码加密模式sha2 改回native

安装 所有节点
https://github.com/yoshinorim/mha4mysql-manager/wiki/Installation#downloading-mha-node-and-mha-manager

yum install perl-DBD-MySQL perl

yum -y install mha4mysql-node-0.58.tar.gz

创建用户并配置manager

在db01中创建用户

grant all privileges on *.* to mha@'10.0.%' identified by 'mha';

#安装manager
yum -y install mha4mysql-manager-0.58-0.el7.centos.noarch.rpm

#创建配置文件目录
mkdir -p /etc/mha

#创建日志目录
mkdir -p /var/log/mha/app1

#编辑mha配置文件
cat  /etc/mha/app1.cnf << EOF
[server default]
manager_log=/var/log/mha/app1/manager
manager_workdir=/var/log/mha/app1
master_binlog_dir=/data/binlog
user=mha
password=mha
ping_interval=2
repl_password=123
repl_user=repl
ssh_user=root
[server1]
hostname=10.0.0.51
port=3306
[server2]
hostname=10.0.0.52
port=3306
[server3]
hostname=10.0.0.53
port=3306
EOF

状态检查

masterha_check_ssh --conf=/etc/mha/app1.cnf
masterha_check_repl --conf=/etc/mha/app1.cnf

mha failover过程原理

1.启动manager
调用masterha_manager脚本启动manager程序
2.监控
通过masterha_master_minitor心跳检测脚本，数据库节点、主要监控主库
默认探测4次，每隔（ping_interval=2）秒,如果主库没有心跳了，认为主库宕机
进入failover过程
3.选主？
a.优先级，如果在节点配置，加入了candidate_master=1参数
如果备选主，日志量落后master太多（后master 100M的relay logs） 也不会被选择为新主
可以通过check_repl_delay=0 不检查日志落后的情景
b.日志量最接近主库
c.日志量一样，配置文件顺序
4.日志补偿
ssh能连接上，通过save_binary_logs
立即保存丢失部分的日志到从库（var/tmp/目录下） 并恢复
ssh无法连接，两个从库进行relaylog日志diff（apply_diff_relay_logs） 差异补偿

5.主从身份切换，所有从库取消和原有主库的复制关系（stop slave,reset slave all）
新主库和剩余从库重新构建主从关系
6.故障库自动被剔除集群(masterha_conf_host 配置去掉)
7.mha是一次性的高可用，failover之后，manager自动退出

架构原理

主库宕机处理过程

1. 监控节点 (通过配置文件获取所有节点信息)
   系统,网络,SSH连接性
   主从状态,重点是主库

2. 选主
   (1) 如果判断从库(position或者GTID),数据有差异,最接近于Master的slave,成为备选主
   (2) 如果判断从库(position或者GTID),数据一致,按照配置文件顺序,选主.
   (3) 如果设定有权重(candidate_master=1),按照权重强制指定备选主.

   1. 默认情况下如果一个slave落后master 100M的relay logs的话，即使有权重,也会失效.
   2. 如果check_repl_delay=0的化,即使落后很多日志,也强制选择其为备选主

3. 数据补偿
   (1) 当SSH能连接,从库对比主库GTID 或者position号,立即将二进制日志保存至各个从节点并且应用(save_binary_logs )
   (2) 当SSH不能连接, 对比从库之间的relaylog的差异(apply_diff_relay_logs)

4. Failover
   将备选主进行身份切换,对外提供服务
   其余从库和新主库确认新的主从关系

5. 应用透明(VIP)

6. 故障切换通知(send_reprt)

7. 二次数据补偿(binlog_server)

8. 自愈自治(待开发...)