MySQLdumpとMySQLシェルユーティリティを使用したパフォーマンステスト

MySQL  localhost:33060+ ssl  JS > util.dumpInstance("/home/vagrant/production_backup", {threads: 2, ocimds: true,compatibility: ["strip_restricted_grants"]})

Acquiring global read lock

Global read lock acquired

All transactions have been started

Locking instance for backup

Global read lock has been released

Checking for compatibility with MySQL Database Service 8.0.22

NOTE: Progress information uses estimated values and may not be accurate.

Data dump for table `sbtest`.`sbtest1` will be written to 38 files

Data dump for table `sbtest`.`sbtest10` will be written to 38 files

Data dump for table `sbtest`.`sbtest3` will be written to 38 files

Data dump for table `sbtest`.`sbtest2` will be written to 38 files

Data dump for table `sbtest`.`sbtest4` will be written to 38 files

Data dump for table `sbtest`.`sbtest5` will be written to 38 files

Data dump for table `sbtest`.`sbtest6` will be written to 38 files

Data dump for table `sbtest`.`sbtest7` will be written to 38 files

Data dump for table `sbtest`.`sbtest8` will be written to 38 files

Data dump for table `sbtest`.`sbtest9` will be written to 38 files

2 thds dumping - 36% (17.74M rows / ~48.14M rows), 570.93K rows/s, 111.78 MB/s uncompressed, 50.32 MB/s compressed

1 thds dumping - 100% (50.00M rows / ~48.14M rows), 587.61K rows/s, 115.04 MB/s uncompressed, 51.79 MB/s compressed

Duration: 00:01:27s                                                                                                

Schemas dumped: 3                                                                                                  

Tables dumped: 10                                                                                                  

Uncompressed data size: 9.78 GB                                                                                    

Compressed data size: 4.41 GB                                                                                      

Compression ratio: 2.2                                                                                             

Rows written: 50000000                                                                                             

Bytes written: 4.41 GB                                                                                             

Average uncompressed throughput: 111.86 MB/s                                                                       

Average compressed throughput: 50.44 MB/s    

データベース全体（mysqldumpに使用されたものと同じデータ）のダンプを取得するのに合計1分27秒かかりました。また、その進行状況を示しており、バックアップがどれだけ完了したかを知るのに非常に役立ちます。バックアップの実行にかかった時間を示します。

並列処理は、サーバー内のコアの数によって異なります。私の場合、値を大まかに増やすことは役に立ちません。 （私のマシンには2つのコアがあります。）

復元速度テスト

復元の部分では、mysqldumpバックアップを別のスタンドアロンサーバーに復元します。バックアップファイルは、rsyncを使用して宛先サーバーにすでに移動されています。

テストケース1 例

[[email protected] vagrant]#time gunzip < /mnt/mysqldump_schemaanddata.sql.gz | mysql -u root -p

10GBのデータを復元するのに約16分26秒かかりました。

テストケース2

この場合、mysqlシェルユーティリティを使用して、別のスタンドアロンホストにバックアップファイルをロードしています。バックアップファイルはすでに移行先サーバーに移動しています。復元プロセスを始めましょう。

例

​ MySQL  localhost:33060+ ssl  JS > util.loadDump("/home/vagrant/production_backup", {progressFile :"/home/vagrant/production_backup/log.json",threads :2})

Opening dump...

Target is MySQL 8.0.22. Dump was produced from MySQL 8.0.22

Checking for pre-existing objects...

Executing common preamble SQL

Executing DDL script for schema `cluster_control`

Executing DDL script for schema `proxydemo`

Executing DDL script for schema `sbtest`

.

.

.

2 thds loading \ 1% (150.66 MB / 9.78 GB), 6.74 MB/s, 4 / 10 tables done

2 thds loading / 100% (9.79 GB / 9.79 GB), 1.29 MB/s, 10 / 10 tables done

[Worker001] [email protected]@@37.tsv.zst: Records: 131614  Deleted: 0  Skipped: 0  Warnings: 0

[Worker002] [email protected]@@37.tsv.zst: Records: 131614  Deleted: 0  Skipped: 0  Warnings: 0

Executing common postamble SQL                                                        

380 chunks (50.00M rows, 9.79 GB) for 10 tables in 2 schemas were loaded in 40 min 6 sec (avg throughput 4.06 MB/s)

10GBのデータを復元するのに約40分6秒かかりました。

次に、REDOログを無効にして、mysqlを使用してデータのインポートを開始してみましょう。シェルユーティリティ。

​mysql> alter instance disable innodb redo_log;

Query OK, 0 rows affected (0.00 sec)



 MySQL  localhost:33060+ ssl  JS >util.loadDump("/home/vagrant/production_backup", {progressFile :"/home/vagrant/production_backup/log.json",threads :2})

Opening dump...

Target is MySQL 8.0.22. Dump was produced from MySQL 8.0.22

Checking for pre-existing objects...

Executing common preamble SQL

.

.

.

380 chunks (50.00M rows, 9.79 GB) for 10 tables in 3 schemas were loaded in 19 min 56 sec (avg throughput 8.19 MB/s)

0 warnings were reported during the load.

REDOログを無効にした後、平均スループットは最大2倍に増加しました。

注：実動システムでREDOロギングを無効にしないでください。 REDOロギングが無効になっているときにサーバーをシャットダウンして再起動できますが、REDOロギングが無効になっているときに予期しないサーバーが停止すると、データが失われたり、インスタンスが破損したりする可能性があります。

物理バックアップ

お気づきかもしれませんが、論理バックアップ方式は、マルチスレッドであっても、テスト対象の小さなデータセットであっても非常に時間がかかります。これが、ClusterControlがファイルのコピーに基づく物理バックアップ方法を提供する理由の1つです。このような場合、論理バックアップを処理するSQLレイヤーではなく、ハードウェアによって制限されます。ディスクがファイルを読み取る速度とネットワークがデータベースノードとバックアップサーバー間でデータを転送できる速度。

ClusterControlには、物理​​バックアップを実装するためのさまざまな方法があります。どの方法を使用できるかは、クラスターの種類によって異なり、場合によってはベンダーによっても異なります。 ClusterControlによって実行されるXtrabackupを見てみましょう。これにより、テスト環境のデータの完全バックアップが作成されます。

今回はアドホックバックアップを作成しますが、ClusterControlでは完全なバックアップスケジュールも作成します。

ここでは、バックアップ方法（xtrabackup）とホストを選択します。からバックアップを取ります。ノードにローカルに保存することも、ClusterControlインスタンスにストリーミングすることもできます。さらに、バックアップをクラウドにアップロードできます（AWS、Google Cloud、Azureがサポートされています）。

バックアップが完了するまでに約10分かかりました。ここに、cmon_backup.metadataファイルからのログがあります。

​[[email protected] BACKUP-9]# cat cmon_backup.metadata 

{

    "class_name": "CmonBackupRecord",

    "backup_host": "192.168.33.14",

    "backup_tool_version": "2.4.21",

    "compressed": true,

    "created": "2020-11-17T23:37:15.000Z",

    "created_by": "",

    "db_vendor": "oracle",

    "description": "",

    "encrypted": false,

    "encryption_md5": "",

    "finished": "2020-11-17T23:47:47.681Z"

 }

次に、ClusterControlを使用して復元するために同じことを試してみましょう。 ClusterControl>バックアップ>バックアップの復元

ここでは、バックアップの復元オプションを選択します。これは、時間とログベースをサポートします。回復も。

ここでは、バックアップファイルのソースパスを選択してから、宛先サーバーを選択します。また、SSHを使用してClusterControlノードからこのホストにアクセスできることを確認する必要があります。

ClusterControlにソフトウェアをセットアップさせたくないので、そのオプションを無効にしました。復元後もサーバーは稼働し続けます。

10GBのデータを復元するのに約4分18秒かかりました。 Xtrabackupは、バックアッププロセス中にデータベースをロックしません。大規模なデータベース（100 GB以上）の場合、mysqldump/shellユーティリティと比較してはるかに優れた復元時間を提供します。また、私の同僚の1人が彼のブログで説明したようにlusterControlは部分的なバックアップと復元をサポートしています：部分的なバックアップと復元。

結論

各メソッドには独自の長所と短所があります。これまで見てきたように、あなたがしなければならないことすべてに最適な方法は1つではありません。実稼働環境とリカバリの目標時間に基づいてツールを選択する必要があります。