重庆分公司,新征程启航
为企业提供网站建设、域名注册、服务器等服务
MySQL中怎么备份分布式逻辑,很多新手对此不是很清楚,为了帮助大家解决这个难题,下面小编将为大家详细讲解,有这方面需求的人可以来学习下,希望你能有所收获。
10年积累的成都做网站、网站设计经验,可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你,你也不认识我。但先做网站设计后付款的网站建设流程,更有定海免费网站建设让你可以放心的选择与我们合作。
定期备份的重要性在数据库生命周期中已得到体现。有不同的风格:二进制的(Percona XtraBackup),二进制日志备份,磁盘快照(lvm,ebs等)和经典的:逻辑备份,可以使用mysqldump,mydumper或mysqlpump等工具进行的备份。它们每个都有特定的用途,MTTR,保留策略等。
定期备份的重要性在数据库生命周期中已得到体现。有不同的风格:二进制的(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 file Device: 10300h/66304d Inode: 54096034 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Context: unconfined_u:object_r:unlabeled_t:s0 Access: 2020-01-01 14:31:34.948124516 +0000 Modify: 2020-01-01 14:37:41.297640837 +0000 Change: 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.816s user 9m48.871s sys 2m6.492s [root@mysql1 ~]# ls -lh /data/backup.sql -rw-r--r--. 1 root root 56G Jan 1 14:52 /data/backup.sql
换一种说法:
分布式服务器快48%!
这是一个相当小的数据集。值得一试。那么它是怎样工作的?
逻辑很简单,可以分为多个阶段。
找出可用的副本数
找出要备份的架构中的表数
在所有可用副本之间划分表的数量。结果块将是每个副本将备份的表。
阻止主服务器执行更改二进制日志位置的操作。通常,这是通过带有读取锁的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文件内的主目录中可用。
看完上述内容是否对您有帮助呢?如果还想对相关知识有进一步的了解或阅读更多相关文章,请关注创新互联行业资讯频道,感谢您对创新互联的支持。