MySQL分布式逻辑备份

摘要

定期备份的重要性在数据库生命周期中已得到体现。有不同的风格：二进制的（Percona XtraBackup），二进制日志备份，磁盘快照（lvm，ebs等）和经典的：逻辑备份，可以使用mysqldump，mydumper或mysqlpump等工具进行的备份。它们每个都有特定的用途，MTTR，保留策略等。

另一个事实是，一旦datadir增长，进行备份可能是一项非常缓慢的任务：存储更多数据，读取和备份更多数据。而且，另一个事实是，不仅数据会增长，而且环境中可用的MySQL实例的数量也会增加（通常）。那么，为什么不利用更多的MySQL实例来进行逻辑备份以使此操作更快呢？

分布式备份（或使用所有可用的从站）

这个想法很简单：不要从单个服务器上获取整个备份，而要使用所有可用的服务器。本概念证明仅专注于在主/从拓扑上使用副本。也可以使用Master，但是在这种情况下，我决定不使用它，以免增加备份开销。

测试

在主/从属拓扑中：

来自Orchestrator GUI的图形

使用约64GB数据（不包括索引大小）和300个表（模式“ sb”）的小datadir：

+--------------+--------+--------+-----------+----------+-----------+----------+| TABLE_SCHEMA | ENGINE | TABLES | ROWS      | DATA (M) | INDEX (M) | TOTAL(M) |+--------------+--------+--------+-----------+----------+-----------+----------+| meta         | InnoDB | 1      |         0 | 0.01     | 0.00      |   0.01   || percona      | InnoDB | 1      |         2 | 0.01     | 0.01      |   0.03   || sb           | InnoDB | 300    | 295924962 | 63906.82 |   4654.68 | 68561.51 || sys          | InnoDB | 1      |         6 | 0.01     | 0.00      |   0.01   |+--------------+--------+--------+-----------+----------+-----------+----------+

使用3个副本，使用mysqldump进行的分布式逻辑备份花费了6分13秒：
[root@mysql1 ~]# ls -lh /data/backups/20200101/total 56G-rw-r--r--. 1 root root 19G Jan  1 14:37 mysql2.sql-rw-r--r--. 1 root root 19G Jan  1 14:37 mysql3.sql-rw-r--r--. 1 root root 19G Jan  1 14:37 mysql4.sql[root@mysql1 ~]# stat /data/backups/20200101/mysql2.sql  File: '/data/backups/20200101/mysql2.sql'  Size: 19989576285     Blocks: 39042144 IO Block: 4096   regular fileDevice: 10300h/66304d   Inode: 54096034 Links: 1Access: (0644/-rw-r--r--)  Uid: ( 0/ root) Gid: (    0/ root)Context: unconfined_u:object_r:unlabeled_t:s0Access: 2020-01-01 14:31:34.948124516 +0000Modify: 2020-01-01 14:37:41.297640837 +0000Change: 2020-01-01 14:37:41.297640837 +0000 Birth: -

单个副本上的相同备份类型花费了11分59秒：
[root@mysql1 ~]# time mysqldump -hmysql2 --single-transaction --lock-for-backup sb > /data/backup.sql
real    11m58.816suser    9m48.871ssys     2m6.492s[root@mysql1 ~]# ls -lh /data/backup.sql-rw-r--r--. 1 root root 56G Jan  1 14:52 /data/backup.sql

换一种说法：
分布式服务器快48％！
这是一个相当小的数据集。值得一试。那么它是怎样工作的？
概念
逻辑很简单，可以分为多个阶段。
阶段1：准备


找出可用的副本数


找出要备份的架构中的表数


在所有可用副本之间划分表的数量。结果块将是每个副本将备份的表。


阶段2：保证一致性


阻止主服务器执行更改二进制日志位置的操作。通常，这是通过带有读取锁的FLUSH TABLES完成的，但是此PoC使用的是Percona Server for MySQL上的LOCK BINLOG FOR BACKUP的很酷的功能， 并且破坏性较小。


查找最新副本


使用START SLAVE UNTIL使所有其他副本与最新副本匹配


使用相应的表块为每个副本启动一个mysqldump，并使用–lock-for-backup（Percona Server的另一个功能）


完整的脚本可以在这里找到：
https://github.com/nethalo/parallel-mysql-backup/blob/master/dist_backup.sh
值得一提的是，脚本具有自己的日志，该日志将描述每个步骤，它看起来像这样：
[200101-16:01:19] [OK] Found 'mysql' bin[200101-16:01:19] [Info] SHOW SLAVE HOSTS executed[200101-16:01:19] [Info] Count tables OK[200101-16:01:19] [Info] table list gathered[200101-16:01:19] [Info] CREATE DATABASE IF NOT EXISTS percona[200101-16:01:19] [Info] CREATE TABLE IF NOT EXISTS percona.metabackups[200101-16:01:19] [Info] TRUNCATE TABLE percona.metabackups[200101-16:01:19] [Info] Executed INSERT INTO percona.metabackups (host,chunkstart) VALUES('mysql3',0)[200101-16:01:19] [Info] Executed INSERT INTO percona.metabackups (host,chunkstart) VALUES('mysql4',100)[200101-16:01:19] [Info] Executed INSERT INTO percona.metabackups (host,chunkstart) VALUES('mysql2',200)[200101-16:01:19] [Info] lock binlog for backup set[200101-16:01:19] [Info] slave status position on mysql3[200101-16:01:19] [Info] slave status file on mysql3[200101-16:01:19] [Info] slave status position on mysql4[200101-16:01:19] [Info] slave status file on mysql4[200101-16:01:19] [Info] slave status position on mysql2[200101-16:01:19] [Info] slave status file on mysql2[200101-16:01:19] [Info] set STOP SLAVE; START SLAVE UNTIL MASTER_LOG_FILE = 'mysql-bin.000358', MASTER_LOG_POS = 895419795 on mysql3[200101-16:01:20] [Info] set STOP SLAVE; START SLAVE UNTIL MASTER_LOG_FILE = 'mysql-bin.000358', MASTER_LOG_POS = 895419795 on mysql4[200101-16:01:20] [Info] set STOP SLAVE; START SLAVE UNTIL MASTER_LOG_FILE = 'mysql-bin.000358', MASTER_LOG_POS = 895419795 on mysql2[200101-16:01:20] [Info] Created /data/backups/20200101/ directory[200101-16:01:20] [Info] Limit chunk OK[200101-16:01:20] [Info] Tables list for mysql3 OK[200101-16:01:20] [OK] Dumping mysql3[200101-16:01:20] [Info] Limit chunk OK[200101-16:01:20] [Info] Tables list for mysql4 OK[200101-16:01:20] [OK] Dumping mysql4[200101-16:01:20] [Info] Limit chunk OK[200101-16:01:20] [Info] Tables list for mysql2 OK[200101-16:01:20] [OK] Dumping mysql2[200101-16:01:20] [Info] UNLOCK BINLOG executed[200101-16:01:20] [Info] set start slave on mysql3[200101-16:01:20] [Info] set start slave on mysql4[200101-16:01:20] [Info] set start slave on mysql2

一些基本要求

由于该工具使用命令SHOW SLAVE HOSTS ，因此必须设置变量report_host，如果使用的是Orchestrator，则很可能已经设置了该变量。
在“ report_host”变量中设置的主机应该是可访问的主机。例如，可以实际解析的IP或主机（DNS，编辑/ etc / hosts文件）。
任何涉及的副本上都没有复制过滤器。这样可以保证数据的一致性。
该脚本当前应在主服务器中本地运行。
由于使用了备份锁，因此只能在Percona Server上使用。
预计MySQL用户凭据将在.my.cnf文件内的主目录中可用
















精彩推荐