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

验证主从的状态

show slave status\G;
两个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自动退出

架构原理

主库宕机处理过程

监控节点 (通过配置文件获取所有节点信息)
系统,网络,SSH连接性
主从状态,重点是主库
选主
(1) 如果判断从库(position或者GTID),数据有差异,最接近于Master的slave,成为备选主
(2) 如果判断从库(position或者GTID),数据一致,按照配置文件顺序,选主.
(3) 如果设定有权重(candidate_master=1),按照权重强制指定备选主.
1. 默认情况下如果一个slave落后master 100M的relay logs的话，即使有权重,也会失效.
2. 如果check_repl_delay=0的化,即使落后很多日志,也强制选择其为备选主
数据补偿
(1) 当SSH能连接,从库对比主库GTID 或者position号,立即将二进制日志保存至各个从节点并且应用(save_binary_logs )
(2) 当SSH不能连接, 对比从库之间的relaylog的差异(apply_diff_relay_logs)
Failover
将备选主进行身份切换,对外提供服务
其余从库和新主库确认新的主从关系
应用透明(VIP)
故障切换通知(send_reprt)
二次数据补偿(binlog_server)
自愈自治(待开发...)

posted @ 2021-05-11 09:31 gidos 阅读(62) 评论(0) 编辑收藏举报

huuyann

mysql_10 特殊的主从复制

mysql_10 特殊的主从复制

延迟从库

配置

恢复思路:

过滤复制

配置方法1

配置方法2

半同步复制

GTID复制

搭建：

生成配置文件

检查关键信息

主库建立复制用户

主库备份恢复到从库

告知从库信息

开启专用的复制线程

验证主从的状态

如果失败去除主从

主从复制架构演变

原生态支持：

非原生

性能

高可用和读写分离 mha

规划

准备

下载安装软件

创建用户并配置manager

状态检查

mha failover过程原理

架构原理

公告

huuyann

mysql_10 特殊的主从复制

mysql_10 特殊的主从复制

延迟从库

配置

恢复思路:

过滤复制

配置方法1

配置方法2

半同步复制

GTID复制

搭建：

生成配置文件

检查关键信息

主库建立复制用户

主库备份恢复到从库

告知从库信息

开启专用的复制线程

验证主从的状态

如果失败 去除主从

主从复制架构演变

原生态支持：

非原生

性能

高可用和读写分离 mha

规划

准备

下载安装软件

创建用户并配置manager

状态检查

mha failover过程原理

架构原理

公告

如果失败去除主从