码迷,mamicode.com
首页 > 编程语言 > 详细

DAY7-剖析复制线程

时间:2018-05-28 19:46:59      阅读:214      评论:0      收藏:0      [点我收藏+]

标签:包含   显示   操作   cti   金融   用户   tips   ica   cloc   

 

高可用:
两地双中心概念
同城:同IDC:增强半同步复制
跨城:异步复制

两地三中心:(金融支付银行)
同城:跨IDC,增强半同步
跨城:异步复制


 
传统复制线程解析
GTID原理
半同步复制线程解析
并发复制
延迟复制实现
多源复制
MySQL-5.7 在复制线程方面的增强

 


主从数据校验:
pt-table-checksum


GTID:
MySQL 5.6 从非GTID到GTID切换,需要重启
MySQL 5.7 支持在线启用GTID
切换流程:
gtid_modd=
1、主从全部off_permissive。
set global gtid_mode=off_permissive;
2、从库on_permissive,主库on_permissive
set global gtid_mode=on_permissive
3、确认整个group中binlog非GTID的执行完毕
4、主库on,从库on
set global gtid_modd=on;

MySQL 5.7 GTID会存储到表里。
支持slave不用开启binlog(log_slave_updates)
mysql.gtid_executed

如何记录GTID
如果开启binlog,在binlog切换时,将当前的GTID插入到gtid_executed表中。
如果没有开启binlog,每个事务提交前,会执行一个insert

gtid_executed表压缩
控制压缩频率
set global gtid_executed_compression_period=N;(默认1000)

enforce-gtid-consistency
off:不检测是否有GTID不支持的语句/事务
warn:当发现不支持语句/事务,返回警告,并在日志中记录警告信息
on: 当发现语句/事务不支持GTID时,返回错误

TIPS:
在现实从非GTID切换过程中,可以先设置成:warn

GTID Limit:
不能使用 create table tb1 select * from tb2;
可以改成: create table tb1 like tb2; insert into tb1 select * from tb2;
事务中更新非事务表:
begin:update no_trx_tabe set col1 =xxx where xxx; update trx_tb set col1=xxx where ...commit;
事务中创建/删除临时表
begin:update trx_tb set xxx;create temporary table...;commit;
sql_slave_skip_counter 不支持

GTID跳过错误:

stop slave;
SET @@SESSION.GTID_NEXT= ‘01eea86a-5da6-11e8-a709-c03fd5486d6f:282‘;
begin;commit;
set gtid_next="automactic"

 

半同步复制:

在Master收到Slave将事务执行完的ACK应答后才Commit事务(5.6是Master在Commit后,才等待Slave应答)
因此在事务复制到slave前,并发的事务看不到当前的事务的数据
当master故障时,所有已提交的事务都会复制到slave上
默认采用无数据丢失的应答等待机构,用户可以选择使用5.6的应答待机制
set rpl_semi_sync_master_wait_point=after_sync|after_commit

如果响应超时 rpl_semi_sync_master_timeout(超时时间),会自动降级为异步复制
修复会自动升级为半同步


增强半同步:
5.7以后默认:(生产使用增强半同步没问题)
主库写binlog,传输到从库后,从库返回ACK,主库commit;性能更好
set rpl_semi_sync_master_wait_point=AFTER_SYNC;
创建单独的应答接收线程
变成双工默认,发送和接收互不影响

master接收到N个slave应答后,才commit事务
用户可以设置应答的slave数量
set global rpl_semi_sync_master_wait_for_slave_count=2;(有两个slave相应再commit;)

特别提示:
低于5.7的版本,在从库关闭后一段时间后,刚启动时,注意先用异步复制,复制追上后,再用半同步复制
master:
set global rpl_semi_sync_master_enabled=ON|OFF;
slave;
set global rpl_semi_sync_master_enabled=ON|OFF; (确认主库on,之后slave再on)

增强半同步 Master Crash Recovery
1、扫描最后一个Binlog提取其中的Xid
2、扫描innodb维持状态(redo log)在Prepare的事务链表,和binlog中的Xid比较,如果binlog中存在,则提交,否回滚。
提交到innoDB中处于Prepare,并且写Binlog的,就可以从崩溃中恢复事务。


并发复制
MySQL 5.6的并发复制是基于库级别(由于生产都是多实例+单库的架构,所以基本无用)

实质上需要:
让master上能并发执行的事务,在slave上也并发执行
在binlog中记录事务并发执行的相关信息
slave上根据上这些的信息,让这些食物在slave上多个线程中并发执行

MySQL 5.7的并发复制是基于事务级别的(logical Clock)


基于锁的并行复制
并发信息以逻辑时间方式写入的gtid_log_event中,共记录2个逻辑时间:
sequence_number
当事务写入binlog时,事务自己的逻辑时间,按照事务记录binlog的顺序递增
commit_parent
当食物进行prepare阶段时,已经提交的事务的最大逻辑时间
事务在slave执行
commit_parent 之前事务全部提交以后,才开始执行

 

并行复制:
最好配置binlog group commit
binlog_group_commit_sync_delay=20-300 微妙 :时间
binlog_group_commit_sync_no_delay_count=10-30 :事务数

 

延迟复制
让从库和主库保持固定时间的延迟(sql_thread)
使用场景
利用延迟复制做误操作恢复
利用延迟复制做统计分析环境处理
stop slave sql_thread
change master to master_delay=N; #N单位是S

 


多源复制
多个M对应一个S
场景:
集中备份
数据分析聚合
分片数据合并

多个channels(channel包含:recevier thread,relay logs,applier threads)每个channel能独立的运行和停止
通过P_S表进行状态监控:
下列表中添加了channel_name字段,不同的channel的信息在不同的行中显示
replication_applier_status_by_coordinator
replication_applier_status_by_work
replication_connection_status
show slave status\G

 

group replication
实质是:
二进制日志
基于Row格式+GTID
一个通信框架+事务排序控制
增强半同步&并行复制

是一个趋势
备份不好搞定
xtrabackup备份,造成性能损失比较严重
新的节点加入过程对原有集群性能有影响

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


练习:
1、增强半同步复制,半同步复制,异步复制区别
2、测试主从数据校验,pt-table-checksum

 

DAY7-剖析复制线程

标签:包含   显示   操作   cti   金融   用户   tips   ica   cloc   

原文地址:https://www.cnblogs.com/yujiaershao/p/9101805.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!