percona server 8.0主从同步延迟分析

Posted DBA入坑指南

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了percona server 8.0主从同步延迟分析相关的知识,希望对你有一定的参考价值。




一、背景

        

       最近在归档几亿业务数据到我们自建的mysql集群,发现数据库主从同步延迟很大,MySQL版本为percona server 8.0.19,存储引擎为TokuDB,机器为腾讯云CVM,配置为2c 4G,磁盘为1T高性能云盘。


二、原因分析

        

      1、第一时间登录服务器发现,IO wait很高,第一反应就是磁盘IO不足导致的。


percona server 8.0主从同步延迟分析


      2、登录MySQL发现,secondary和primary相差了四百多个binlog,IO thread拉取binlog很慢,slave thread重放完了relay log,一直在等待新的relay log,所以调整了sync_binlog = 0,但是发现情况并没有任何改善。


percona server 8.0主从同步延迟分析

        

       3、用perf分析MySQL进程是哪个函数占用cpu较高,当然DBA也可以使用strace去分析堆栈信息,只是会比较耗时,如图所示


percona server 8.0主从同步延迟分析


 从上面我们可以知道问题大概率出现在flush_master_info这个函数,所以我们去搜索percona server的源码,源码位置为percona-server-8.0.19-10/sql/rpl_slave.cc,代码片段如下

int flush_master_info(Master_info *mi, bool force, bool need_lock, bool do_flush_relay_log) { DBUG_TRACE; DBUG_ASSERT(mi != nullptr && mi->rli != nullptr); DBUG_EXECUTE_IF("fail_to_flush_master_info", { return 1; }); /* With the appropriate recovery process, we will not need to flush the content of the current log.
For now, we flush the relay log BEFORE the master.info file, because if we crash, we will get a duplicate event in the relay log at restart. If we change the order, there might be missing events.
If we don't do this and the slave server dies when the relay log has some parts (its last kilobytes) in memory only, with, say, from master's position 100 to 150 in memory only (not on disk), and with position 150 in master.info, there will be missing information. When the slave restarts, the I/O thread will fetch binlogs from 150, so in the relay log we will have "[0, 100] U [150, infinity[" and nobody will notice it, so the SQL thread will jump from 100 to 150, and replication will silently break. */ mysql_mutex_t *log_lock = mi->rli->relay_log.get_log_lock(); mysql_mutex_t *data_lock = &mi->data_lock;
if (need_lock) { mysql_mutex_lock(log_lock); mysql_mutex_lock(data_lock); } else { mysql_mutex_assert_owner(log_lock); mysql_mutex_assert_owner(&mi->data_lock); }
int err = 0; /* We can skip flushing the relay log when this function is called from queue_event(), as after_write_to_relay_log() will already flush it. */ if (do_flush_relay_log) err |= mi->rli->flush_current_log();
err |= mi->flush_info(force);
if (need_lock) { mysql_mutex_unlock(data_lock); mysql_mutex_unlock(log_lock); }
return err;}

从代码和注解上,我们可以知道主要跟flush mater info和relay log操作有关,消耗过多IO。


     4、调整MySQL参数如下

set global sync_master_info=10000;set global sync_relay_log=10000;set global sync_relay_log_info=10000;

之前上面那三个参数为了安全,在配置文件设置的是1,MySQL 8.0默认参数是10000,修改完毕后重启同步线程stop/start slave,发现IO thread拉取binlog正常了


percona server 8.0主从同步延迟分析


不过同步延迟还是很大,毕竟拖了挺长时间了,show full processlist查看进程信息是没办法使用并行复制的,毕竟归档库没什么并发,就一个归档程序再串行跑,没用好group commit的优势。


percona server 8.0主从同步延迟分析


为了加快后续新数据重放速度,开启writeset复制,不过对于目前的relay log延迟就慢慢地先让sql thread慢慢重放了。


三、总结

        

       之前由于是用于归档的库,对于机器配置要求不高,没有使用SSD云盘,所以突然归档大量数据后,磁盘IO有点吃不消了,上面参数调整主要减轻IO消耗,因为每次都需要调用fdatasync写磁盘,代价还是挺高的。



percona server 8.0主从同步延迟分析


percona server 8.0主从同步延迟分析

扫描二维码获取

更多精彩

DBA入坑指南

percona server 8.0主从同步延迟分析
percona server 8.0主从同步延迟分析







点个在看 你最好看



以上是关于percona server 8.0主从同步延迟分析的主要内容,如果未能解决你的问题,请参考以下文章

pt-heartbeat监测mysql主从同步延迟

MySQL(Percona Server) 5.6 主从复制

mysql主从复制延迟复制半同步

AWS RDS MySQL 主从同步延迟总结

MySQL延迟复制--percona-toolkit和MASTER TO MASTER_DELAY

pt-heartbeat(percona toolkit)