あらゆる状況であらゆる種類のデータ損失を防ぐための重要な部分は、適切なバックアップおよびリカバリポリシーを用意することです。また、アプリケーションワークフローのライフサイクルの任意の時点でデータを確実に回復することも不可欠です。 MySQLとMariaDBはどちらも、これらのケースに対するソリューションを提供します。この記事では、MySQLとMariaDBの既存のオプションと手順、およびその他の潜在的なバックアップオプションについて説明します。
バックアップ戦略
データはあらゆるアプリケーションの最も重要な部分であるため、その整合性を保護することは、存在の戦いで生き残るために不可欠です。いつでもデータのアクセス可能性や整合性が損なわれると、アプリケーションとそれが提供するビジネス/サービスに深刻な損害を与える可能性があります。
アプリケーションワークフローとビジネスの継続性を確実に成功させるには、日次、週次、月次、および年次のバックアップを使用して、適切なバックアップおよびリカバリポリシーを実装する必要があります。このようなバックアップは、次のような重要な時期に実行されます。
- 毎日のバッチウィンドウの前;
- 大量のデータを取り込む前;
- アプリケーションのアップグレード前;
- 規制要件を満たすための毎週、毎月、および毎年のバックアップ。
- またはその他の毎日/毎週の定期メンテナンス。
バックアップツール
MySQLとMariaDBは、バックアップとリカバリの計画を設定して実行するためのいくつかの方法を提供します。これらの方法には、MySQLのEnterprisemysqlbackupツールを使用した物理バックアップが含まれます。 、MariaDBのmariabackupツール 、またはPerconaのXtraBackupツール 。また、Mysqlのmysqldumpツールで作成された論理バックアップ 重宝するかもしれません。もう1つのオプションは、前述のツールと組み合わせたデータベースのbin-logs（トランザクションログ）を使用したポイントインタイムリカバリです。
障害や災害が発生した場合にデータベースの回復可能性を最大化するために、適切な方法をバックアップ戦略に取り入れることができます。
注：MariaDBバージョン10.4.6では、mysqldumpのsymlink mariadb-dumpと呼ばれます 。 10.5.2を含むそれ以降のバージョンでは、名前が再び変更されました– mysqldump シンボリックリンクになりました 。
手順を説明するために、mariabackupツールを使用します。 物理バックアップを作成します。ツールの基本的な機能は前述のツールと同じですが、ツールごとに若干の違いがあります。
物理データベースのバックアップ
物理バックアップはファイルレベルのバックアップであり、ファイルの高速コピー方法を提供します。このようなバックアップは、ディザスタリカバリのシナリオ、データベースのクローン作成、および/またはスレーブデータベースの作成に適しています。
物理バックアップを作成する場合、完全バックアップまたは増分バックアップの作成を選択できます。完全バックアップには、データベースサーバーの完全バックアップが含まれます。増分バックアップは、最後の完全バックアップまたは増分バックアップからの変更のみを保存します。
重要：データベースのサイズによって、バックアップの時間が調整されます。そのため、非常に大規模なデータベースをバックアップするための適切な戦略は、完全バックアップと増分バックアップを組み合わせることです。このようにして、バックアップのストレージスペースと、バックアップとリカバリの合計時間の両方を節約できます。
もう1つの注意すべき点は、物理バックアップからデータをリカバリする場合、最終的なリカバリ手順が完了するまで、MySQL/MariaDBデータベースインスタンスプロセスを停止する必要があることです。
次のように、単純な完全物理バックアップの実行を実行できます。
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220 \
--user=backupuser --password=backuppasswd
–target-dir オプションは、バックアップツールにバックアップを配置する場所を指示します。
この例では、バックアップを DYYYYMMDDというディレクトリに整理しました。 各完全バックアップが保存される場所（DはDailyを表します）。そうすることで、特定の日付に作成されたバックアップからデータベースを復元するための簡単なアクションがあります。
次の例は、単純な増分バックアップの実行を示しています。
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220_inc1/ \
--incremental-basedir=/data/backups/mariadb/D20210220/ \
--user=backupuser --password=backuppasswd
後続の増分バックアップは、次のようになります。
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220_inc2/ \
--incremental-basedir=/data/backups/mariadb/D20210220_inc1 \
--user=backupuser --password=backuppasswd
–インクリメンタルベースのir オプションは、現在のバックアップの増分デルタファイルを作成する際の開始点として、以前に取得した完全バックアップまたは増分バックアップを使用するようにバックアップツールに指示します。このようにして、1つの完全バックアップとそれに続く増分バックアップのチェーンを構築します。これらが一緒になって、必要なときに復元する単一のバックアップを形成します。
それでは、すべてのディレクトリデータが保存されている物理データベースファイルの名前を調べてみましょう。ドメインコントローラにあるデータベースはActiveDirectoryです。このディレクトリは、ユーザーやデータなどを管理するために使用されます。ActiveDirectoryのコアは、リンク、セキュリティ記述子、およびデータテーブルで構成されるNTDS.DITデータベースファイルです。すべてのディレクトリデータは、この物理データベースファイルに保存されます。
物理ファイルと論理ファイルを区別する必要があります。実際のシステムデータは物理ファイルにありますが、論理ファイルには物理ファイルに保存されているレコードの説明が含まれています。
物理ファイルからMySQLデータベースを復元する作業は難しい場合があります。 mysqldump この場合、コマンドが役立つ場合があります。このトピックについてはさらに詳しく説明します。
論理データベースのバックアップ
論理バックアップは、 mysqldumpを使用して作成されます 道具。このバックアップ方法は、物理バックアップよりも柔軟性があります。これは、一貫性のあるバックアップを形成するために必要なすべてのDMLおよび/またはDDL SQLステートメントで構成され、バックアップ前およびバックアップ中に行われたすべてのコミットされたデータと変更を組み合わせます。すべてのデータベースをバックアップおよび復元する方法について詳しく知りたい場合は、この記事を読むことができます。
論理バックアップは、単一のファイルまたは複数のファイル（特定のスクリプトで作成）にすることができます。さらに、MySQL / MariaDBインスタンス（プロセス）をシャットダウンせずに、構造やデータを復元できます。したがって、論理バックアップはデータベースやテーブルレベルで実行され、物理バックアップはファイルシステムレベル（ディレクトリとファイル）で実行されます。
論理バックアップは、目的のデータベースやテーブルの完全バックアップイメージのみであることに注意してください。
MySQL/MariaDBインスタンス全体の論理バックアップを作成する方法は次のとおりです。
mysqldump --all-databases --single-transaction \
--quick --lock-tables=false \
-u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/full-backup-$(date +'%Y%m%d_%H%M%S').sql
物理バックアップと論理バックアップは、バックアップ管理の目的でファイルシステム内で明確に区別されていることに注意してください。
前の例とは異なり、単一のデータベース（スキーマ）の論理バックアップは次の方法で作成されます。
mysqldump empdb --single-transaction \
--quick --lock-tables=false \
-u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/empdb-full-backup-$(date +'%Y%m%d_%H%M%S').sql
最後に、データベース内の単一のテーブルの論理バックアップを作成するには、データベースの後にテーブルの名前を追加します。
mysqldump empdb departments --single-transaction \
--quick --lock-tables=false \
-u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/empdb-departments-full-backup-$(date +'%Y%m%d_%H%M%S').sql
DROPDATABASEまたはDROPTABLEステートメントを編集してリカバリシナリオに追加する必要がある場合、大きなバックアップファイルを操作すると、テキストエディタが窒息するほどの影響を与える可能性があります。
このような場合は、 –add-drop-databaseなどの他のオプションを追加することを検討してください。 および/または–add-drop-table これらのDROPステートメントをバックアップに含めます。他のシナリオでは、これらのステートメントを除外して、 –skip-add-drop-tableに置き換えることができます。 コマンドのオプション。
ただし、 –no-create-info を使用して、データのみまたはDDLのみのバックアップを作成することもできます。 または–no-data オプション。一部のリカバリシナリオでは、特に空のクローンデータベースやそのテーブルを作成するためにDDL構造のみが必要な場合は、データと構造の個別のバックアップを選択することをお勧めします。
ディスクスナップショットを使用したデータベースのバックアップ
データが大きくなるにつれて、複数のディスクやファイルシステムでデータを整理する必要が生じる場合があります。パフォーマンス上の理由に加えて、I / Oは複数のディスク/ファイルシステムに分散されているため、効率的なバックアップおよびリカバリ戦略にディスクおよびファイルシステムのスナップショット機能が含まれていることを確認する必要があります。
まず、各データベース、テーブルのグループ、およびインデックスが存在するファイルシステムレイアウトを設計および構築します。次に、テーブルを整理し、データベースシステムを構成します。それらはすべて単一のディレクトリに存在する必要があります：
innodb_home_dir = /<path where your InnoDB tables will reside>または、 DATA_DIRECTORYを使用することもできます およびINDEX_DIRECTORY CREATEのオプション それらを別々のファイルシステムの場所に配布するためのテーブルステートメント。
InnoDBの場合は、必ず file_per_table =ONを使用してください。 （最新バージョンではデフォルトでオン）。 InnoDBテーブルを作成するときは、それらのパスを慎重に選択してください。テーブルを削除して再作成せずにパスを変更することはできません。
スナップショット機能が組み込まれた適切なファイルシステムがあると便利です。 Linux上のXFSおよびZFS。スナップショットバックアップの作成は物理バックアップの作成と似ていますが、特殊性があることに注意してください。書き込みプロセスを停止する必要があります（ READLOCKを使用したFLUSH または同様のもの—バックアップステージを参照してください スナップショットを取り、 LOCKS を解放する前に、MariaDBオンラインドキュメントのコマンド） スナップショットの完了直後。データの一貫性を確保する必要があります。
災害復旧シナリオでは、スナップショットバックアップを検討して使用する必要があります。ただし、データベースインスタンスのクローン作成にも適しています。
回復戦略
物理バックアップからのリカバリ
以前、物理的なバックアップ手順について説明しました。このようにして、完全バックアップのチェーンまたは完全バックアップと増分バックアップのチェーンのいずれかを構築できます。後者のオプションは、障害が発生した場合、完全バックアップとそれに続く増分バックアップがポイントゼロになることを意味します。
たとえば、DBAは日曜日に完全バックアップを取り、他の日に増分バックアップを取ります。水曜日に増分バックアップを作成した後、障害が発生します。したがって、データベースを復元する必要があります。このような状況では、DBAは日曜日に作成された完全バックアップと、月曜日、火曜日、および水曜日に作成された増分バックアップを使用する必要があります。毎日完全バックアップがあった場合は、水曜日のバックアップを復元するだけで十分です。
障害後に「最も近い」バックアップを回復するには、それが完全バックアップであろうと増分バックアップであろうと、すべてのバックアップファイルが特定の時点で一貫していることを確認する必要があります。 最も近いバックアップ終了の時間で。それ以外の場合、InnoDBエンジンは、データが破損していると見なしてデータを拒否します。
もう1つの重要なポイントは、バックアップを準備するときに、関連する完全バックアップを別の場所にコピーすることです。 ポイントインタイムの一貫性を確保するための手順を適用する前に。このようにして、元のバックアップ状態を保持します。これは後で便利になる場合があります。このアプローチに固執することを強くお勧めします。
完全バックアップを準備するには、障害に最も近いバックアップを選択し、それを適切な場所にコピーして、次のコマンドを実行します。
mariabackup --prepare \
--target-dir=data/backups/mariadb/COPY_D20210220
最も近い増分バックアップに復元するには、 最も近い完全バックアップのコピーを準備し、関連するすべての増分バックアップを追加します 次の順序で 。復元されたデータベースイメージは次のようになります。
これは、 prepareを実行することで実現します。 以下に示すように、各増分バックアップのコマンド：
mariabackup --prepare \
--target-dir=/data/backups/mariadb/COPY_D20210220 \
--incremental-dir=/data/backups/mariadb/D20210220_INC#
バックアップコピーを準備したら、データベースインスタンスをシャットダウンする必要があります。 （処理する）。また、空にする必要があります データベースディレクトリ 復元プロセスを終了する前に。 –copy-backを使用してコマンドを発行できます オプション
mariabackup --copy-back \
--target-dir=data/backups/mariadb/COPY_D20210220
または–move-back オプション：
mariabackup --move-back \
--target-dir=data/backups/mariadb/COPY_D20210220
後者のコマンドは、コピーされたディレクトリをデータベースディレクトリに移動します。元のバックアップを別の場所にコピーすることは賢明な選択です。そうしないと、バックアップが失われ、他の状況やシナリオで使用できなくなります。
データベースインスタンスを開始する前の最後の手順は、ユーザーとプロセス所有者のグループに一致するようにファイルの所有権を調整することです。通常、これはMySQLです。
論理バックアップからのリカバリ
論理バックアップを使用してデータベースやテーブルをリカバリする場合、1つの重要なポイントを見落とすことがよくあります。このポイントは、 max_allowed_packetを設定することです セッションのサイズ（グローバルに設定する方が賢明かもしれません）を最大値1073741824に設定します。大きなバッファーとINSERTステートメントがクライアントとサーバー間の単一のパケットに収まるようにする必要があります。これにより、回復時間が短縮されます。
バックアップを作成する際のもう1つの重要な側面は、前述のようにDROPステートメントを含めるか除外することです。バックアップ復元プロセスを可能な限りスムーズに実行するために必要です。そのことを念頭に置いて、以下のコードを使用してバックアップ復元を実行します。
mysql -u backupuser -p backuppasswd < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sql個々のデータベースのバックアップのように、バックアップにデータベースが含まれていない場合、または復元を別のデータベースにリダイレクトする必要がある場合は、別のコードを使用してください。
mysql -u backupuser -p backuppasswd newemp < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sqlディスクスナップショットによるリカバリ
ディスクスナップショットから回復するには常に 最初に確認 データベースシステムがシャットダウンする前に リカバリプロセスが実行されます 。ディスクスナップショットを使用してライブデータベースを回復しようとすると、データの不整合が発生し、データが破損する可能性が高くなります。
ポイントインタイムリカバリ
ポイントインタイムリカバリ（PITR）は、その名前が示すように、障害が発生する前の時間にできるだけ近い時間にデータベースとテーブルをリカバリする方法です。または、毎日のバッチプロセスが失敗し、再実行する必要がある場合は、PITRバックアップリカバリを実行するという唯一のオプションもあります。
データベースで実行しているワークロードのタイプに応じて、データベースのbin-logを有効にし、bin-log形式をステートメントベース、行ベース、または混合ログのいずれかに設定することが重要です。さらに、 log_bin_compress =ON（デフォルトはOFF）を使用して圧縮を有効にする必要がある場合があります。 ディスクスペースを節約します。
bin-logはトランザクションログであり、順番に作成されるため、すべてのログファイルのバックアップを作成することが重要です。 PITRプロセスに関しては、不可能です。 ログファイルなし。さらに、bin-logの保守とライフサイクルは、完全バックアップと増分バックアップのライフサイクルに従う必要があります。したがって、バックアップポリシーで最も古いバックアップよりも古いログのみを削除するようにしてください。
バイナリログは2つの方法でパージできます。まず、以下のパージコマンドに示すように、最も古いバックアップに最も近いbin-log名を宣言します。
PURGE BINARY LOGS TO 'mariadb-bin.000063';次に、パージコマンドで保持されている最も古いバックアップの日付を宣言します。
PURGE BINARY LOGS BEFORE '2021-01-20 00:00:00';回復の準備をするには、必要な時点まで再生するために必要なすべてのステートメントを取得する必要があります。バックアップが開始されてから回復する時点までに利用可能なすべてのbinログを収集します。
バックアップが終了してからPITR時間までのログリストを調べることから始めます。
mysqlbinlog --start-datetime=<backup end datetime> --stop-datetime=<PITR datetime> \
<list of binlogs> \
> temporary_file.sql
次に、一時ファイルを調べて、適用および使用する正確なログ位置を見つけます。これらは–start-position および–stop-position コマンドの正確な位置を設定し、 mysqlbinlogを再実行します。 コマンド：
mysqlbinlog --start-position=<exact log start position> --stop-position=<exact log position to stop on> \
<list of binlogs> \
> final_temporary_PITR_file.sql
この時点で、回復プロセスが開始されています。フルバックアップまたはインクリメンタルバックアップのいずれかを使用します。
final_temporary_PITR_file.sql を適用して、リカバリを終了します 以下に示すようにMySQLクライアントを使用します：
mysql -u backupuser -p backuppasswd < final_temporary_PTR_file.sqlバックアップと再生されたトランザクションをログから障害発生の瞬間に最も近いポイントに復元することで、PITRリカバリを完了しました。
ワークベンチ
MySQLとMariaDBでのデータベースの設計と開発、テスト、およびメンテナンスには、WindowsアプリケーションWorkbenchを使用できます。 Linuxでも動作します。このアプリケーションを使用すると、ユーザーはデータベースの設計、メタデータの表示と変更、データとメタデータの転送などを行うことができます。 Workbenchの代わりにdbForgeStudioforMySQLを使用できることを追加する価値があります。
結論
全体として、MySQLとMariaDBで利用可能なツールとメソッドを使用したデータベースのバックアップとリカバリの手法について簡単に説明し、説明しました。
障害からデータベースシステムを正常に回復するには、物理バックアップと論理バックアップの両方を実装する必要があります。 システム全体から個々のテーブルに至るまで、ポリシーと計画に上記の方法を取り入れます。
PITRを正常に実行するには、bin-logを有効にして適切なログ管理が必要が必要です。 所定の位置にあります。
ただし、1つのバックアップ方法のみを使用し、bin-logが欠落していると、間違ったアプローチになります。データが失われ、アプリケーションのビジネスの継続性が損なわれる可能性があります。したがって、さまざまな方法を組み合わせて、常にログファイルをバックアップおよび復元ポリシーに含めてください！