请选择 进入手机版 | 继续访问电脑版

14:主从复制-配置主从延时、半同步复制、过滤复制、延时从库、GTID复制、

[复制链接]
小小海 发表于 2020-12-31 18:14:56 | 显示全部楼层 |阅读模式 打印 上一主题 下一主题
1.主从延时
1.1 什么是主从延时?
主库做了操作,从库很久没跟上.
1.2 怎么监控?
通过日志的时间戳隔断:
Seconds_Behind_Master: 0
通过日志量判定?
非GTID :
(主库show master status–> Position) - (从库 show slave status—> Exec_Master_Log_Pos) = 日志量差别
GTID:
可以用GTID号码判定.
1.3 原因?
1.3.0 外部 :
网络慢 .
主从硬件设置差别大.
参数.
版本(只支持从低到高.不支持从高到低).
1.3.1 主库 :
dump 是串行工作的.如果主库并发事务量高,大概大事务时.传输时就会有较高延时.
办理方案: 5.6+版本,到场了Group Commit(GC)技能.两个指标时间延时+个数控制举行组提交.但是依然怕大事务.
binlog_group_commit_sync_delay=1
binlog_group_commit_sync_no_delay_count=1000
1.3.2 从库 :
SQL默认是串行工作的. 主库的并发事务量大大概大事务.都会导致 SQL线程回放慢.
办理方案:
5.6版本: 到场了SQL线程并发回放机制. 以database级别举行并发回放.
意思是,只要主库中的事务是来自于不同库的操作,可以并发回放.
5.7+版本: 到场了Logical_clock模式,使得在主库可以或许group commit的事务(last_committed=8),而且根据sequence_number=9在从库并发回放
slave_parallel_type = DATABASE / logical_clock
slave_parallel_workers = 0
8.0+ writesets 写聚集方式. MGR.
综上所述:
1. 汗青遗留的延时问题,在版本升级过程中根本办理了.
2. 所以主从延时,我们面对的问题就是优化业务. 所以淘汰大事务,锁问题,性能较差SQL才是优化主从延时的重点.
2.主从数据最终一致性包管—(增强)半同步复制
commit原理:
commit分为两个阶段:(称之为2pc)
prepare、commit
  1. 当执行commit时首先会在redo prepare中执行一下动作:固然以下两个动作是由一个参数来控制的:innnodb_flush_log_at_trx_commit=1,此参数的意思是只要有提交,就将所有                                                                                                                  状态都执行一下动作:flush_log(刷新到文件系统缓存)sync_log(同步到磁盘的ib_logfile)中随后进入下一个环节:binlog prepare然后到达binlog commit,在这里会执行flush以及sync操作。最终到达redo commit环节:将所有带有prepare标志的全部修改为commit状态此时在到达redo commit环节时如果发生宕机后,系统下次再次开启的时候会做以下处理处罚:带有commit标签的,系统会将其加载到内存中举行redo重做带有prepare状态的,系统在将其拿到内存中重做时发现时prepare状态,这时就会在binlog中找到对应的事务,binlog中对应的事务一定是commit状态的,所以最终会举行redo前滚操作。如果是没有commit标签,也不带prepare标签系统会怎么做呢?首先将其加载到内存中,然后举行redo,随后在undo回滚掉。
复制代码
2.1 半同步复制-after_commit 和 after_sync
5.5开始支持半同步复制,但是没有GC机制,性能极差,时机没人用
5.6 版本时 ,到场了GC机制,半同步复制开始被吸收.使用的是after_commit机制,但是是在redo commit之后举行期待ACK确认.
这里会有一个痛点,如果主库redo commit阶段宕机宕机了,从库又获取到了binlog,会出现从库比主库数据"多"的问题.导致数据不一致.
5.7版本+以后,到场了after_sync机制,在binlog commit(binlog sync disk)阶段,期待从库ACK,不管谁宕机,都能包管最终一致性.
另外:
不管哪种方式,还会出现,如果ACK超时,会被切换为异步复制的模式.照旧有数据不一致的风险.
如果公司能容忍,可以使用这种架构,发起使用增强半同步+GTID模式.
如果不能容忍,可以使用MGR PXC .
简化总结
5.5 出现概念,但是不发起使用,性能太差
5.6出现group commit 组提交功能,来提升开启半同步复制的性能
5.7更加完善了,在group commit根本上出现了MGR
5.7的增强半同步复制的新特性:after commit; after sync;
2.2 增强半同步复制设置
2.2.1 加载插件
INSTALL PLUGIN rpl_semi_sync_master SONAME ‘semisync_master.so’;
INSTALL PLUGIN rpl_semi_sync_slave SONAME ‘semisync_slave.so’;
2.2.2 检察是否加载乐成:
show plugins;
启动:
SET GLOBAL rpl_semi_sync_master_enabled = 1;
SET GLOBAL rpl_semi_sync_slave_enabled = 1;
2.2.3 重启从库上的IO线程
STOP SLAVE IO_THREAD;
START SLAVE IO_THREAD;
2.2.4 检察是否在运行
show status like ‘Rpl_semi_sync_master_status’;
show status like ‘Rpl_semi_sync_slave_status’;
2.2.5 其他的优化参数:
show variables like ‘%semi%’;
rpl_semi_sync_master_enabled =ON
rpl_semi_sync_master_timeout =1000
rpl_semi_sync_master_trace_level =32
rpl_semi_sync_master_wait_for_slave_count =1
rpl_semi_sync_master_wait_no_slave =ON
rpl_semi_sync_master_wait_point =AFTER_SYNC
rpl_semi_sync_slave_enabled =ON
rpl_semi_sync_slave_trace_level =32
mysql> set global binlog_group_commit_sync_delay =1;
mysql> set global binlog_group_commit_sync_no_delay_count =1000;
3.主从复制演变–过滤复制
3.1 什么是过滤复制?
选择性复制.
3.2 应用场景
业务的分离.
部门数据同步.
3.3 如何实现
主库 : 是否记录binlog来控制
binlog_do_db : 白名单
binlog_ignore_db : 黑名单
白名单:只记录白名单中列出的库的二进制日志
黑名单:不记录黑名单列出的库的二进制日志
从库 : SQL线程是否回放来控制
replicate_do_db=world
replicate_ignore_db=test
replicate_do_table=world.city
replicate_ignore_table:test.t100w
replicate_wild_do_table=oldboy.t*
replicate_wild_ignore_table=oldguo.t*
白名单:只执行白名单中列出的库大概表的中继日志
黑名单:不执行黑名单中列出的库大概表的中继日志
3.4 设置演练:
mysql> stop slave sql_thread;
mysql> change replication filter replicate_do_db = (oldguo, test);
mysql> start slave sql_thread;
4.延时从库
4.1介绍
是我们认为设置的一种特殊从库.人为设置从库和主库延时N小时.
4.2 为什么要有延时从
什么是数据库损坏?
物理损坏
主从复制非常擅长办理物理损坏.
逻辑损坏
平常主从复制没办法办理逻辑损坏
4.3 设置延时从库
SQL线程延时:数据已经写入relaylog中了,SQL线程"慢点"运行
一般企业发起3-6小时,详细看公司运维人员对于故障的反应时间。
stop slave;
CHANGE MASTER TO MASTER_DELAY = 300;
start slave;
4.4 延时从库应用 *****
4.4.1 故障规复思路
a. 发现问题
b. 停掉从库线程
c. 控制SQL回放日志的停止位置点.
d. 找回数据,快速规复业务
4.4.2 故障模仿及规复演练
stop slave;
CHANGE MASTER TO MASTER_DELAY = 300;
start slave;
create database relaydb ;
use relaydb;
create table t1(id int);
insert into t1 values(1),(2),(3);
commit;
insert into t1 values(11),(12),(13);
commit;
insert into t1 values(111),(112),(113);
commit;
drop database relaydb;
处理处罚过程
show relaylog events in ‘db02-relay-bin.000002’
| db02-relay-bin.000002 | 1732 | Xid | 51 | 3385 | COMMIT /* xid=2212 / |
| db02-relay-bin.000002 | 1763 | Gtid | 51 | 3462 | SET @@SESSION.GTID_NEXT= ‘00bf718b-491c-11eb-81a2-000c2905f029:24’ |
| db02-relay-bin.000002 | 1840 | Query | 51 | 3575 | drop database relaydb /
xid=2214 */
stop slave sql_thread;
CHANGE MASTER TO MASTER_DELAY = 0;
START SLAVE SQL_THREAD UNTIL RELAY_LOG_FILE = ‘db02-relay-bin.000002’, RELAY_LOG_POS = 1763 ;
如果开启GTID,可以按照GTID方式UNTIL
START SLAVE UNTIL SQL_BEFORE_GTIDS = “188be1ed-c84c-11ea-98e7-000c29ea9d83:4”;
5.GTID复制
5.1 GTID引入
5.2 GTID介绍
GTID(Global Transaction ID)是对于一个已提交事务的唯一编号,而且是一个全局(主从复制)唯一的编号。
它的官方界说如下:
GTID =server_uuid : transaction_id
7E11FA47-31CA-19E1-9E56-C43AA21293967:29
什么是sever_uuid,和Server-id 区别?
核心特性: 全局唯一,具备幂等性
5.3 GTID核心参数
重要参数:
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
gtid-mode=on --启用gtid范例,否则就是平常的复制架构
enforce-gtid-consistency=true --强制GTID的一致性
log-slave-updates=1 --slave更新是否记入日志
5.4 GTID复制设置过程:
5.4.1 清理情况
pkill mysqld
\rm -rf /data/3306/data/*
\rm -rf /data/3306/binlog/*
\mv /etc/my.cnf /tmp
mkdir -p /data/3306/data /data/3306/binlog/
chown -R mysql.mysql /data/*

5.4.2 准备设置文件
主库db01:
cat > /etc/my.cnf  /etc/my.cnf  /etc/my.cnf  /etc/my.cnf  /etc/my.cnf  /etc/my.cnf SHOW SLAVE STATUS FOR CHANNEL 'Master_1'\Gdb03 [(none)]>SHOW SLAVE STATUS FOR CHANNEL 'Master_2'\Gselect * from performance_schema.replication_connection_configuration\GSELECT * FROM performance_schema.replication_connection_status WHERE CHANNEL_NAME='master_1'\Gselect * from performance_schema.replication_applier_status_by_worker;[/code] d.多源复制设置过滤

  1. mysql> CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE = ('db1.%') FOR CHANNEL "master_1";mysql> CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE = ('db2.%') FOR CHANNEL "master_2";
复制代码
来源:https://blog.csdn.net/xiaoleinb/article/details/111997376
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则


专注素材教程免费分享
全国免费热线电话

18768367769

周一至周日9:00-23:00

反馈建议

27428564@qq.com 在线QQ咨询

扫描二维码关注我们

Powered by Discuz! X3.4© 2001-2013 Comsenz Inc.( 蜀ICP备2021001884号-1 )