以前は、MoodleMySQLデータベースのバックアップについてブログを書いていました。今回は、MoodleMariaDBデータベースのバックアップがすべてです。実際、Moodle MySQLデータベースをバックアップする場合、MoodleMariaDBデータベースと同じアプローチを共有します。ただし、MariaDB 10.2以降、徐々に逸脱し、MySQLバージョンとの大幅な違いが続いています。この点で、MariaDBからバックアップしている場合は、MySQLとは対照的に、MariaDBをバックアップするときに考慮しなければならない可能性のあるアプローチに注意してください。
では、これはどうしたのですか？ Moodleのバックアップを取るには、少なくとも以下のバックアップを行う必要があります：
- ポイントインタイム（インクリメンタル）リカバリ
データの論理バックアップは、SQLなどの人間が読める形式で保存されます。論理バックアップは、論理データベース構造（CREATE DATABASE、CREATE TABLEステートメント）およびコンテンツ（INSERTステートメントまたは区切りテキストファイル）として表される情報を保存します。このタイプのバックアップは、データ値やテーブル構造を編集したり、別のマシンアーキテクチャでデータを再作成したりする可能性のある少量のデータに適しています。巨大なデータベースバックアップを使用する傾向がある場合は、圧縮が有効になっていることを確認してください。これは特に多くのディスクスペースを必要とする可能性があるため、注意が必要です。
MariaDBでは、使用する一般的なツールはmysqldumpを使用していますが、MariaDB10.4.6または10.5.2以降のmariadb-dumpで将来変更される予定です。または、論理バックアップコピーの並列バックアップが必要な場合、MySQL /MariaDBDBAに使用する一般的なツールはmydumperです。一部のバージョンにはいくつかの問題がありますが、特に最新バージョンのMariaDBでは問題が発生する可能性があります。これを使用する場合は、コピーを作成するときにバックアップログに注意してください。
物理バックアップには、データベースの内容を格納するディレクトリとファイルの生のコピーで構成されるデータベースバイナリデータが含まれます。これは、特に大規模なデータベースに対して実行する適切なアクションであり、論理バックアップコピーと比較して、データベースの完全コピーを回復する方が高速です。一方、完全な物理バックアップの作成には、特に非常に大きなデータセットがある場合は時間がかかります。また、バックアップETAに影響を与える可能性のある有効化または設定したパラメータによっても異なります。
MariaDBに使用する一般的なツールは、mariabackupを使用することです。 Mariabackupは、MariaDBが提供するオープンソースツールです。これは、暗号化および圧縮されたテーブルで動作するように設計されたPercona XtraBackupのフォークであり、MariaDBデータベースに推奨されるバックアップ方法です。
ポイントインタイムリカバリ（PITR）
ポイントインタイムリカバリとは、特定の時点までのデータ変更のリカバリを指します。この特定の時点は、回復中に適用される、決定されて元の場所に戻す必要がある望ましい回復目標です。 PITRはポイントフォワードリカバリであり、MySQLサーバーでのMariaDBフラッシュバックの使用とは逆に、データを目的の開始時刻から希望の終了時刻に復元できることを意味します。 PITRは、重要な情報の損失を防ぐため、データ保護の追加の方法とも見なされます。
一般的な状況では、リカバリのタイプに適用できるPITRバックアップは、バックアップが作成された時点の状態にサーバーを戻す完全バックアップを復元した後に実行されます。次に、ポイントインタイムリカバリにより、サーバーは完全バックアップの時点からより新しい時刻まで段階的に最新の状態になります。また、MariaDBプライマリデータベースまたはアクティブライターデータベースに追いつくことから、レプリケーションクラスター内でのレプリカの構築を高速化します。
では、これらのバックアップは何ですか？ MariaDBでは、PITRに適用できる一般的なバックアップはバイナリログです。バイナリログは、MariaDBデータベースで適切に構成され、有効になっている必要があります。 ClusterControlを使用している場合は、自動的に構成され、特にレプリケーションクラスターをセットアップするときに有効になるため、構成が難しくない場合があります。
PITRを適用する場合、使用する最も一般的なツールは、MariaDB10.5.2以降のmysqlbinlogまたはmariadb-binlogです。
Moodle MariaDBデータベースを実行するときは、ピーク時以外の時間帯またはトラフィックが少なすぎるときに常にバックアップを取ります。これを行う前に、バックアップをテストし、正常に終了したことを確認してください。完了したら、バックアップが有用かどうか、およびデータリカバリが必要な場合、または別のクラスターのセット（QA、開発、または別のデータセンターへの拡張）を作成するためにバックアップが必要な場合に、バックアップがニーズを満たしているかどうかをテストします。基本的に、以下のサブセクションは、あなたが対処しなければならないアプローチとセットアップです。
レプリカをセットアップし、レプリカでバックアップを取ります
レプリケーションに慣れていない場合は、ホワイトペーパー「MySQLReplicationforHighAvailability」をお読みください。基本的に、バックアップを実行または実行するためにアクティブライターまたはプライマリデータベースノードを惜しまないでください。バックアップの作成はテストする必要があり、作成した一連のコマンドとそのバックアップポリシーでまだテストされていない場合は、本番環境で実行する必要はありません。うまくいったら、そのままにしてレプリカに向けます。選択の余地がない場合、または少なくとも自分が何をしているか確信がある場合は、プライマリ/マスターMariaDBデータベースからバックアップを取ることができます。
バックアップを実行するときは、それがピーク時間であることを確認してください。最新のデータがブラックアップされるように、レプリカは可能な限りゼロラグである必要があります。
バックアップポリシーは、バックアップが開始されるパラメータとスケジュールで構成されます。パラメータについては、セキュリティ、圧縮などのニーズが十分であることを確認してください。スケジュールは永続的である必要があるため、災害時に必要なときにバックアップがあり、データの回復が必要です。また、バックアップスケジュールを実行する頻度と時期を決定できるように、目標復旧時間も決定できます。
mariadb-dump/mysqldumpの使用
以下のコマンドは、Moodleのデータベースバックアップを作成します。この例では、データベース名はmoodleです。トリガー、ストアドプロシージャまたはルーチン、およびイベントが含まれています。プライマリまたはマスターデータベースノードからレプリカをプロビジョニングする場合に役立つGTIDとマスター情報を印刷します。
$ /usr/bin/mariadb-dump --defaults-file=/etc/my.cnf --flush-privileges --hex-blob --opt --master-data=2 --single-transaction --skip-lock-tables --triggers --routines --events --gtid --databases moodleMariaDBバージョン<10.5.2を使用している場合は、mariadb-dumpをmysqldumpに置き換えるだけです。圧縮する必要がある場合は、以下のコマンドを実行できます：
$ /usr/bin/mysqldump --defaults-file=/etc/my.cnf --flush-privileges --hex-blob --opt --master-data=2 --single-transaction --skip-lock-tables --triggers --routines --events --gtid --databases moodle |gzip -6 -c > /backups/backup-n1/mysqldump_2021-01-25_182643_schemaanddata.sql.gzmariabackupは簡単に実行できます。このために、必要なストリーミングおよびアーカイブ形式としてmbstreamを使用します。以下のコマンドを使用できます：
$ /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --parallel 1 --stream=xbstream > backup.xbstream圧縮する場合は、次のコマンドを実行できます。
$ /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --parallel 1 --stream=xbstream | gzip -6 - > backup.xbstream.gzClusterControlの使用
特にMoodleのバックアップを取るためにマネージドソリューションに切り替える場合、ClusterControlはそれをシンプルでありながらバックアップを取るための高度な機能を提供します。以下のスクリーンショットをご覧ください：
バックアップの作成は非常に簡単で、簡単に作成できます。 <クラスターの選択>→バックアップ→バックアップの作成
に移動するだけです。上のスクリーンショットには、mysqldump、PITR互換のmysqldump、およびmariabackupがあります。バックアップを取るホストを選択できます。前述のように、レプリカまたはスレーブでバックアップを取っていることを確認してください。つまり、スレーブが選択されていることを確認してください。以下のスクリーンショットを参照してください：
mysqldumpを選択または選択する際、ClusterControlではユーザーが次のタイプを選択できます。ダンプされるデータ。これには、バックアップ用のPITR互換ダンプも含まれます。以下のスクリーンショットを参照してください：
バイナリまたは物理バックアップの場合、論理バックアップとしてのmysqldumpは別として、 mariabackupは、フルまたはインクリメンタルのいずれかを選択できます。以下を参照してください：
保存場所では、ユーザーはノードにとどまるか、ノードにとどまるかを選択できます。 ClusterControlホストにストリーミングします。 ClusterControlに登録されていない外部サーバーがある場合は、NFSを使用して、バックアップをダンプするボリュームをマウントできます。これは理想的ではないかもしれませんが、場合によっては、特にネットワーク帯域幅またはネットワーク転送がネットワーク経由で他のノードにデータをローカルにストリーミングするのに十分な速さである場合に満たされます。
基本的に、クラウドにアップロードするバックアップを選択できます。前にスクリーンショットを表示し、チェックボックスをオンにして次のように有効にします。
前述のように、ClusterControlはバックアップを簡単に使用できますが、高度な機能。設定できるオプションは次のとおりです。
mysqldumpの場合、
mariabackupの場合、
Moodle MariaDBデータベースのバックアップは簡単ですが、データが大きくなり、トラフィックが増えると、大きな課題になる可能性があります。ベストプラクティスに従い、データが保護されていることを確認し、バックアップが検証されていることを確認する必要があります。これは、データリカバリを適用する必要がある場合に役立ちます。