mysql在线搭建备库&并行复制&备库延迟

1 读写环境准备

主库模拟压力环境

准备一个干净的主库（开undo表空间回收顺便测下）

sysbench oltp_common --mysql-socket=tmp/mysql.sock --mysql-user=root --mysql-db=server_234_db1 --db-driver=mysql  --tables=4 --table-size=5000000 --report-interval=1 --threads=8 preparesysbench oltp_read_write --mysql-socket=tmp/mysql.sock --mysql-user=root --mysql-db=server_234_db1 --db-driver=mysql  --tables=4 --table-size=5000000 --rand-type=uniform --report-interval=1 --threads=32 --time=12000000 run

安装xtrabackup

wget www.percona.com/downloads/Percona-XtraBackup-2.4/Percona-XtraBackup-2.4.18/binary/redhat/7/x86_64/percona-xtrabackup-24-2.4.18-1.el7.x86_64.rpm
yum install -y percona-xtrabackup-24-2.4.18-1.el7.x86_64.rpm
yum install -y qpress

2 搭建备库

1 主备配置

主库创建备份账号

grant reload,lock tables,replication client,process on *.* to bkman@'%' identified by 'bkman';
grant replication slave,replication client on *.* to repl@'%' identified by 'repl';

备库创建my.cnf不能初始化

cat > /home/mingjie.gmj/databases/data/mydata5471/my.cnf << EOF
[mysqld]
###### general
socket = /home/mingjie.gmj/databases/data/mydata5471/tmp/mysql.sock
log-error = /home/mingjie.gmj/databases/data/mydata5471/mysql/master-error.log
basedir = /home/mingjie.gmj/databases/mysql5471
datadir = /home/mingjie.gmj/databases/data/mydata5471/dbs5471
tmpdir = /home/mingjie.gmj/databases/data/mydata5471/tmp
innodb_buffer_pool_size = 128M
port = 5471
join_buffer_size = 128M
sort_buffer_size = 2M
read_rnd_buffer_size = 2M
innodb_flush_log_at_trx_commit = 1
auto_increment_increment = 1
auto_increment_offset = 1
binlog_group_commit_sync_delay = 100
binlog_group_commit_sync_no_delay_count = 10
###### LOG
log_warnings
slow_query_log_file = /home/mingjie.gmj/databases/data/mydata5471/mysql/slow_query.log
slow_query_log = 1
log_output = TABLE
long_query_time = 1
###### REPLICATION
master-info-file = /home/mingjie.gmj/databases/data/mydata5471/mysql/master.info
master_info_repository = TABLE
relay_log_info_repository = TABLE
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=8
relay_log_recovery=ON
#read_only = ON
###### GTID
server_id = 06700071
gtid_mode = ON
enforce_gtid_consistency = ON
###### BINLOG
log_bin_trust_function_creators = 1
log-bin = /home/mingjie.gmj/databases/data/mydata5471/mysql/mysql-bin.log
log-bin-index = /home/mingjie.gmj/databases/data/mydata5471/mysql/master-log-bin.index
log-slave-updates = 1
binlog_format = ROW
sync_master_info = 10000
sync_binlog = 1
max_binlog_size = 500M
binlog_row_image = full
binlog_checksum = CRC32
binlog_cache_size = 2097152
###### RELAYLOG
relay-log = /home/mingjie.gmj/databases/data/mydata5471/mysql/slave-relay.log
relay-log-info-file = /home/mingjie.gmj/databases/data/mydata5471/mysql/slave-relay-log.info
relay-log-index = /home/mingjie.gmj/databases/data/mydata5471/mysql/slave-relay-log.index
EOF

补充目录

# mkdir -p /home/mingjie.gmj/databases/data/mydata5471/dbs5471
mkdir -p /home/mingjie.gmj/databases/data/mydata5471/mysql
mkdir -p /home/mingjie.gmj/databases/data/mydata5471/tmp

2 开始备份

命令还是用流复制远程的，在本地测一下

mkdir /fdisk1/tmp/xbk_m /fdisk1/tmp/xbk_sxtrabackup --defaults-file=/home/mingjie.gmj/databases/data/mydata5470/my.cnf \-ubkman -pbkman -H127.0.0.1 -P5470 \--backup \--stream=xbstream \--compress \--target-dir=/fdisk1/tmp/xbk_m | ssh mingjie.gmj@127.0.0.1 "xbstream -x -C /fdisk1/tmp/xbk_s"

3 从库恢复

从库上解压并prepare

xtrabackup --decompress --parallel=32 --remove-original --target-dir=/fdisk1/tmp/xbk_s
xtrabackup --prepare --use-memory=4GB --target-dir=/fdisk1/tmp/xbk_s

从库采用move-back方法，把应用好的数据恢复到数据目录

xtrabackup --defaults-file=/home/mingjie.gmj/databases/data/mydata5471/my.cnf \
--move-back --parallel=32 --target-dir=/fdisk1/tmp/xbk_s...
200101 15:09:12 completed OK!

4 从库启动

/bin/sh /home/mingjie.gmj/databases/mysql5471/bin/mysqld_safe --defaults-file=/home/mingjie.gmj/databases/data/mydata5471/my.cnf &

找到从库gtid

cat /home/mingjie.gmj/databases/data/mydata5471/dbs5471/xtrabackup_info | grep binlog_pos
binlog_pos = filename 'mysql-bin.000009',
position '285335334',
GTID of the last change '226e3bb2-2c64-11ea-846b-00163f00f11a:1-87993'

修改从库gtid

reset master;
set global gtid_purged="226e3bb2-2c64-11ea-846b-00163f00f11a:1-87993";show master status\G
*************************** 1. row ***************************File: mysql-bin.000001Position: 154Binlog_Do_DB:Binlog_Ignore_DB:
Executed_Gtid_Set: 226e3bb2-2c64-11ea-846b-00163f00f11a:1-87993

从库启动复制

CHANGE MASTER TOMASTER_HOST='127.0.0.1',MASTER_USER='repl',MASTER_PASSWORD='repl',MASTER_PORT=5470,MASTER_AUTO_POSITION=1;start slave;

参考链接

3 并行复制

3.1 概念

为了兼容 MySQL 5.6 基于库的并行复制，5.7 引入了新的变量 slave-parallel-type，其可以配置的值有：

DATABASE：默认值，基于库的并行复制方式。
LOGICAL_CLOCK：基于组提交的并行复制方式。

如何知道事务是否在一组中，又是一个问题，因为原版的 MySQL 并没有提供这样的信息。在 MySQL 5.7版本中，其设计方式是将组提交的信息存放在 GTID 中。那么如果用户没有开启 GTID 功能，即将参数 gtid_mode 设置为 OFF 呢？故 MySQL 5.7 又引入了称之为 Anonymous_Gtid 的二进制日志 event 类型，如：

mysql> SHOW BINLOG EVENTS in 'mysql-bin.000011';| mysql-bin.000011 | 123 | Previous_gtids | 88 | 194 | f11232f7-ff07-11e4-8fbb-00ff55e152c6:1-2 |
| mysql-bin.000011 | 194 | Anonymous_Gtid | 88 | 259 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' |
| mysql-bin.000011 | 259 | Query | 88 | 330 | BEGIN |
| mysql-bin.000011 | 330 | Table_map | 88 | 373 | table_id: 108 (aaa.t) |
| mysql-bin.000011 | 373 | Write_rows | 88 | 413 | table_id: 108 flags: STMT_END_F |
......

打开gtid

mysql> show binlog events in 'mysql-bin.000012' limit 100;
+------------------+-------+----------------+-----------+-------------+------------------------------------------------------------------------+
| Log_name         | Pos   | Event_type     | Server_id | End_log_pos | Info                                                                   |
+------------------+-------+----------------+-----------+-------------+------------------------------------------------------------------------+
| mysql-bin.000012 |     4 | Format_desc    |   6700070 |         123 | Server ver: 5.7.27-log, Binlog ver: 4                                  |
| mysql-bin.000012 |   123 | Previous_gtids |   6700070 |         194 | 226e3bb2-2c64-11ea-846b-00163f00f11a:1-833142                          |
| mysql-bin.000012 |   194 | Gtid           |   6700070 |         259 | SET @@SESSION.GTID_NEXT= '226e3bb2-2c64-11ea-846b-00163f00f11a:833143' |
| mysql-bin.000012 |   259 | Query          |   6700070 |         341 | BEGIN                                                                  |
| mysql-bin.000012 |   341 | Table_map      |   6700070 |         408 | table_id: 122 (server_234_db1.sbtest2)                                 |
| mysql-bin.000012 |   408 | Update_rows    |   6700070 |         824 | table_id: 122 flags: STMT_END_F                                        |
| mysql-bin.000012 |   824 | Table_map      |   6700070 |         891 | table_id: 122 (server_234_db1.sbtest2)                                 |
| mysql-bin.000012 |   891 | Update_rows    |   6700070 |        1307 | table_id: 122 flags: STMT_END_F                                        |
| mysql-bin.000012 |  1307 | Table_map      |   6700070 |        1374 | table_id: 121 (server_234_db1.sbtest3)                                 |
| mysql-bin.000012 |  1374 | Delete_rows    |   6700070 |        1599 | table_id: 121 flags: STMT_END_F                                        |
| mysql-bin.000012 |  1599 | Table_map      |   6700070 |        1666 | table_id: 121 (server_234_db1.sbtest3)                                 |
| mysql-bin.000012 |  1666 | Write_rows     |   6700070 |        1891 | table_id: 121 flags: STMT_END_F                                        |
| mysql-bin.000012 |  1891 | Xid            |   6700070 |        1922 | COMMIT /* xid=16521822 */                                              |
| mysql-bin.000012 |  1922 | Gtid           |   6700070 |        1987 | SET @@SESSION.GTID_NEXT= '226e3bb2-2c64-11ea-846b-00163f00f11a:833144' |
| mysql-bin.000012 |  1987 | Query          |   6700070 |        2069 | BEGIN                                                                  |
| mysql-bin.000012 |  2069 | Table_map      |   6700070 |        2136 | table_id: 124 (server_234_db1.sbtest4)                                 |
| mysql-bin.000012 |  2136 | Update_rows    |   6700070 |        2552 | table_id: 124 flags: STMT_END_F                                        |
| mysql-bin.000012 |  2552 | Table_map      |   6700070 |        2619 | table_id: 124 (server_234_db1.sbtest4)                                 |
| mysql-bin.000012 |  2619 | Update_rows    |   6700070 |        3035 | table_id: 124 flags: STMT_END_F                                        |
| mysql-bin.000012 |  3035 | Table_map      |   6700070 |        3102 | table_id: 123 (server_234_db1.sbtest1)                                 |
| mysql-bin.000012 |  3102 | Delete_rows    |   6700070 |        3327 | table_id: 123 flags: STMT_END_F                                        |
| mysql-bin.000012 |  3327 | Table_map      |   6700070 |        3394 | table_id: 123 (server_234_db1.sbtest1)                                 |
| mysql-bin.000012 |  3394 | Write_rows     |   6700070 |        3619 | table_id: 123 flags: STMT_END_F                                        |
| mysql-bin.000012 |  3619 | Xid            |   6700070 |        3650 | COMMIT /* xid=16521553 */
+------------------+-------+----------------+-----------+-------------+------------------------------------------------------------------------+

组提交是个比较好玩的方式，我们根据 MySQL 的 binlog 可以发现较之原来的二进制日志内容多了 last_committed 和 sequence_number 。

mysqlbinlog mysql-bin.000012 |grep last_committed

我们可以看到倒数第三个事务的 last_committed 是相同的，这意味着这两个事务是作为一个组提交的，两个事务在 Perpare 阶段获取相同的 last_committed 而且相互不影响，最终是会作为一个组进行提交。这就是所谓的组提交。组提交的事务是可以在从机进行并行回放的。

上述的 last_committed 和 sequence_number 代表的就是所谓的 LOGICAL_CLOCK 。

3.2 参数

---------->主库<----------

show global variables like '%group_commit%';
+-----------------------------------------+-------+
| Variable_name                           | Value |
+-----------------------------------------+-------+
| binlog_group_commit_sync_delay          | 0     |
| binlog_group_commit_sync_no_delay_count | 0     |
+-----------------------------------------+-------+

要开启 MySQL 5.7 并行复制需要以下二步，首先在主库设置 binlog_group_commit_sync_delay 的值大于0 。

set global binlog_group_commit_sync_delay=10;

这里简要说明下 binlog_group_commit_sync_delay 和 binlog_group_commit_sync_no_delay_count 参数的作用。

binlog_group_commit_sync_delay

全局动态变量，单位微妙，默认0，范围：0～1000000（1秒）。

表示 binlog 提交后等待延迟多少时间再同步到磁盘，默认0 ，不延迟。当设置为 0 以上的时候，就允许多个事务的日志同时一起提交，也就是我们说的组提交。组提交是并行复制的基础，我们设置这个值的大于 0 就代表打开了组提交的功能。

binlog_group_commit_sync_no_delay_count

全局动态变量，单位个数，默认0，范围：0～1000000。

表示等待延迟提交的最大事务数，如果上面参数的时间没到，但事务数到了，则直接同步到磁盘。若 binlog_group_commit_sync_delay 没有开启，则该参数也不会开启。

---------->备库<----------

# 过多的线程会增加线程间同步的开销，建议4-8个Slave线程。slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=4

备库状态

mysql> show processlist;
+------+---------+------+---------------------------------------------+
| db   | Command | Time | State                                       |
+------+---------+------+---------------------------------------------+
| NULL | Connect | 1789 | Waiting for master to send event            |
| NULL | Connect |    0 | Waiting for dependent transaction to commit |
| NULL | Connect |  917 | System lock                                 |
| NULL | Connect |  917 | System lock                                 |
| NULL | Connect |  917 | System lock                                 |
| NULL | Connect |  917 | Waiting for an event from Coordinator       |
| NULL | Connect |  917 | Waiting for an event from Coordinator       |
| NULL | Connect |  917 | Waiting for an event from Coordinator       |
| NULL | Connect |  917 | Waiting for an event from Coordinator       |
| NULL | Connect |  917 | System lock                                 |
| NULL | Query   |    0 | starting                                    |
+------+---------+------+---------------------------------------------+

3.3 并行复制配置与调优

开启 MTS 功能后，务必将参数 master-info-repository 设置为 TABLE ，这样性能可以有 50%~80% 的提升。这是因为并行复制开启后对于 master.info 这个文件的更新将会大幅提升，资源的竞争也会变大。

在 MySQL 5.7 中，推荐将 master-info-repository 和 relay-log-info-repository 设置为 TABLE ，来减小这部分的开销。

master-info-repository = table
relay-log-info-repository = table
relay-log-recovery = ON

3.4 并行复制监控

复制的监控依旧可以通过 SHOW SLAVE STATUS\G，但是 MySQL 5.7 在 performance_schema 架构下多了以下这些元数据表，用户可以更细力度的进行监控：

mysql> use performance_schema;
mysql> show tables like 'replication%';
+---------------------------------------------+
| Tables_in_performance_schema (replication%) |
+---------------------------------------------+
| replication_applier_configuration           |
| replication_applier_status                  |
| replication_applier_status_by_coordinator   |
| replication_applier_status_by_worker        |
| replication_connection_configuration        |
| replication_connection_status               |
| replication_group_member_stats              |
| replication_group_members                   |
+---------------------------------------------+

4 备库延迟

主库4并发模拟压力

sysbench oltp_read_write --mysql-socket=tmp/mysql.sock --mysql-user=root --mysql-db=server_234_db1 --db-driver=mysql  --tables=4 --table-size=5000000 --rand-type=uniform --report-interval=1 --threads=4 --time=12000000 run

延迟场景：

optimize重建表：一开始不会影响，新表重建完了opti会在主库上一段时间上加meta锁，那段时间主库写会阻塞。备库拿到opti后会重新做一遍，并发复制也会延迟！
加索引：主库需要计算，用文件排序等等，备库会重做一遍并延迟
删索引：主库、备库都会很快完成

Xtrabackup在线搭建备库与并行复制延迟相关推荐

PostgreSQL学习篇16.3 检查备库及流复制情况
检查异步流复制情况: 主库查询: select pid,state,client_addr,sync_priority,sync_state from pg_stat_replication;post ...
mysql开启gtid dump_MySQL5.7搭建备库开启gtid使用mysqldump
1.主库mysqldump mysqldump --all-databases --default-character-set=utf8 -R -q --triggers --master-data= ...
MariaDB 10之并行复制--延迟测试结果
测试参数: sysbench --test=/root/sysbench0.5/sysbench/tests/db/insert.lua --mysql-table-engine=innodb --o ...
mysql在线搭建从库_Mysql主从库搭建
基于Docker的Mysql主从复制搭建首先安装docker 拉取mysql镜像:5.7版本启动主从数据库容器 docker run -p 3339:3306 --name Maste -e MY ...
MySQL备库复制延迟的原因及解决办法
背景今天有同事问我主从复制延迟会影响高可用切换的 RTO 怎么办,这个不需要做实验,我可以直接回答,所以有了以下赶鸭子的文章,都是一线运维经验之谈,建议四连:点赞.收藏.转发.在看. 复制延迟的原因 ...
mysql 并行复制搭建_基于GTID的主从实践系列之④并行复制搭建及测试
并行复制最早在5.6就搞出来了,是一个库级别的并行复制(slave_parallel_type可以有两个值:DATABASE 默认值,基于库的并行复制方式:LOGICAL_CLOCK:基于组提交的并行 ...
mysql多线程复制crash_MySQL 并行复制(MTS) 从库发生异常crash分析
背景半同步复制从库在晚上凌晨2点半发生异常crash,另一个异步复制从库在第二天凌晨3点也发生了异常crash. 版本 mysql 5.7.16 redhat 6.8 mysql> show ...
mysql从库并行,MySQL 并行复制从库发生自动重启分析
并行复制从库发生自动重启分析背景半同步复制从库在晚上凌晨2点半发生自动重启,另一个异步复制从库在第二天凌晨3点也发生了自动重启. 分析版本mysql 5.7.16 mysql> show ...
Innobackupex实现mysql在线搭建master-slave主从复制
oracle.mysql.sqlserver这种使用物理备份做master-slave主从的,原理都是一样,主库不需要停机,主库在线做好物理备份后,恢复物理备份到从库,从库以主库物理备份开始的这个时刻 ...

Xtrabackup在线搭建备库与并行复制延迟