1.从库Crash后为什么复制会中断，如何避免?
2.有哪些办法可以减少复制延迟?
3.如果让MySQL复制，只复制部分表?
4.如何将多个数据源汇总在一个从库实例上?

1.从库Crash后为什么复制会中断，如何避免?

1．从库异常down机后，启动start slave;复制不能进行。
2．如何处理?实质原因: mysql relay log损坏

GTID环境解决

stop slave;
reset slave;          -- 清空relay log
start slave;

mysqldump -A --single-transaction --master-data=2 -S /tmp/mysql3306.sock -p > db3306.sql
more db3306.sql
启动一个实例 
/usr/local/mysql/bin/mysqld --defaults-file=/data/mysql/mysql3308/my3308.cnf &
如果有数据需要清空数据
drop database xxx;
reset master;  --清空binlog
reset slave all;
show master status;
恢复数据
mysql -S /tmp/mysql3308.sock < /data/backup/db3306.sql
show master status;  --查看同步的gtid
change master to master_host='127.0.0.1' master_port='3306' master_user='repl', master_password='repl4slave',master_auto_position=1;
start slave;


主库
create table tb1(
id int(11) NOT NULL,
c1 varchar(64) DEFAULT NULL,
PRIMARY KEY (id)
)ENGINE=InnoDB DEFAULT CHARSET=utf8
insert into tb1(id,c1) values(22,'abcd');
show master status;

小插曲,配置问价加载不生效,分析

为了区分显示,加了端口
[mysql]
auto-rehash
prompt="\\u@\\h:\p [\\d]>"


分析加载情况
strace -S /tmp/mysql3308.sock -p | grep my.cnf
mv my.cnf my.cnf_bak_`date +%Y%m%d`

position环境

stop slave;
change master to 
master_log_file = relay_master_log_file
master_log_pos = exec_log_position
start slave io_thread;


show slave status\G    记录信息
Relay_Master_Log_File: mysql-bin.000021
Exec_Master_Log_Pos: 3441

复制自动recovery,主从都配置
       relay_log_info_repository = table
       relya _log_recovery=1
       relay_log_purge=1

start slave until SQL_after_MTS_GAPS;    需要上述三个参数才行

需要注意的是mha环境  relay_log_purge=0    就不能使用上面的功能了

2.有哪些办法可以减少复制延迟?

并行复制
slave_parallel_type=LOGICAL_CLOCK
slave_parallel_workers=4-8
为什么开了这两个参数，实质上并没有启用并行复制?

怎么看并行复制是生效的呢?
select * from ps_replication_applier_status_by_worker\G;
show global variables like '%slave%';

并行复制需要开启的参数
Master:
Binlog group commit:
binlog_group_commit_sync_delay
binlog_group_commit_sync_no_delay_count


Slave并行复制:
slave_parallel_type=LOGICAL_CLOCK              以来上面的binlog group commit
slave_parallel_workers=4-8
binlog_transaction_dependency_tracking=writeset
slave-preserve-commit-order=0

如果slave-preserve-commit-order 配置为1  writeset就不工作了

什么是binlog group commit?
Binlog Group Commit的过程
flush Stage
Sync Stage
Commit Stage

commied=No,seqxxxed=No     其中 seqxxxed=No 一样就是一组


binlog_group_commit_sync_delay                   配置100微妙
binlog_group_commit_sync_no_delay_count   队列大小  配置在20-30

slave_parallel_type=LOGICAL_CLOCK
slave_parallel_workers=4-8

8.0的writeSet
binlog group commit是5.7引入，为了提高从库的应用速度，在主库上尽量提高并行
8.0做的设计是针对从库，即使主库在串行提交的事务，只要不互相冲突，在Slave上也可以并行回放:WriteSet

binlog_transaction_dependency_tracking=commit_order/writesetlwriteset_session
transaction_write_set_extraction (hash方法) xxhash64
binlog_transaction_dependency_history_size (hash大小) 默认25000

如果slave-preserve-commit-order 配置为1  writeset就不工作了


groupcommit和write set 同时设置会不会冲突?
优先使用write set


 binlog中引入: last_commited和sequence_number
sequence_number 是自身事务ID
last_commited是上一个提交事务的ID
·如果两事务的last_commited相同，说明两个事务是在同一个Group内提交

pke函数
基于Slave上的并行复制优化
依赖于日志中commit timestamps或是writesets并行回放事务需要使用到函数
rpl_write_set_handler.cc:add_pke()     ( binlog_write_row中调用)
非唯一索引名称+分隔符+库名+分隔符+库名长度+表名+分隔符+表名长度+索引字段1数值+分隔符+索引字段1长度[+索引字2段数值+分隔符+索引字段2长度...]


每个表都有一个唯一的key
hash,isapply?

update tb1 set c1=10 where id=10;
主键hash一个值  id:10zst:3tb1:3 --> 0
update tb1 set c1=11 where id=11;  发现主键值一样,不能并行,不放在队列中
update tb1 set c1=11 where id=11;  又形成一个hash, id:11zst:3tb1::3 -->0

binlog_transaction_dependency_history_size=25000   池子的概念, 在队列里取任务,然后按照slave_parallel_workers=4取值并发

并发完后 id:10zst:3tb1:3 --> 1    id:11zst:3tb1::3 --> 1  标记为1  60秒会清理一次

如果并发出错了,就停止了

Master中的配置writeset
binlog_transaction_dependency_tracking

select * from sys.memory_global_total;
select * from sys.memory_global_by_current_bytes;

总结:

#relay log recovery
 relay_log_info_repository = table
 relya _log_recovery=1
 relay_log_purge=1

#binlog group commit
binlog_group_commit_sync_delay=100
binlog_group_commit_sync_no_delay_count=20

#replication parallel
slave_parallel_type=LOGICAL_CLOCK
slave_parallel_workers=8
binlog_transaction_dependency_tracking=writeset
slave-preserve-commit-order=0

复制中重要功能启用

sync_relay_log_info = 1

show slave status\G   从哪里读取的数据


这是一个性能杀手的配置
sync_relay_log_info=1 & relay_log_info_repository=file
正确的姿势
sync_relay_log_info=1 & relay_log_info_repository=table
sync_master_info = 1
#如果使用了crash-safe replication这个参数建议配置大点，提升性能。

复制延迟功能

#启用延迟复制,保持和主库一个小时库

的延迟
mysq>stop slave sql_thread;
mysq>change master to \
master_delay=3600;
mysq>start slave sql_thread;



#禁用延迟复制
mysqI>stop slave sql_thread;
mysql>change master to \
master_delay= 0;
mysql>start slave sql_thread;

change master to master_delay=0;
start slave sql_thread until SQL_BEFORE_GTIDS=uuid:N;        重放到删库前的uuid


如果数据库很大 都有好几T了, 可以用延时从库做灾备    12小时延迟

3.如果让MySQL复制，只复制部分表?

binlog_do_db不要在主库上配置
stop slave sql_thread;
change replication filter replicate_do_db=(tencent);
start slave sql_thread;

DDL binlog   都是 statement

statement  格式 不能跨库操作,
跨库DDL操作可能遇到不能复制的情况

4.如何将多个数据源汇总在一个从库实例上?

多源复制
change master to \
...
for channel 'channelname'

启用多源复制的限制
master_info_repository=table
relay_log_info_repository=table
+GTID
从管理方便上讲:
binlog_format=row
gtid_mode=on

change master to .... for channel db3306;
change master to ... for channel db3307;



show slave status\G
show master status;   获取gitd
reset master;                  
show master status;
导入数据
mysql < ./db3307.sql
show master status;  获取gtid
set global gtid_purged='uuid1:1-N;uuid2:1-N'
show master status;

change master to mast_host=uuid2 ... for channel db3307;

start slave for channel db3307;
start slave for channel db3306;