組複製常規操作-使用xtrabackup備份恢復或添加組成員 | 全方位認識MySQL8.0 Group Replication

2021-02-14 老葉茶館

4.6. 在組複製中使用備份數據恢復失敗的成員或增加新成員由於官方手冊中使用了企業版的mysqlbackup做演示步驟，以下本節內容採用開源的percona-xtrabackup 8.0.7版本演示對組成員數據的備份和恢復過程，如果有企業版的mysqlbackup需求，詳情可參考連結：https://dev.mysql.com/doc/refman/8.0/en/group-replication-enterprise-backup.html備份組複製成員數據。備份組複製成員的數據類似於備份一個MySQL單實例。下面的演示步驟假設你已經了解了如何使用percona-xtrabackup 8.0.7版本，否則，請自行參考在線手冊：https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html設置組中已經有3個組成員(node1、node2和node3)，通過組中任意成員的performance_schema.replication_group_members表可以查詢到組中的成員資格與狀態信息，如下：

root@localhost : (none):45: > SELECT * FROM performance_schema.replication_group_members;
+--+---+---+---+----+---+-+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+--+---+---+---+----+---+-+
| group_replication_applier | 2d283e92-de7b-11e9-a14d-525400c33752 | node2 | 3306 | ONLINE | SECONDARY | 8.0.17 |
| group_replication_applier | 2e33b2a7-de7b-11e9-9a21-525400bdd1f2 | node3 | 3306 | ONLINE | SECONDARY | 8.0.17 |
| group_replication_applier | 320675e6-de7b-11e9-b3a9-5254002a54f2 | node1 | 3306 | ONLINE | PRIMARY | 8.0.17 |
+--+---+---+---+----+---+-+
3 rows in set (0.00 sec)

使用percona-xtrabackup工具執行備份（假設這裡在node3節點上執行備份，注意，除非必須，否則不要在主要節點上執行備份--這裡主要節點為node1）。

# 在node3中執行備份命令
[root@node3 ~]# xtrabackup --defaults-file=/etc/my.cnf --user=admin --password='letsg0' --backup --target-dir=/data//backup/
.
191012 17:19:37 Backup created in directory '/data/backup/'
MySQL binlog position: filename 'mysql-bin.000023', position '231', GTID of the last change '320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-2771494'
191012 17:19:37 [00] Writing /data/backup/backup-my.cnf
191012 17:19:37 [00] ...done
191012 17:19:37 [00] Writing /data/backup/xtrabackup_info
191012 17:19:37 [00] ...done
xtrabackup: Transaction log of lsn (11495841139) to (11495843979) was copied.
191012 17:19:37 completed OK!
# 備份完成之後查看備份數據目錄中的數據文件
[root@node3 ~]# ll /data//backup/
total 2147376
-rw-r 1 root root 515 Oct 12 17:19 backup-my.cnf
-rw-r 1 root root 2147483648 Oct 12 17:19 ibdata1
drwxr-x--- 2 root root 143 Oct 12 17:19 mysql
-rw-r 1 root root 231 Oct 12 17:19 mysql-bin.000023
-rw-r 1 root root 52 Oct 12 17:19 mysql-bin.index
-rw-r 1 root root 24117248 Oct 12 17:19 mysql.ibd
drwxr-x--- 2 root root 8192 Oct 12 17:19 performance_schema
drwxr-x--- 2 root root 44 Oct 12 17:19 sbtest
drwxr-x--- 2 root root 28 Oct 12 17:19 sys
drwxr-x--- 2 root root 20 Oct 12 17:19 test
-rw-r 1 root root 13631488 Oct 12 17:19 undo_001
-rw-r 1 root root 13631488 Oct 12 17:19 undo_002
-rw-r 1 root root 109 Oct 12 17:19 xtrabackup_binlog_info
-rw-r 1 root root 101 Oct 12 17:19 xtrabackup_checkpoints
-rw-r 1 root root 622 Oct 12 17:19 xtrabackup_info
-rw-r 1 root root 5632 Oct 12 17:19 xtrabackup_logfile
-rw-r 1 root root 262 Oct 12 17:19 xtrabackup_tablespaces

將備份數據傳輸到新的等待加入組的Server node4的主機中（對於node4的資料庫Server初始化安裝，請參考"2.1.2.1. 組複製實例配置的基本要求")。

# 在這個例子中，我們假設主機都是Linux伺服器，並使用SCP在它們之間複製文件
## 在node4中創建用於存放備份數據的目錄
[root@node4 ~]# mkdir /data/backup/xtrabackup_dir
## 在node3中將備份數據使用SCP傳送到node4中
[root@node3 ~]# scp -r /data//backup/ 10.10.30.16:/data/backup/xtrabackup_dir

接下來，我們需要使用備份數據恢復目標實例（這裡我們是在node4主機上執行恢復操作），先停止目標伺服器的資料庫進程，如下：

# 首先停止目標伺服器的資料庫進程
[root@physical-machine ~]# service mysqld stop
Shutting down MySQL SUCCESS!
[root@physical-machine ~]# ps aux |grep mysqld |grep -v grep
[root@physical-machine ~]#
# 注意：如果是用備份數據來恢復發生故障的成員，且故障成員的主機未宕機，則建議將故障成員的datadir下的auto.cnf和mysqld-auto.cnf文件先拷貝出來，稍後使用備份數據恢復完成之後，再拷貝回原目錄（auto.cnf中記錄著源實例的UUID，使用該UUID來對實例進行恢復時，可確保故障實例可以以原來的身份重新加入組，而不是重新生成一個UUID以新的身份加入組；mysqld-auto.cnf記錄了Server本地的一些系統變量的臨時持久化設置），拷貝命令類似如下
[root@node2 ~]# cp -ar /data//mysqldata1/mydata/{auto.cnf,mysqld-auto.cnf} /data/backup/
[root@node2 ~]# ll /data//backup/*.cnf
-rw-r 1 mysql mysql 56 Sep 24 11:27 /data//backup/auto.cnf
-rw-r 1 mysql mysql 414 Sep 25 17:12 /data//backup/mysqld-auto.cnf

清空目標主機中的數據目錄（node4），如下：

# 必須清空共享表空間(innodb_data_home_dir)、獨立表空間(datadir)、獨立undo表空間(innodb_undo_directory)、redo log日誌(innodb_log_group_home_dir)數據文件所在的目錄，否則後續恢復將無法拷貝文件（如果可以，中繼日誌、二進位日誌所在的目錄也一併清空），類似如下
[root@node4 ~]# rm -rf /data/mysqldata1/{binlog,innodb_log,innodb_ts,mydata,relaylog,undo}/*

對備份數據執行redo log恢復（應用在執行備份過程中生成的redo日誌，這些redo 日誌是xtrabackup工具自己拷貝的且是存放在xtrabackup_logfile文件中的，而不是存放在InnoDB存儲引擎層自己的redo log文件裡，另外，xtrabackup備份工具執行備份時，也不會備份存儲引擎層的redo log文件，需要執行該步驟來生成全新的redo log文件）。

# 執行恢復語句
[root@node4 ~]# xtrabackup --prepare --target-dir=/data/backup/xtrabackup_dir/backup/
.
FTS optimize thread exiting.
Starting shutdown...
Log background threads are being closed...
Shutdown completed; log sequence number 11495844364
191014 15:32:39 completed OK!
# 執行完成恢復之後，查看備份數據文件所在目錄，可以發現多了一些文件和目錄
[root@physical-machine ~]# ll /data/backup/xtrabackup_dir/backup/
total 6362156
-rw-r 1 root root 515 Oct 12 18:01 backup-my.cnf
-rw-r 1 root root 2147483648 Oct 14 15:32 ibdata1
-rw-r 1 root root 2147483648 Oct 14 15:32 ib_logfile0  # 發現多了ib_logfile0和ib_logfile1文件
-rw-r 1 root root 2147483648 Oct 14 15:32 ib_logfile1
-rw-r 1 root root 12582912 Oct 14 15:32 ibtmp1 # 多了ibtmp1文件
drwxr-x--- 2 root root 6 Oct 14 15:32 #innodb_temp # 多了一個目錄
drwxr-x--- 2 root root 143 Oct 12 18:01 mysql
-rw-r 1 root root 231 Oct 12 18:01 mysql-bin.000023
-rw-r 1 root root 52 Oct 12 18:01 mysql-bin.index
-rw-r 1 root root 24117248 Oct 14 15:32 mysql.ibd
drwxr-x--- 2 root root 8192 Oct 12 18:01 performance_schema
drwxr-x--- 2 root root 44 Oct 12 18:00 sbtest
drwxr-x--- 2 root root 28 Oct 12 18:00 sys
drwxr-x--- 2 root root 20 Oct 12 18:00 test
-rw-r 1 root root 13631488 Oct 14 15:32 undo_001
-rw-r 1 root root 13631488 Oct 14 15:32 undo_002
-rw-r 1 root root 109 Oct 12 18:01 xtrabackup_binlog_info
-rw-r 1 root root 101 Oct 14 15:32 xtrabackup_checkpoints
-rw-r 1 root root 622 Oct 12 18:01 xtrabackup_info
-rw-r 1 root root 8388608 Oct 14 15:32 xtrabackup_logfile
-rw-r--r-- 1 root root 1 Oct 14 15:32 xtrabackup_master_key_id  # 多了xtrabackup_master_key_id文件
-rw-r 1 root root 262 Oct 14 15:32 xtrabackup_tablespaces

將恢復完成的備份數據文件拷貝（或移動）到目標資料庫Server的數據目錄下。

[root@physical-machine ~]# xtrabackup --defaults-file=/etc/my.cnf --copy-back --target-dir=/data/backup/xtrabackup_dir/backup/
.
191014 16:26:10 [01] Creating directory ./#innodb_temp
191014 16:26:10 [01] ...done.
191014 16:26:10 completed OK!

修改目標資料庫的數據目錄權限，並配置好my.cnf。

# 修改目錄權限
[root@node4 backup]# chown mysql.mysql /data/mysqldata1/ -R
# 在my.cnf中配置好組複製的系統變量（如果是恢復故障Server而不是新增Server，這些配置都在，無需重複配置）
[root@node4 backup]# cat /etc/my.cnf
.
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
binlog_checksum=NONE
plugin_load_add='group_replication.so'
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_start_on_boot=off
group_replication_local_address= "10.10.30.16:33061"
group_replication_group_seeds= "10.10.30.162:33061,10.10.30.163:33061,10.10.30.164:33061"
group_replication_bootstrap_group=off
report_host=node4
# 配置好hosts解析記錄，或者將report_host指定為IP位址也可以不用配置解析記錄（將node4的解析記錄同時配置到其他組成員的/etc/hosts文件中）（如果是恢復故障Server而不是新增Server，這些配置都在，無需重複配置）
[root@physical-machine ~]# cat /etc/hosts
.
10.10.30.16 node4
10.10.30.162 node1
10.10.30.163 node2
10.10.30.164 node3

如果有需要，且允許，請將auto.cnf與mysqld-auto.cnf文件拷貝到目標資料庫Server的datadir目錄下（故障Server恢復才需要此步驟，新加入組的Server不需要此步驟）。

# 操作命令類似如下
[root@node2 ~]# cp -ar /data/backup/{auto.cnf,mysqld-auto.cnf} /data/mysqldata1/mydata/

啟動目標資料庫Server進程（node4）。

[root@physical-machine backup]# service mysqld start
Starting MySQL.... SUCCESS!
[root@node4 backup]# ps aux |grep mysqld |grep -v grep
root 27818 0.7 0.0 11760 1640 pts/3 S 17:23 0:00 /bin/sh /usr/local/mysql/bin/mysqld_safe --datadir=/home/mysql/data/mysqldata1/mydata --pid-file=/home/mysql/data/mysqldata1/sock/mysql.pid
mysql 29388 102 3.4 107051036 8436648 pts/3 Sl 17:23 0:16 /usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql --datadir=/home/mysql/data/mysqldata1/mydata --plugin-dir=/usr/local/mysql/lib/plugin --user=mysql --log-error=/home/mysql/data/mysqldata1/log/error.log --open-files-limit=65535 --pid-file=/home/mysql/data/mysqldata1/sock/mysql.pid --socket=/home/mysql/data/mysqldata1/sock/mysql.sock --port=3306

查看備份目錄下的xtrabackup_binlog_info文件中的GTID信息。

[root@physical-machine ~]# cd /data/backup/xtrabackup_dir/backup/
# 記錄下320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-2771494字符串，稍後登錄資料庫中需要使用
[root@physical-machine backup]# cat xtrabackup_binlog_info
mysql-bin.000023 231 320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-2771494

登錄到node4的資料庫Server中，重設GTID SET信息，如下：

# 先查看一下當前的GTID SET信息，如果與xtrabackup_binlog_info文件中記錄的一致，就不需要後續步驟了（在一個在線的組中，這裡GTID經常會不一致，這裡我們的示例中GTID SET碰巧一致是因為在執行備份期間，組並沒有新的請求進入）
admin@localhost : (none):37: > show master status;
+---++----+---++
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---++----+---++
| mysql-bin.000024 | 231 | | | 320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-2771494 |
+---++----+---++
1 row in set (0.00 sec)
# 如果發現GTID SET信息與xtrabackup_binlog_info文件中記錄的不一樣，則需要執行後續步驟，重設GTID SET為xtrabackup_binlog_info文件中記錄的GTID SET
admin@localhost : (none):37: > reset master;
Query OK, 0 rows affected (0.01 sec)
admin@localhost : (none):38: > set global gtid_purged='320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-2771494';
Query OK, 0 rows affected (0.00 sec)
admin@localhost : (none):38: > show master status;
+---++----+---++
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---++----+---++
| mysql-bin.000001 | 151 | | | 320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-2771494 |
+---++----+---++
1 row in set (0.00 sec)

登錄到node4的資料庫Server中，啟動組複製。

# 使用如下語句使node4加入組
admin@localhost : (none):38: > START GROUP_REPLICATION;
Query OK, 0 rows affected (3.77 sec)
# 稍後查看成員狀態信息，可以看到node4節點已經處於ONLINE狀態了（如果在node4操作過程中，組持續不斷有新的事務寫入，那麼，在其申請加入組的過程中，會有一部分事務需要追趕，所以node4可能有一段時間處於RECOVERING狀態，等待追趕事務完成之後，才會變更ONLINE狀態）
admin@localhost : (none):02: > select * from performance_schema.replication_group_members;
+--+---+---+---+----+---+-+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+--+---+---+---+----+---+-+
| group_replication_applier | 2d283e92-de7b-11e9-a14d-525400c33752 | node2 | 3306 | ONLINE | SECONDARY | 8.0.17 |
| group_replication_applier | 2e33b2a7-de7b-11e9-9a21-525400bdd1f2 | node3 | 3306 | ONLINE | SECONDARY | 8.0.17 |
| group_replication_applier | 320675e6-de7b-11e9-b3a9-5254002a54f2 | node1 | 3306 | ONLINE | PRIMARY | 8.0.17 |
| group_replication_applier | 54b857f4-ee64-11e9-ada9-0025905b06da | node4 | 3306 | ONLINE | SECONDARY | 8.0.17 |
+--+---+---+---+----+---+-+
4 rows in set (0.01 sec)

將系統變量group_replication_start_on_boot=ON加入到my.cnf中，以避免node4重啟之後無法自動加入組。注意：如果組中的主要節點發生故障，在應用程式端如果未做主要節點的切換操作（如果在主要節點發生故障之後，組內新選舉出了主要節點，且應用程式已經切換到了新的主要節點，則無此問題。但凡是總有例外，風險意識必須有），那麼，在使用備份恢復主要節點時，需要將如下一些參數在資料庫Server啟動之前配置到my.cnf配置文件中，以防止在恢復主要節點的過程中，應用程式寫入新的數據，造成數據與組中的數據不一致而導致加入組失敗。

[root@node4 ~]# cat my.cnf
.
# 不自動啟動MGR插件
group_replication_start_on_boot=OFF
# 在啟動故障主要節點的資料庫進程之前，設置只讀，防止在執行分布式恢復過程中，應用程式寫入新的數據到該節點中，造成與組中的數據不一致而導致加入組失敗
super_read_only=ON
# 如果有使用事件調度器做一些數據操作，也需要在啟動之前關閉，以防止造成數據不一致而加入組失敗
event_scheduler=OFF

當發生故障的主要節點重新成功加入組之後，再將my.cnf配置文件中MGR插件和事件調度器的系統變量修改為ON，刪除只讀操作參數，如下：

# 動態啟用事件調度器
mysql> SET global event_scheduler=ON;
# 在my.cnf配置文件中啟用MGR插件和事件調度器，刪除只讀操作參數（注意，這裡不是將只讀參數設置為OFF，組複製會在組中根據單主和多主模式自動調整隻讀參數的設置，前面添加該參數到配置文件中的目的是為了避免發生意外寫入，一旦加入組之後，就不需要人為幹預了）
group_replication_start_on_boot=ON
event_scheduler=ON

PS：

xtrabackup 8.0版本支持備份時不加全局讀鎖（不執行FLUSH TABLE WITH READ LOCK語句），這就避免了在組複製中啟用多線程回放的組成員上執行備份時造成鎖死的現象，但是，為了保證一致性，是通過執行FLUSH NO_WRITE_TO_BINLOG BINARY LOGS語句來切換二進位日誌，並拷貝最後一個二進位日誌，在執行恢復時使用最後一個二進位日誌來恢復一致性位置的方式來變相實現的。如果有大事務，則存在無法切換二進位日誌的風險（執行切換二進位日誌的語句可能會被長時間阻塞），具體情況請大家自行斟酌，做好充足的測試。

在xtrabackup 8.0版本廢棄了innobackupex命令，統一使用xtrabackup命令，這樣一來，就可以使用xtrabackup命令的--lock-ddl和--lock-ddl-per-table選項在備份過程中阻塞DDL但並不阻塞DML操作。從而很好地防止了在備份期間發生DDL修改表結構導致備份失敗的問題。

在xtrabackup 8.0版本中，當發現有非InnoDB或RocksDB引擎時，Oracle MySQL版本則仍然會加全局讀鎖（由於Percona Server支持備份鎖，因此在這種情況下，Percona Server並不是加全局讀鎖，而是使用LOCK TABLES FOR BACKUP語句加備份鎖），當發現不存在非InnoDB或RocksDB引擎時，則如果無需考慮在備份期間存在DDL操作的情況，無需使用--lock-ddl和--lock-ddl-per-table選項，且備份過程中不會對資料庫執行加鎖操作。

羅小波·資料庫技術專家《千金良方——MySQL性能優化金字塔法則》、《數據生態：MySQL複製技術與生產實踐》作者之一。熟悉MySQL體系結構，擅長資料庫的整體調優，喜好專研開源技術，並熱衷於開源技術的推廣，在線上線下做過多次公開的資料庫專題分享，發表過近100篇資料庫相關的研究文章。

全文完。

Enjoy MySQL 8.0 :)

葉老師的「MySQL核心優化」大課已升級到MySQL 8.0，掃碼開啟MySQL 8.0修行之旅吧

相關焦點

  • 問題定位 | Peronca Xtrabackup 8.0近日踩坑總結 - xtrabackup 2.4和8.0區別
    Xtrabackup 8.0 在備份只有 InnoDB 表的實例時，xtrabackup_binlog_info 文件記錄的 GTID 信息不一定是準確的，但是備份恢復後 show master status 顯示的 GTID 是準確的。
  • xtrabackup 實現MySQL資料庫備份
    innobackupex命令的--copy-back選項用於執行恢復操作，其通過複製所有數據相關的文件至mysql伺服器 DATADIR目錄中來執行恢復過程。innobackupex通過backup-my.cnf來獲取DATADIR目錄的相關信息。
  • MySQL數據備份與恢復(二) -- xtrabackup工具
    操作均很簡單，此處略過xtrabackup通常使用 innobackupex命令， 可以使用 innobackupex  --help 命令查看參數及說明。--defaults-file=/app/data/mysql3307/etc/my.cnf &恢復完畢4.2  基於增量備份的恢復如果是基於第一次增量備份的恢復，操作如下/root/xtrabackup/bin/innobackupex
  • Mysql 物理備份Xtrabackup
    install -y percona-xtrabackup-80-8.0.4-1.el7.x86_64.rpm下載到哪裡? client arguments: --port=3306 --socket=/tmp/mysql.sock --user=root --password=* --backup=1 --target-dir=/u01/mysql/mysql8020debug/backup xtrabackup version 8.0.4 based on MySQL server 8.0.13 Linux
  • Percona XtraBackup 8.0.26使用說明
    Percona XtraBackup特性說明1)Percona Xtrabackup 8.0.26新增支持MyRocks存儲引擎，不支持TokuDB引擎2)Percona Xtrabackup 8.0.26 不支持低於MySQL 8.0的備份（因為MySQL 8.0在數據字典、redo log中和之前版本不兼容）3)Percona Xtrabackup 8.0.26 目前X86版本可以從官方下載，ARM
  • MySQL中xtrabackup備份恢復全攻略(r12筆記第11天)
    可以看到這兩個工具的版本還有一些差別，xtrabackup主要是用於熱備份innodb,或者是 xtradb表中數據的工具，不能備份其他類型的表，也不能備份數據表結構；innobackupex是將xtrabackup進行封裝的perl腳本，可以備份和恢復MyISAM表以及數據表結構。
  • MySQL 8.0 異步複製的三種方式
    例如，複製過程化中對主庫加鎖會影響對主庫的訪問，因此通常是不被允許的。這種場景下有兩種備選的複製方案：使用mysqldump程序或使用如XtraBackup的第三方工具。這兩種方案有各自的適用場合。使用mysqldump聯機建立複製的過程如下。
  • 故障分析 | xtrabackup 吃掉了MySQL的 binlog 文件名?
    前段時間在 centos 8 環境上做 MySQL 的備份恢復測試的時候，遇到一個問題，下面跟大家分享下。1、講環境伺服器OS資料庫版本備份工具Centos 8 for X86 mysql 8.0.18         xtrabackup 8.0.10 小編的問題場景出現在 centos 8 上，驗證也使用了 centos 8 版本，不過相信看到最後你會發現這個問題和 OS 關係不大，我們繼續往下看。
  • MySQL - Xtrabackup簡介
    Xtrabackup是由percona開源的免費資料庫熱備份軟體，它能對InnoDB資料庫和XtraDB存儲引擎的資料庫非阻塞地備份（對於MyISAM的備份同樣需要加表鎖）；mysqldump備份方式是採用的邏輯備份，其最大的缺陷是備份和恢復速度較慢，如果資料庫大於50G，mysqldump備份就不太適合
  • 一、Percona-XtraBackup介紹
    for MySQL 8.0, and Percona XtraDB Cluster 8.0.xtrabackup使用位圖文件來讀取增量備份所需的數據頁。Percona XtraBackup恢復原理xtrabackup可以通過使用xtrabackup --copy-back或xtrabackup --move-back
  • 技術分享 | 實戰 MySQL 8.0.17 Clone Plugin
    實操後小結：克隆與xtrabackup的對比克隆和xtrabackup備份都屬於物理熱備，備份恢復原理也近似。克隆在恢復實例時需要先啟動一個實例並授權，而xtrabackup不需要。xtrabackup在backup後需要apply log，克隆是類似mysqlbackup提供的backup-and-apply-log，合併在一起做。xtrabackup備份文件的權限等於執行命令的人的權限，恢復實例時需要人手chown回實例權限，克隆備份後權限和原數據權限一致，無需再人手chown，方便恢復。
  • xtrabackup 原理及實施
    這時，xtrabackup 會運行一個後臺進程，用於監視事務日誌，並從事務日誌複製最新的修改。Xtrabackup 必須持續的做這個操作，是因為事務日誌是會輪轉重複的寫入，並且事務日誌可以被重用。所以 xtrabackup 自啟動開始，就不停的將事務日誌中每個數據文件的修改都記錄下來。上面就是 xtrabackup 的備份過程。接下來是準備（prepare）過程。
  • xtrabackup 備份原理
    mysqldump 是邏輯備份工具，在數據量越來越大的情況下，備份和恢復所需要的時間越來越長，於是出現了
  • mysql資料庫之安裝、主從搭建、備份恢復
    使用xtrabackup備份和恢復資料庫：1. mysql-5.7.29資料庫安裝：  mysql資料庫安裝有多種方式，可以使用yum安裝，也可以編譯安裝，還有一種就是二進位安裝，不需要編譯。本文介紹的就是二進位的安裝方式。
  • 使用克隆插件搭建主從複製與組複製拓撲
    1.1.
  • MySQL 8.0 clone plugin 完整版
    組複製成員還可以配置使用克隆插件來作為另一種恢復方法（如果不使用克隆插件，則必須使用基於二進位日誌的狀態傳輸進行數據恢復），當組成員和待加入組的Server都配置支持克隆插件時，待加入組的Server可以自行決定選擇一個更加高效的方式從種子成員中獲取數據。有關更多信息，請參見《MySQL Group Replication for 8.0》."4.3.1 克隆用於分布式恢復"。
  • 【MySQL在線熱備神器】MySQL · 物理備份 · Percona XtraBackup 備份原理
    簡單來說，innobackupex 在 xtrabackup 之上做了一層封裝。一般情況下，我們是希望能備份 MyISAM 表的，雖然我們可能自己不用 MyISAM 表，但是 mysql 庫下的系統表是 MyISAM 的，因此備份基本都通過 innobackupex 命令進行；另外一個原因是我們可能需要保存位點信息。
  • MYSQL 增量恢復
    ，需要使用base，incr1，incr2三個備份都存在時，才能進行完整的恢復，每個備份的from_lsn都是基於上一個備份的to_lsn，所以缺一不可。--backup  --target-dir=/home/zqdba/20200324backup/incr2 --incremental-basedir=/home/zqdba/20200324backup/incr1假設周一是基於base的備份，周二是基於base的incr1備份，周三是基於base的incr2備份，在恢復資料庫的時候，需要使用base和
  • 複製信息記錄表|全方位認識 mysql 系統庫
    》中，我們詳細介紹了mysql系統庫中的時區信息記錄表，本期我們將為大家帶來系列第七篇《複製信息記錄表|全方位認識 mysql 系統庫》，下面請跟隨我們一起開始 mysql 系統庫的系統學習之旅吧！當一個事務中所有的binlog event組分發完成，讀取到下一個新的事務時，SQL協調器線程會重複以上判斷流程）。從庫多線程複製的crash recovery。
  • 備份恢復,DBA最後一道防線,你完全掌握了嗎?
    常用的備份工具有三個：邏輯導出：mysqldump，msyqlpump，mydumper物理導出：xtrabackup。1.mysqldump 是 MySQL 自帶的邏輯備份工具。備份原理是通過協議連接到 MySQL 資料庫，將需要備份的數據查詢出來，將查詢出的數據轉換成對應的SQL語句，當需要還原這些數據時，只要執行這些SQL語句，即可將對應的數據還原。2.xtrabackup是一款mysql開源備份(物理備份)工具，是由percona公司開發的。