MySQL复制中重要参数及优化
2022-10-06 本文已影响0人
古飞_数据
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;
