MySQLdumpは、MySQLで最も人気のある論理バックアップツールです。 MySQLディストリビューションに含まれているため、すべてのMySQLインスタンスですぐに使用できます。
ただし、論理バックアップは、MySQLデータベースをバックアップするための最速または最もスペース効率の高い方法ではありませんが、物理バックアップよりも大きな利点があります。
物理バックアップは通常、オールオアナッシングタイプのバックアップです。 Xtrabackupを使用して部分バックアップを作成することは可能かもしれませんが（これについては以前のブログ投稿の1つで説明しました）、そのようなバックアップの復元には注意が必要で時間がかかります。
基本的に、単一のテーブルを復元する場合は、レプリケーションチェーン全体を停止し、すべてのノードで一度にリカバリを実行する必要があります。これは大きな問題です。最近では、すべてのデータベースを停止する余裕はほとんどありません。
もう1つの問題は、テーブルレベルがXtrabackupで達成できる最低の粒度レベルであるということです。単一のテーブルを復元することはできますが、その一部を復元することはできません。ただし、論理バックアップはSQLステートメントの実行方法で復元できるため、実行中のクラスターで簡単に実行でき、実行するSQLステートメントを選択できます（簡単には呼び出せませんが、それでも）。テーブルの部分的な復元を実行します。
mysqldumpを使用した単一のMySQLテーブルの復元
最初は、部分バックアップではデータの一貫したビューが提供されないことに注意してください。別々のテーブルのバックアップを取る場合、バックアップからすべてのデータを復元する場合でも、そのようなバックアップを時間内に既知の位置に復元することはできません（たとえば、レプリケーションスレーブをプロビジョニングするため）。これを後回しにして、先に進みましょう。
データセットには、1つのスキーマと複数のテーブルが含まれています：
mysql> SHOW SCHEMAS;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sbtest |
| sys |
+--------------------+
5 rows in set (0.01 sec)
mysql> SHOW TABLES FROM sbtest;
+------------------+
| Tables_in_sbtest |
+------------------+
| sbtest1 |
| sbtest10 |
| sbtest11 |
| sbtest12 |
| sbtest13 |
| sbtest14 |
| sbtest15 |
| sbtest16 |
| sbtest17 |
| sbtest18 |
| sbtest19 |
| sbtest2 |
| sbtest20 |
| sbtest21 |
| sbtest22 |
| sbtest23 |
| sbtest24 |
| sbtest25 |
| sbtest26 |
| sbtest27 |
| sbtest28 |
| sbtest29 |
| sbtest3 |
| sbtest30 |
| sbtest31 |
| sbtest32 |
| sbtest4 |
| sbtest5 |
| sbtest6 |
| sbtest7 |
| sbtest8 |
| sbtest9 |
+------------------+
32 rows in set (0.00 sec)次に、バックアップを取る必要があります。この問題に取り組むにはいくつかの方法があります。データセット全体の一貫したバックアップを取ることができますが、これにより、すべてのデータを含む大きな単一のファイルが生成されます。単一のテーブルを復元するには、そのファイルからテーブルのデータを抽出する必要があります。もちろん可能ですが、かなり時間がかかり、スクリプト化できるのはかなり手動の操作ですが、適切なスクリプトがない場合は、データベースがダウンしていて大きなプレッシャーにさらされているときにアドホックコードを記述します。必ずしも最も安全なアイデアとは限りません。
その代わりに、すべてのテーブルが個別のファイルに保存されるようにバックアップを準備できます。
[email protected]:~/backup# d=$(date +%Y%m%d) ; db='sbtest'; for tab in $(mysql -uroot -ppass -h127.0.0.1 -e "SHOW TABLES FROM ${db}" | grep -v Tables_in_${db}) ; do mysqldump --set-gtid-purged=OFF --routines --events --triggers ${db} ${tab} > ${d}_${db}.${tab}.sql ; done--set-gtid-purged=OFFに設定されていることに注意してください。このデータを後でデータベースにロードする場合に必要です。そうしないと、MySQLは@@ GLOBAL.GTID_PURGEDを設定しようとしますが、これはおそらく失敗します。 MySQLはSET@@SESSION.SQL_LOG_BIN=0を設定することもできます。これは間違いなく私たちが望んでいることではありません。これらの設定は、データセット全体の一貫したバックアップを作成し、それを使用して新しいノードをプロビジョニングする場合に必要です。私たちの場合、それは一貫したバックアップではなく、そこから何かを再構築する方法はありません。必要なのは、マスターにロードしてスレーブに複製できるダンプを生成することだけです。
このコマンドは、本番クラスターにアップロードできるSQLファイルの適切なリストを生成しました：
[email protected]:~/backup# ls -alh
total 605M
drwxr-xr-x 2 root root 4.0K Mar 18 14:10 .
drwx------ 9 root root 4.0K Mar 18 14:08 ..
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest10.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest11.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest12.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest13.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest14.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest15.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest16.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest17.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest18.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest19.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest1.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest20.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest21.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest22.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest23.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest24.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest25.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest26.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest27.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest28.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest29.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest2.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest30.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest31.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest32.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest3.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest4.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest5.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest6.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest7.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest8.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest9.sqlデータを復元する場合は、SQLファイルをマスターノードにロードするだけです。
[email protected]:~/backup# mysql -uroot -ppass sbtest < 20200318_sbtest.sbtest11.sqlデータはデータベースにロードされ、すべてのスレーブに複製されます。
ClusterControlを使用して単一のMySQLテーブルを復元する方法
現在、ClusterControlは、1つのテーブルだけを復元する簡単な方法を提供していませんが、いくつかの手動操作で復元することは可能です。使用できるオプションは2つあります。まず、少数のテーブルに適しており、基本的に、個別のテーブルの部分バックアップを1つずつ実行するスケジュールを作成できます。
ここでは、sbtest.sbtest1テーブルのバックアップを作成しています。 sbtest2テーブルの別のバックアップを簡単にスケジュールできます：
または、バックアップを実行して、単一のスキーマからのデータを別のファイル：
これで、ファイル内で不足しているデータを手動で見つけて、復元することができます。このバックアップを別のサーバーに送信するか、ClusterControlに実行させます：
サーバーを稼働させたままにして、データを抽出できますmysqldumpまたはSELECT…INTOOUTFILEのいずれかを使用して復元したかった。このような抽出されたデータは、本番クラスターに適用する準備が整います。