MySQL实战 8/32 并行复制

DatabaseBlog 2020-04-19
141

实战1 并行复制搭建

此处假设已经完成标准复制的搭建。

    master :10.67.36.124:3380
    slave:10.67.36.124:3390

    slave 配置

      # MTS
      slave-parallel-type = LOGICAL_CLOCK
      slave-parallel-workers = 4
      master_info_repository = TABLE
      relay_log_info_repository = TABLE
      relay_log_recovery = on
      binlog_transaction_dependency_tracking='WRITESET'

      重启salve mysqld

        mysqladmin -S data/kyle/mysql3390/tmp/mysql3390.sock -uroot -p shutdown
        mysqld --defaults-file=/data/kyle/mysql3390/mysql3390.cnf &

        master

          binlog_group_commit_sync_delay = 100
          binlog_group_commit_sync_no_delay_count = 10
          binlog_transaction_dependency_tracking='WRITESET'

          重启master mysqld

            mysqladmin -S data/kyle/mysql3380/tmp/mysql3380.sock -uroot -p shutdown
            mysqld --defaults-file=/data/kyle/mysql3380/mysql3380.cnf &

            登录到salve

              mysql -S data/kyle/mysql3390/tmp/mysql3390.sock -uadmin -p
              # 重启start salve
              change master to master_host='10.67.36.124', master_port=3380, master_user='repl', master_password='repl4slave', MASTER_AUTO_POSITION=1;
              start slave;
              # 查询复制的线程
              select id, Relay_log_name,Relay_log_pos,Master_log_name,Master_log_pos,Channel_name from slave_worker_info;

              使用sysbench 做压力测试,测试并行复制

                sysbench --mysql-host=10.67.36.124 --mysql-db=db1 --mysql-user=admin --mysql-password=admin123 --mysql-port=3380  --table_size=200000 --tables=10 --threads=10 --events=1000 --report-interval=10 --time=0  usr/local/share/sysbench/oltp_read_write.lua  prepare

                查询时候使用了并行复制

                  select * from slave_worker_info;

                  master 上查看组提交信息

                    mysqlbinlog myql3380_binlog.000002 |grep last_committed

                    相同的last committed 都是组提交的事务。

                    在salve上查询并行复制的信息:

                      mysqlbinlog myql3390_binlog.000004 |grep last_committed

                      相同的 last committed 都是组提交的事务。


                      实战2 为什么会有延时

                      我们再看一下经典的复制原理图

                      1, 若在master 上运行一个delete from t1的语句,要全删除,没有where条件,假如表中有20000条数据, 则会产生20000条binlog, 这样情况,会有延时。

                      2, 在slave上,写入数据的线程只有一个sql thread;而在master 上, 有无数个链接线程在写入数据;所以理论上会有延时;


                      实战3 并行复制原理

                      MySQL5.6 加入了并行复制,但是只是只是数据库级别的并行复制 (即slave-parallel-type=DATABASE), 即一个数据库一个sql thread, 对于现在流行的微服务, 一个MySQL实例,通常一个数据库,所以这种并行复制很鸡肋。

                      MySQL5.7有了基于组提交的并行复制(即slave-parallel-type = LOGICAL_CLOCK),主要原理是一个组内提交的事务,可以并行回放。而这种基于组提交的并行复制,顾名思义就是基于master的组提交。


                      实战4 并行复制关键参数分析

                      1. binlog_group_commit_sync_delay = 100 【主库设置】, 表示延迟多少微秒后才调用 fsync。

                      2. binlog_group_commit_sync_no_delay_count = 2,表示累积多少次以后才调用 fsync。binlog_group_commit_sync_delay  和 binlog_group_commit_sync_no_delay_count 是或的关系, 满足一个条件就提交。

                      3. binlog_transaction_dependency_tracking 【主库设置, 默认commit_order】  取值commit_order | writeset | writeset_session, 主要是控制binlog文件中last_committed的计算方式。

                        1. commit_order即group commit,同在prepare阶段的事务,在binlog中last_committed数值一样,传到从库之后可以并行执行;

                        2. writeset,会对事务处理的行数据哈希出一个writeset值,放到一个哈希表里,如果两个事务先后提交,但是处理的行数据没有冲突,即wirteset不一样,就可以有同样的last_committed,在从库可以并行执行;

                        3. writeset_session,比writeset多了一个约束,同一个session的事务,在binlog里保留先后顺序,也就是last_committed按先后顺序递增

                      4. slave-parallel-type = LOGICAL_CLOCK,

                      5. slave_preserve_commit_order=0,【从库设置,5.7 从库,默认值是0】当该值是1时,严格按照relay log的顺序提交;当该值是0时,从库自行决定提交顺序。

                      6. slave-parallel-workers = 4


                      文章转载自DatabaseBlog,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

                      评论