はじめに
2022年1月18日にリリースされたMySQL Shell 8.0.28からダンプユーティリティーとダンプロードユーティリティーで、スキーマやテーブル、トリガー、ルーチン、イベントのダンプ及びロードを個々に制御できるようになりました。
MySQL Shell’s instance dump utility util.dumpInstance(), schema dump utility util.dumpSchemas(), table dump utility util.dumpTables(), and dump loading utility util.loadDump() have new filtering options to cover all objects that can be dumped and loaded. The options give you fine control over the content of the dump files and over what objects are loaded onto the destination server, and enable you to skip any objects that are causing issues. At an appropriate level for the utility, the options allow you to include or exclude a specified list of schemas, tables, routines, events, or triggers.
引用元 ： Changes in MySQL Shell 8.0.28 (2022-01-18, General Availability)
特定のオブジェクトをフィルタリングする機能はmysqlpumpにもあるため、本記事ではmysqlpumpと比較しながら、MySQL Shellの新機能について確認していきたいと思います。
mysqlpumpの使用方法
mysqlpumpは論理バックアップを実行するクライアントユーティリティーです。
ダンプする際は以下のように任意のファイルに出力します。
|
1 |
$ mysqlpump [options] > dump.sql |
インポートする際は、例えば、以下のようにmysqlクライアントでファイルに含まれているステートメントを実行します。
|
1 |
$ mysql < dump.sql |
なお、mysqlpumpはデフォルトで全てのスキーマを含めます。
また、–triggers,–routines,–eventsもデフォルトで有効となっています。
そのため、以下のように何もオプションを指定しない場合は、全てのスキーマ、テーブル、イベント、トリガー、ルーチンがダンプされます。
|
1 |
$ mysqlpump > test.dump |
※ただし、INFORMATION_SCHEMAなど一部のオブジェクトはダンプされません。詳しくは下記ドキュメントをご参照ください。
4.5.6 mysqlpump — A Database Backup Program | mysqlpump Restrictions
特定のスキーマ、テーブル、イベント、トリガー、ルーチンをダンプに含める場合は以下のオプションを使用します。
特定のスキーマ、テーブル、イベント、トリガー、ルーチンをダンプに含めない場合は以下のオプションを使用します。
Instance Dump Utility, Schema Dump Utility, 及び Table Dump UtilityとDump Loading Utility
公式リファレンスは以下になります。
MySQLの各ダンプユーティリティを使用する場合、それぞれ以下のようなコマンドを実行します。
|
1 2 3 |
shell-js> util.dumpInstance(outputUrl[, options]) shell-js> util.dumpSchemas(schemas, outputUrl[, options]) shell-js> util.dumpTables(schema, tables, outputUrl[, options]) |
インポートする際は、Dump Loading Utilityを使用します。
|
1 |
shell-js> util.loadDump(url[, options]) |
例えば、util.dumpInstanceを使用する場合、以下のコマンドで/backup1にダンプファイルを作成します。
|
1 |
shell-js> util.dumpInstance("/backup1") |
/backup1には以下のようにファイルが作成されます。
|
1 2 3 4 |
# ls /backup1/ d1.json d1@t1@@0.tsv.zst.idx d1@t1.triggers.sql d1@t2.json d1@t3@@0.tsv.zst.idx @.done.json @.sql d1.sql d1@t1.json d1@t2@@0.tsv.zst d1@t2.sql d1@t3.json @.json @.users.sql d1@t1@@0.tsv.zst d1@t1.sql d1@t2@@0.tsv.zst.idx d1@t3@@0.tsv.zst d1@t3.sql @.post.sql |
ダンプしたファイルは以下のコマンドでロードすることができます。
|
1 |
shell-js> util.loadDump("/backup1") |
特定のスキーマ、テーブル、イベント、トリガー、ルーチンをダンプに含める場合は以下のフィルタリングオプションを使用します。
- includeSchemas: array of strings
- includeTables: array of strings
- includeEvents: array of strings
- includeRoutines: array of strings
- includeTriggers: array of strings
特定のスキーマ、テーブル、イベント、トリガー、ルーチンをダンプに含めない場合は以下のオプションを使用します。
- excludeSchemas: array of strings
- excludeTables: array of strings
- excludeEvents: array of strings
- excludeRoutines: array of strings
- excludeTriggers: array of strings
なお、MySQL ShellではInstance Dump Utility, Schema Dump Utility及びTable Dump UtilityとDump Loading Utilityの双方で上記のオプションが使用できます。
つまりダンプ時とインポート時のどちらでも、特定のオブジェクトを含めるか否かを選択することができます。
オブジェクトのフィルタリング方法
まずは検証用の環境を準備します。
今回は移行元(DB1)と移行先(DB2)として2つのMySQLを用意しました。
バージョンは以下の通りです。
- MySQL8.0.28
- MySQL Shell 8.0.28
次に移行元のMySQLにデータを作成します。
スキーマとテーブルを作成します。
|
1 2 3 4 5 |
mysql> CREATE DATABASE d1; mysql> CREATE TABLE d1.t1 (col1 int Primary key AUTO_INCREMENT, col2 int); mysql> CREATE TABLE d1.t2 (col1 int Primary key AUTO_INCREMENT, col2 int); mysql> CREATE TABLE d1.t3 (col1 int Primary key AUTO_INCREMENT, col2 int); mysql> INSERT INTO d1.t1(col2) values(1),(1),(1),(1),(1); |
トリガー、イベント、ルーチンを作成します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
mysql> CREATE DEFINER = root@localhost TRIGGER d1.test_trigger_1 AFTER INSERT ON t1 for each row insert into t2(col2) values(1); mysql> CREATE DEFINER = root@localhost TRIGGER d1.test_trigger_2 AFTER INSERT ON t1 for each row insert into t3(col2) values(2); mysql> CREATE DEFINER = root@localhost TRIGGER d1.test_trigger_3 AFTER INSERT ON t3 for each row insert into t2(col1) values(1); mysql> CREATE DEFINER= root@localhost EVENT d1.test_event_1 ON SCHEDULE EVERY 1 DAY STARTS '2022-03-29 00:00:00' DO insert into t2(col1) values(3); mysql> DELIMITER // mysql> CREATE DEFINER = root@localhost PROCEDURE d1.test_procedure_1() SQL SECURITY DEFINER BEGIN SHOW DATABASES; END; // mysql> DELIMITER ; |
test_trigger_1,test_trigger_2はd1.t1に、test_trigger_3はd1.t3に関連付けられたトリガーとなっています。
また、test_event_1とtest_procedure_1はd1に関連付けられています。
mysqlpump
mysqlpumpで全トリガー中、test_trigger_1のみダンプする場合は以下のコマンドとなります。また、この場合スキーマやテーブル、イベント、ルーチンは全てダンプされます。
|
1 2 3 4 |
# mysqlpump --include-triggers=test_trigger_1 > test1.dump # grep -e "test_trigger" test1.dump /*!50017 CREATE*/ /*!50003 DEFINER=`root`@`localhost`*/ /*!50017 TRIGGER `d1`.`test_trigger_1` AFTER INSERT ON `t1` FOR EACH ROW insert into t2(col2) values(1) */ |
また、mysqlpumpではワイルドカードを使用して、含める/含めないオブジェクトを指定することができます。
以下のようにtest_trigger_%とするとこれに一致するトリガーがダンプに含まれます。
|
1 2 3 4 5 6 |
# mysqlpump --include-triggers=test_trigger_% > test2.dump # grep -e "test_trigger" test2.dump /*!50017 CREATE*/ /*!50003 DEFINER=`root`@`localhost`*/ /*!50017 TRIGGER `d1`.`test_trigger_1` AFTER INSERT ON `t1` FOR EACH ROW insert into t2(col2) values(1) */ /*!50017 CREATE*/ /*!50003 DEFINER=`root`@`localhost`*/ /*!50017 TRIGGER `d1`.`test_trigger_2` AFTER INSERT ON `t1` FOR EACH ROW insert into t3(col2) values(2) */ /*!50017 CREATE*/ /*!50003 DEFINER=`root`@`localhost`*/ /*!50017 TRIGGER `d1`.`test_trigger_3` AFTER INSERT ON `t3` FOR EACH ROW insert into t2(col1) values(1) */ |
なお、トリガーについては、--include-tablesまたは--exclude-tablesオプションを使用すると、そのテーブルに関連付けられているトリガーにも適用されます。
例えば、以下のコマンドの場合d1.t1に関連するトリガーのみがダンプに含まれます。
|
1 2 3 4 5 |
# mysqlpump --include-tables=t1 > test3.dump # grep -e "test_trigger" test3.dump /*!50017 CREATE*/ /*!50003 DEFINER=`root`@`localhost`*/ /*!50017 TRIGGER `d1`.`test_trigger_1` AFTER INSERT ON `t1` FOR EACH ROW insert into t2(col2) values(1) */ /*!50017 CREATE*/ /*!50003 DEFINER=`root`@`localhost`*/ /*!50017 TRIGGER `d1`.`test_trigger_2` AFTER INSERT ON `t1` FOR EACH ROW insert into t3(col2) values(2) */ |
MySQL Shell
MySQL Shellでtest_trigger_1のみダンプする場合は以下のコマンドとなります。また、スキーマやテーブル、イベント、ルーチンは特に指定していないため、全てダンプされます。
|
1 |
shell-js> util.dumpInstance("/backup1", {includeTriggers: ["d1.t1.test_trigger_1"]}) |
また、MySQL Shellのdump,loadユーティリティーのワイルドカードの使用についてはドキュメントに記載はありません。
実際に以下のようにワイルドカードを使用するとエラーとなりました。
|
1 2 |
shell-js> util.dumpInstance("/backup2", {includeTriggers: ["d1.t1.test_trigger_%"]}) Util.dumpInstance: Argument #2: Failed to parse trigger to be included 'd1.t1.test_trigger_%': Invalid object name, expected end of name, but got: '%'. (ArgumentError) |
なお、トリガーの場合は、<スキーマ>.<テーブル>.<オブジェクト>と指定するところで、<スキーマ>.<テーブル>と指定した場合、
<スキーマ>.<テーブル>に関連するトリガーを含める/含めないことができます。
例えば、以下のコマンドの場合d1.t1に関連するトリガーが全てダンプに含まれます。
|
1 |
shell-js> util.dumpInstance("/backup2", {includeTriggers: ["d1.t1"]}) |
/backup2を確認すると1@t1.triggers.sqlファイルが存在し、その中身にはd1.t1.test_trigger_1とd1.t1.test_trigger_2の定義が記載されていることがわかります。
|
1 2 3 4 5 6 |
# ls /backup2/*.triggers.sql /backup2/d1@t1.triggers.sql # grep -e "test_trigger_" /backup2/d1@t1.triggers.sql | grep -e "CREATE" /*!50003 CREATE DEFINER=`root`@`localhost` TRIGGER `test_trigger_1` AFTER INSERT ON `t1` FOR EACH ROW insert into t2(col2) values(1) */;; /*!50003 CREATE DEFINER=`root`@`localhost` TRIGGER `test_trigger_2` AFTER INSERT ON `t1` FOR EACH ROW insert into t3(col2) values(2) */;; |
特定のオブジェクトのみをダンプする
mysqlpump
例えば、特定のテーブルのみをダンプしたい場合は次のようなオプションを使用します。
ここでは
–include-databasesと–include-tablesでスキーマとテーブルを指定し、
–no-create-db、–skip-routines、–skip-triggers、–skip-eventsで各オブジェクトのCREATE文の出力を抑制します。
|
1 2 |
# mysqlpump --include-databases=d1 --include-tables=t1 --no-create-db --skip-routines \ --skip-triggers --skip-events > test4.dump |
テーブル定義のみダンプし、データを含めたくない場合は、さらに–skip-dump-rowsを追加します。
|
1 2 |
# mysqlpump --include-databases=d1 --include-tables=t1 --no-create-db --skip-routines \ --skip-triggers --skip-events --skip-dump-rows > test5.dump |
特定のトリガーのみダンプしたい場合は、次のようなオプションを使用します。
–no-create-infoでCREATE TABLEの出力を抑制し、 –include-triggersでダンプするトリガーを指定します。
|
1 2 |
# mysqlpump --no-create-info --no-create-db --skip-dump-rows --databases d1 \ --skip-routines --skip-events --include-triggers=test_trigger_1 > test6.dump |
イベントやルーチンの場合も –include-events, –include-routines
を使用することで、同じことが可能です。
MySQL Shell
MySQL Shellには以下のようなオプションがあり、DDLのみのダンプかデータのみのダンプかを選択できるようになっています。
デフォルトではどちらもfalseです。
- ddlOnly: [ true | false ]
- trueの場合、DDLファイルのみが含まれ、データはダンプされません。
- デフォルトでfalseです。
- dataOnly: [ true | false ]
- trueの場合、データのみが含まれ、DDLはダンプされません。
- デフォルトでfalseです。
特定のテーブルをダンプしたい場合は、以下のようにオプションを指定します。
|
1 |
shell-js> util.dumpSchemas(["d1"], "/backup3",{ includeTables: ["d1.t1"]}) |
また、データはダンプせずにテーブル定義のみをダンプする場合は、以下のようにオプションを指定します。
|
1 |
shell-js> util.dumpSchemas(["d1"], "/backup4",{ ddlOnly: true, includeTables: ["d1.t1"]}) |
また、イベント、トリガー、ルーチンに関しては、ダンプに含めるか否かを以下のオプションで制御することができます。すべてデフォルトでtrueです。
- events: [ true | false ]
- triggers: [ true | false ]
- routines: [ true | false ]
しかし、mysqlpumpの--no-create-infoのようなCREATE TABLEを含めない(その他のDDLは含める)といったオプションはありません。
そのため、CREATE DATABASE | TABLEを含めず、特定のCREATE TRIGGER | EVENT | PROCEDUREのみをダンプするといった制御はできないようです。
ただし、イベントとルーチンの場合は以下のように、スキーマのテーブルを全て除外することで、スキーマ、イベント、ルーチンのみのDDLを出力することができました。
|
1 |
shell-js> util.dumpSchemas(["d1"], "/backup5",{ excludeTables: ["d1.t1","d1.t2","d1.t3"]}) |
一方、トリガーの場合は、関連するテーブルが含まれていないとダンプできないようで、以下のようにテーブルを全て含めないようにして、トリガーを指定するとエラーとなりました。
|
1 2 3 4 |
shell-js> util.dumpSchemas(["d1"], "/backup6",{ excludeTables: ["d1.t1","d1.t2","d1.t3"], includeTriggers: ["d1.t1.test_trigger_1"], dryRun: true}) ERROR: The includeTriggers option contains a trigger `d1`.`t1`.`test_trigger_1` which refers to an excluded table. Util.dumpSchemas: Conflicting filtering options (ArgumentError) |
進行状況について
mysqlpumpでは、–watch-progressオプションで進行状況が表示します。これはデフォルトで有効です。
|
1 2 3 |
# mysqlpump --watch-progress > test4.dump Dump progress: 1/1 tables, 0/3 rows Dump completed in 146 |
MySQL Shellでは、showProgressオプションをtrueに指定すると進行状況が表示されます。これもデフォルトでtrueです。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
shell-js> util.dumpSchemas(["d1"], "/backup6") Acquiring global read lock Global read lock acquired Initializing - done 1 schemas will be dumped and within them 3 tables, 0 views, 1 event, 1 routine, 3 triggers. Gathering information - done All transactions have been started Locking instance for backup Global read lock has been released Writing global DDL files Running data dump using 4 threads. NOTE: Progress information uses estimated values and may not be accurate. Writing schema metadata - done Writing DDL - done Writing table metadata - done Starting data dump 100% (5 rows / ~5 rows), 0.00 rows/s, 0.00 B/s uncompressed, 0.00 B/s compressed Dump duration: 00:00:00s Total duration: 00:00:00s Schemas dumped: 1 Tables dumped: 3 Uncompressed data size: 20 bytes Compressed data size: 47 bytes Compression ratio: 0.4 Rows written: 5 Bytes written: 47 bytes Average uncompressed throughput: 20.00 B/s Average compressed throughput: 47.00 B/s |
また、MySQL Shellではインポートの際には進行状況が永続的なファイルに保存されます。
これにより、ロードが途中で中断された場合、途中から再開することができるようになっています。
インポートの進行状態は永続的な進行状態ファイルに格納され、正常に完了したステップと中断または失敗したステップが記録されます。 デフォルトでは、進捗状態ファイルは load-progress.server_uuid.json という名前でダンプディレクトリに作成されますが、別の名前と場所を選択することもできます。 ダンプロードユーティリティは、ダンプのインポートを再開または再試行するときに進行状態ファイルを参照し、完了したステップをスキップします。
注意が必要なのは、この機能はデフォルトで有効であり、永続的にファイルに記録されるということです。
そのため、一度データをインポートした後に、例えば操作ミスでテーブルを誤って削除してしまった場合などに、再度ファイルをインポートしたい場合に、util.loadDump()を再度実行しても何もインポートされません。
進行状況を記録するファイルには全てのインポートが完了済みと記録されているためです。
試しに、先ほどダンプした/backup6を移行先のDB2にインポートしてみます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
shell-js> util.loadDump("/backup6") Loading DDL and Data from '/backup6' using 4 threads. Opening dump... Target is MySQL 8.0.28. Dump was produced from MySQL 8.0.28 Scanning metadata - done Checking for pre-existing objects... Executing common preamble SQL Executing DDL - done Executing view DDL - done Starting data load Executing common postamble SQL 100% (20 bytes / 20 bytes), 0.00 B/s, 3 / 3 tables done Recreating indexes - done 3 chunks (5 rows, 20 bytes) for 3 tables in 1 schemas were loaded in 0 sec (avg throughput 20.00 B/s) 0 warnings were reported during the load. |
再度、インポートを実行します。実際にはデータのインポートは行われていないため、出力内容が変化していることが確認できます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
shell-js> util.loadDump("/backup6") Loading DDL and Data from '/backup6' using 4 threads. Opening dump... Target is MySQL 8.0.28. Dump was produced from MySQL 8.0.28 NOTE: Load progress file detected. Load will be resumed from where it was left, assuming no external updates were made. You may enable the 'resetProgress' option to discard progress for this MySQL instance and force it to be completely reloaded. Scanning metadata - done Executing common preamble SQL Executing DDL - done Executing view DDL - done Starting data load 100% (20 bytes / 20 bytes), 0.00 B/s, 0 / 3 tables done Executing common postamble SQL Recreating indexes - done There was no remaining data left to be loaded. 0 warnings were reported during the load. |
次にd1.t1を削除した後に、再度インポートを実行します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
shell-js> \sql drop table d1.t1 Query OK, 0 rows affected (0.0091 sec) shell-js> util.loadDump("/backup6") Loading DDL and Data from '/backup6' using 4 threads. Opening dump... Target is MySQL 8.0.28. Dump was produced from MySQL 8.0.28 NOTE: Load progress file detected. Load will be resumed from where it was left, assuming no external updates were made. You may enable the 'resetProgress' option to discard progress for this MySQL instance and force it to be completely reloaded. Scanning metadata - done Executing common preamble SQL Executing DDL - done Executing view DDL - done Starting data load 100% (20 bytes / 20 bytes), 0.00 B/s, 0 / 3 tables done Executing common postamble SQL Recreating indexes - done There was no remaining data left to be loaded. 0 warnings were reported during the load. shell-js> \sql show tables from d1 +--------------+ | Tables_in_d1 | +--------------+ | t2 | | t3 | +--------------+ 2 rows in set (0.0012 sec) |
削除されたd1.t1は再度インポートを実行しても、再作成されるわけではないことがわかります。
進捗状態ファイルはprogressFileオプションで指定でき、デフォルトでload-progress.<server_uuid>.json という名前で作成されます。
先ほどutil.loadDump("/backup6")を実行した後には以下のように記録されています。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
# cat /backup6/load-progress.29031710-af05-11ec-a5e7-0200170293b2.json {"op":"SERVER-UUID","done":true,"timestamp":1648618612101,"uuid":"29031710-af05-11ec-a5e7-0200170293b2"} {"op":"SCHEMA-DDL","done":false,"timestamp":1648618612136,"schema":"d1"} {"op":"TABLE-DDL","done":false,"timestamp":1648618612136,"schema":"d1","table":"t3"} {"op":"TABLE-DDL","done":false,"timestamp":1648618612136,"schema":"d1","table":"t1"} {"op":"TABLE-DDL","done":false,"timestamp":1648618612136,"schema":"d1","table":"t2"} {"op":"TABLE-DDL","done":true,"timestamp":1648618612156,"schema":"d1","table":"t2"} {"op":"TABLE-DDL","done":true,"timestamp":1648618612159,"schema":"d1","table":"t3"} {"op":"TABLE-DDL","done":true,"timestamp":1648618612161,"schema":"d1","table":"t1"} {"op":"SCHEMA-DDL","done":true,"timestamp":1648618612162,"schema":"d1"} {"op":"TABLE-DATA","done":false,"timestamp":1648618612162,"schema":"d1","table":"t3","chunk":0} {"op":"TABLE-DATA","done":false,"timestamp":1648618612162,"schema":"d1","table":"t1","chunk":0} {"op":"TABLE-DATA","done":false,"timestamp":1648618612162,"schema":"d1","table":"t2","chunk":0} {"op":"TABLE-DATA","done":true,"timestamp":1648618612166,"schema":"d1","table":"t3","chunk":0,"bytes":0,"raw_bytes":9} {"op":"TABLE-DATA","done":true,"timestamp":1648618612167,"schema":"d1","table":"t2","chunk":0,"bytes":0,"raw_bytes":9} {"op":"TABLE-DATA","done":true,"timestamp":1648618612169,"schema":"d1","table":"t1","chunk":0,"bytes":20,"raw_bytes":29} {"op":"TRIGGERS-DDL","done":false,"timestamp":1648618612169,"schema":"d1","table":"t3"} {"op":"TRIGGERS-DDL","done":true,"timestamp":1648618612178,"schema":"d1","table":"t3"} {"op":"TRIGGERS-DDL","done":false,"timestamp":1648618612178,"schema":"d1","table":"t1"} {"op":"TRIGGERS-DDL","done":true,"timestamp":1648618612194,"schema":"d1","table":"t1"} |
再度インポートしたい場合は、progressFileで別のファイル名を指定するか、resetProgressをtrueに設定します。
resetProgressをtrueにすると、進行状態がリセットされ、インポートが最初から再開されます。
なお、ダンプロードユーティリティはデフォルトでは作成済みのオブジェクトを自動でスキップはしないため、再度インポートをする場合は、手動で作成済みのオブジェクトを削除する必要があります。
もしくは、ignoreExistingObjectsをtrueに設定することで、作成済みのオブジェクトをスキップすることもできます。この場合、作成済みのオブジェクトとダンプファイルのオブジェクトの内容が完全に一致するかまではチェックされないため、注意が必要です。
また、この進行状況の記録はテーブルとスキーマは個々に記録されていますが、トリガーやイベント、ルーチンは個別に記録されていません。
例えば、トリガーが以下のようにテーブル単位での記録となっています。
|
1 2 |
{"op":"TRIGGERS-DDL","done":false,"timestamp":1648618612178,"schema":"d1","table":"t1"} {"op":"TRIGGERS-DDL","done":true,"timestamp":1648618612194,"schema":"d1","table":"t1"} |
つまり、d1.t1.test_trigger_1を除きインポートした場合であっても、ファイルにはd1.t1にはd1.t1関連付けられたトリガーのインポートは完了したと記録されます。
再度インポートを実行しても、初回に除外したトリガーがインポートされるという動作にはなりません。
まずは先ほどインポートしたd1スキーマを削除します。
resetProgress: trueで進行状況の記録をリセットし、includeTriggersでd1.t1.test_trigger_1のみを指定します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
shell-js> \sql drop database d1 Query OK, 2 rows affected (0.0038 sec) shell-js> util.loadDump("/backup6" ,{resetProgress: true , includeTriggers: ["d1.t1.test_trigger_1"]}) Loading DDL and Data from '/backup6' using 4 threads. Opening dump... Target is MySQL 8.0.28. Dump was produced from MySQL 8.0.28 NOTE: Load progress file detected for the instance but 'resetProgress' option was enabled. Load progress will be discarded and the whole dump will be reloaded. Scanning metadata - done Checking for pre-existing objects... Executing common preamble SQL Executing DDL - done Executing view DDL - done Starting data load Executing common postamble SQL 100% (20 bytes / 20 bytes), 0.00 B/s, 3 / 3 tables done Recreating indexes - done 3 chunks (5 rows, 20 bytes) for 3 tables in 1 schemas were loaded in 0 sec (avg throughput 20.00 B/s) shell-js> \sql show triggers from d1 +----------------+--------+-------+--------------------------------+--------+------------------------+-----------------------------------------------------------------------------------------------------------------------+----------------+----------------------+----------------------+--------------------+ | Trigger | Event | Table | Statement | Timing | Created | sql_mode | Definer | character_set_client | collation_connection | Database Collation | +----------------+--------+-------+--------------------------------+--------+------------------------+-----------------------------------------------------------------------------------------------------------------------+----------------+----------------------+----------------------+--------------------+ | test_trigger_1 | INSERT | t1 | insert into t2(col2) values(1) | AFTER | 2022-03-30 06:00:16.52 | ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION | root@localhost | utf8mb4 | utf8mb4_0900_ai_ci | utf8mb4_0900_ai_ci | +----------------+--------+-------+--------------------------------+--------+------------------------+-----------------------------------------------------------------------------------------------------------------------+----------------+----------------------+----------------------+--------------------+ 1 row in set (0.0018 sec) |
作成されているトリガーはtest_trigger_1のみです。
一方、ファイルにはd1.t1とd1.t3に関連するトリガーについて完了済みと記録されています。
|
1 2 3 4 5 6 7 8 |
# cat /backup6/load-progress.29031710-af05-11ec-a5e7-0200170293b2.json {"op":"SERVER-UUID","done":true,"timestamp":1648620016456,"uuid":"29031710-af05-11ec-a5e7-0200170293b2"} ... {"op":"TABLE-DATA","done":true,"timestamp":1648620016512,"schema":"d1","table":"t1","chunk":0,"bytes":20,"raw_bytes":29} {"op":"TRIGGERS-DDL","done":false,"timestamp":1648620016512,"schema":"d1","table":"t3"} {"op":"TRIGGERS-DDL","done":true,"timestamp":1648620016517,"schema":"d1","table":"t3"} {"op":"TRIGGERS-DDL","done":false,"timestamp":1648620016517,"schema":"d1","table":"t1"} {"op":"TRIGGERS-DDL","done":true,"timestamp":1648620016528,"schema":"d1","table":"t1"} |
そのため、再度test_trigger_2,test_trigger_3をインポートしようとしても、これらのトリガーは作成されません。
|
1 2 3 4 5 6 7 8 9 10 |
shell-js> util.loadDump("/backup6" , { includeTriggers: ["d1.t1.test_trigger_2","d1.t3.test_trigger_3"]}) shell-js> \sql show triggers from d1 +----------------+--------+-------+--------------------------------+--------+------------------------+-----------------------------------------------------------------------------------------------------------------------+----------------+----------------------+----------------------+--------------------+ | Trigger | Event | Table | Statement | Timing | Created | sql_mode | Definer | character_set_client | collation_connection | Database Collation | +----------------+--------+-------+--------------------------------+--------+------------------------+-----------------------------------------------------------------------------------------------------------------------+----------------+----------------------+----------------------+--------------------+ | test_trigger_1 | INSERT | t1 | insert into t2(col2) values(1) | AFTER | 2022-03-30 06:00:16.52 | ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION | root@localhost | utf8mb4 | utf8mb4_0900_ai_ci | utf8mb4_0900_ai_ci | +----------------+--------+-------+--------------------------------+--------+------------------------+-----------------------------------------------------------------------------------------------------------------------+----------------+----------------------+----------------------+--------------------+ 1 row in set (0.0012 sec) |
まとめ
オブジェクトをフィルタリングした場合の進行状況の記録のされ方はオブジェクトによって異なるため、フィルタリング機能を使用しつつ、再ロードを実施する場合は、注意する必要がありそうです。
オブジェクトのフィルタリング自体はmysqlpumpですでにできたことですが、MySQL Shellではインポート時にもフィルタリングができるようになり、ますますMySQL Shellの機能が充実してきています。
今後もMySQL Shellのアップデートにも注目していきたいと思います。
