<span>mysql5.7的并行复制</span>

#####################################

注意:开启并行复制后,如果想要Xtrabackup进行全量备份的话,那就必须还要开启gtid复制而不是传统的位点复制

 

问题描述:

               随着业务的规模越来越大,数据库的读写压力也会越来越大,一般地,mysql的架构为一主多从,实现读写分离,读的压力往往可以通过添加从库实例来解决,然而写压力就只有主库独自承担,主库可以并行写入数据。

               而从库在默认情况下,只能单线程重放主库的binlog,从库通过一个io线程去拉取主库的binlog并写到从库的relay log,然后再通过从库的一个sql线程将relay log重放一次,通常地主库和从库均部署在同一个机房,因此io线程不会是性能瓶颈,sql线程往往才是性能的瓶颈。

               这个时候,主库写数据压力大,这就导致从库的sql线程来不及消化relay log,也就是主库写数据量很大,但是从库重放relay log的速度太慢,这就导致一个严重的问题,主从延迟越来越大,那么从从库读取的数据就很久之前的过期数据了。

 

 

如何解决:在线开启从库的并行复制,同时将开启双0:

                  开启从库的并行复制,

 

1) 开启双0,提高性能,降低安全性,从库实例较多,挂掉一个从库实例没啥影响

mysql> set global sync_binlog=0; 

mysql> set global innodb_flush_log_at_trx_commit=0;

 

2)查看当前并行复制配置:

mysql> show variables like 'slave_parallel_%';

+------------------------+---------------+

| Variable_name          | Value         |

+------------------------+---------------+

| slave_parallel_type    | database |

| slave_parallel_workers | 0             |

+------------------------+---------------+

2 rows in set (0.00 sec)

# slave-parallel-type        默认值为database,但是针对只有一个数据库的集群而言,配置为database就没意义了,建议配置为logical_clock

# slave-parallel-workers      默认值为0,建议至少配置为4

 

 

3)关闭sql线程:

在线开启:

mysql> stop slave sql_thread;

Query OK, 0 rows affected (0.07 sec)


 

4)开启基于组提交的并行复制

mysql> set global slave_parallel_type='LOGICAL_CLOCK';

Query OK, 0 rows affected (0.00 sec)

 

5)配置从库worker线程数,不要配置为0和1,建议至少配置为4

mysql> set global slave_parallel_workers=16;

Query OK, 0 rows affected (0.00 sec)

 

6)开启sql线程:

mysql> start slave sql_thread;

Query OK, 0 rows affected (0.06 sec)

 

7)

root@10.10.10.10 ((none)) > show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Queueing master event to the relay log
                  Master_Host: 10.10.10.11
                  Master_User: mysqlsync
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.037977
          Read_Master_Log_Pos: 766436384
               Relay_Log_File: relay-bin.111125
                Relay_Log_Pos: 766243914
        Relay_Master_Log_File: mysql-bin.037977
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 766243709
              Relay_Log_Space: 766436825
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 113123925
                  Master_UUID: 465c12f1-bbc2-11ea-9fcb-e4434be4b111
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 
                Auto_Position: 0
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
1 row in set (0.04 sec)

Mon Aug 30 10:41:29 2021

 

 

 

优化选项:

启用table模式是因为如果在多线程模式下,会频繁更新master.info文件,消耗代价过高,并且此值也不是非常准确

master_info_repository=table  对应的表为mysql.slave_master_info

relay_log_recovery=on          

relay_log_info_repository=table 对应的表为mysql.slave_relay_log_info

 

 

my.cnf对应的配置如下:

 

# slave
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON
innodb_flush_log_at_trx_commit=0
sync_binlog=0

 

#####################################

全部评论

相关推荐

05-11 11:48
河南大学 Java
程序员牛肉:我是26届的双非。目前有两段实习经历,大三上去的美团,现在来字节了,做的是国际电商的营销业务。希望我的经历对你有用。 1.好好做你的CSDN,最好是直接转微信公众号。因为这本质上是一个很好的展示自己技术热情的证据。我当时也是烂大街项目(网盘+鱼皮的一个项目)+零实习去面试美团,但是当时我的CSDN阅读量超百万,微信公众号阅读量40万。面试的时候面试官就告诉我说觉得我对技术挺有激情的。可以看看我主页的美团面试面经。 因此花点时间好好做这个知识分享,最好是单拉出来搞一个板块。各大公司都极其看中知识落地的能力。 可以看看我的简历对于博客的描述。这个帖子里面有:https://www.nowcoder.com/discuss/745348200596324352?sourceSSR=users 2.实习经历有一些东西删除了,目前看来你的产出其实很少。有些内容其实很扯淡,最好不要保留。有一些点你可能觉得很牛逼,但是面试官眼里是减分的。 你还能负责数据库表的设计?这个公司得垃圾成啥样子,才能让一个实习生介入数据库表的设计,不要写这种东西。 一个公司的财务审批系统应该是很稳定的吧?为什么你去了才有RBAC权限设计?那这个公司之前是怎么处理权限分离的?这些东西看着都有点扯淡了。 还有就是使用Redis实现轻量级的消息队列?那为什么这一块不使用专业的MQ呢?为什么要使用redis,这些一定要清楚, 就目前看来,其实你的这个实习技术还不错。不要太焦虑。就是有一些内容有点虚了。可以考虑从PR中再投一点产出
点赞 评论 收藏
分享
SadnessAlex:跟三十五岁原则一样,人太多给这些***惯坏了
点赞 评论 收藏
分享
不愿透露姓名的神秘牛友
05-29 15:00
教授A:“你为什么要讲这么久,是要压缩我们对你的评议时间吗?你们别以为这样就能够让我们对你们少点意见。”&nbsp;“从你的发言和论文格式就能知道你的性格啊。”…….&nbsp;感觉被狠狠霸凌了。
码农索隆:“教授您好,首先我想回应您提出的两点疑问。” “关于我讲解时间较长的问题:这绝非为了压缩各位老师的评议时间。这份毕业设计是我过去几个月倾注了全部心血的作品,从构思、实验、调试到撰写,每一个环节都反复打磨。我深知时间宝贵,所以选择详细讲解,是希望能更完整、清晰地展示它的核心创新点、实现过程和验证结果,确保老师们能充分理解它的价值和我的努力。我完全理解并重视评审环节的意义,也做好了充分准备来听取各位老师的专业意见和批评。几个月的研究都坚持下来了,我怎么可能害怕老师们的点评呢?今天站在这里,正是抱着虚心学习、诚恳求教的态度而来。” “如果我的展示确实超时,影响了后续流程,烦请老师们随时示意,我会立刻调整。我非常期待并预留了充足的时间,希望能听到老师们宝贵的建议和深入的讨论。” “其次,关于您提到‘从发言和论文格式就能知道我的性格’。教授,我对此感到非常困惑和不安。学术研究和答辩的核心,难道不应该是作品本身的质量、逻辑的严谨性、数据的可靠性和结论的合理性吗?论文格式有明确的规范要求,我尽最大努力遵循了这些规范。如果格式上存在疏忽或不足,这属于技术性、规范性的问题,恳请老师们具体指出,我一定认真修改。但将格式问题或个人表达风格(如讲解时长)直接上升为对个人性格的评判,甚至以此作为质疑我学术态度和动机的依据,这让我感到非常不公平,也偏离了学术评议应有的客观和严谨原则。” “我尊重每一位评审老师的专业权威,也衷心希望能得到老师们对我的工作内容本身的专业指导和批评指正。任何基于研究本身的意见,无论多么尖锐,我都会认真聆听、反思并改进。但我恳请老师们,能将评议的焦点放在我的研究本身,而不是对我个人进行主观的推断或评价。谢谢各位老师。”
点赞 评论 收藏
分享
评论
点赞
收藏
分享

创作者周榜

更多
牛客网
牛客企业服务