MySQL中怎么備份分布式邏輯

中怎么備份分布式邏輯，很多新手對此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細講解，有這方面需求的人可以來(lái)學(xué)習下，希望你能有所收獲。

摘要

定期備份的重要性在數據庫生命周期中已得到體現。有不同的風(fēng)格：二進(jìn)制的（Percona XtraBackup），二進(jìn)制日志備份，磁盤(pán)快照（lvm，ebs等）和經(jīng)典的：邏輯備份，可以使用mysqldump，mydumper或mysqlpump等工具進(jìn)行的備份。它們每個(gè)都有特定的用途，MTTR，保留策略等。

定期備份的重要性在數據庫生命周期中已得到體現。有不同的風(fēng)格：二進(jìn)制的（Percona XtraBackup），二進(jìn)制日志備份，磁盤(pán)快照（lvm，ebs等）和經(jīng)典的：邏輯備份，可以使用mysqldump，mydumper或mysqlpump等工具進(jìn)行的備份。它們每個(gè)都有特定的用途，MTTR，保留策略等。

另一個(gè)事實(shí)是，一旦datadir增長(cháng)，進(jìn)行備份可能是一項非常緩慢的任務(wù)：存儲更多數據，讀取和備份更多數據。而且，另一個(gè)事實(shí)是，不僅數據會(huì )增長(cháng)，而且環(huán)境中可用的MySQL實(shí)例的數量也會(huì )增加（通常）。那么，為什么不利用更多的MySQL實(shí)例來(lái)進(jìn)行邏輯備份以使此操作更快呢？

分布式備份（或使用所有可用的從站）

這個(gè)想法很簡(jiǎn)單：不要從單個(gè)上獲取整個(gè)備份，而要使用所有可用的服務(wù)器。本概念證明僅專(zhuān)注于在主/從拓撲上使用副本。也可以使用Master，但是在這種情況下，我決定不使用它，以免增加備份開(kāi)銷(xiāo)。

測試

在主/從屬拓撲中：

來(lái)自Orchestrator GUI的圖形

使用約64GB數據（不包括索引大?。┖?00個(gè)表（模式“ 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個(gè)副本，使用mysqldump進(jìn)行的分布式邏輯備份花費了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: -

單個(gè)副本上的相同備份類(lèi)型花費了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

換一種說(shuō)法：

分布式服務(wù)器快48％！

這是一個(gè)相當小的數據集。值得一試。那么它是怎樣工作的？

概念

邏輯很簡(jiǎn)單，可以分為多個(gè)階段。

階段1：準備

• 找出可用的副本數

• 找出要備份的架構中的表數

• 在所有可用副本之間劃分表的數量。結果塊將是每個(gè)副本將備份的表。

階段2：保證一致性

• 阻止主服務(wù)器執行更改二進(jìn)制日志位置的操作。通常，這是通過(guò)帶有讀取鎖的FLUSH TABLES完成的，但是此PoC使用的是Percona Server for MySQL上的LOCK BINLOG FOR BACKUP的很酷的功能， 并且破壞性較小。

• 查找最新副本

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

• 使用相應的表塊為每個(gè)副本啟動(dòng)一個(gè)mysqldump，并使用–lock-for-backup（Percona Server的另一個(gè)功能）

完整的腳本可以在這里找到：

https://github.com/nethalo/parallel-mysql-backup/blob/master/dist_backup.sh

值得一提的是，腳本具有自己的日志，該日志將描述每個(gè)步驟，它看起來(lái)像這樣：

[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，則很可能已經(jīng)設置了該變量。

在“ report_host”變量中設置的主機應該是可訪(fǎng)問(wèn)的主機。例如，可以實(shí)際解析的IP或主機（，編輯/ etc / hosts文件）。

任何涉及的副本上都沒(méi)有復制過(guò)濾器。這樣可以保證數據的一致性。

該腳本當前應在主服務(wù)器中本地運行。

由于使用了備份鎖，因此只能在Percona Server上使用。

預計MySQL用戶(hù)憑據將在.my.cnf文件內的主目錄中可用。