ClusterControlを使用してデータベースバックアップをスケジュールする方法

データベースのバックアップはデータベース管理の重要な部分であり、慎重に計画する必要があります。バックアップのスケジュールは十分ではありません。バックアップデータの整合性と整合性も検証する必要があります。暗号化やオフサイトでのアーカイブなど、他にも考慮事項があります。優れたバックアップマネージャには、これらのさまざまな考慮事項をすべて考慮に入れた機能があります。

このブログ投稿では、ClusterControlを使用してデータベースのバックアップをスケジュールする方法について説明します。

ClusterControlを使用したデータベースバックアップ

ClusterControlは、次の表に要約されているように、クラスターの種類に応じていくつかのバックアップ方法をサポートしています。

ClusterControlを使用してバックアップをスケジュールする場合、各バックアップ方法は、バックアップの実行方法に関する一連のオプションを使用して構成できます。さまざまなデータベースワークロードとバックアップ戦略では、さまざまな機能のサポートが必要になります。例：

• ディスクIOPSスロットリング
• ネットワークスロットリング
• バックアップロック
• 暗号化
• 圧縮
• 保持期間
• 確認

ClusterControlは、特定のデータベースベンダーのベストプラクティスに従って、いくつかのバックアップオプションを自動的に設定します。たとえば、ターゲットデータベースノードでバイナリログが有効になっている場合、追加のフラグ-master-dataが追加されます。 ダンプされたサーバーのバイナリログ座標（ファイル名と位置）を含めます。それがGaleraノードであり、バックアップ方法がxtrabackupの場合、ClusterControlは追加のフラグ-galera-infoを追加します。 これには、バックアップ時のローカルノードの状態が含まれます。

バックアップの計画

バックアップをスケジュールする前に、バックアップ操作をどのように行うかを計画する必要があります。バックアップスケジュールを作成する前に、次の質問例に答えておくと役に立ちます。

• どのバックアップ方法を使用しますか？一部のバックアップ方法は非ブロッキングですが、非常にリソースを消費します。トレードオフを理解しているので、プロセスが本番環境でどのように動作するかについて驚くことはありません。
• データベースをバックアップする頻度はどれくらいですか。バックアップ間隔が短すぎると、完全バックアップを実行するのが困難になる場合があります。おそらく、完全バックアップと増分バックアップを組み合わせる必要があります。
• データをどのくらいの速さで復元しますか？物理バックアップは通常、完全な復元時間の点で論理バックアップよりもはるかに高速です。一方、論理バックアップは通常、部分的な復元の方が高速です。
• データサイズはどれくらいですか？場合によっては、論理バックアップが巨大なデータベースに適していないことがあり、バイナリバックアップが唯一の方法です。
• バックアップを保存するために必要な空き容量はどれくらいですか？バックアップは多くのスペースを消費する傾向があります。圧縮が必要かどうか、および許容できる圧縮レベルを決定します。圧縮率を高めるには、CPU使用率を高くする必要があります。
• バックアップ時間中にバックアップサーバーがダウンした場合はどうなりますか？バックアップを別の利用可能なホストにフェイルオーバーする必要がありますか？通常、メンテナンスウィンドウのためにバックアップをスキップすることはお勧めできません。
• 作成したバックアップの整合性を確保するにはどうすればよいですか？復元できない場合、バックアップはバックアップではないことを忘れないでください。
• バックアップストレージを信頼しますか？データを保護するには、暗号化をお勧めします。

一般に、これらの質問に答えることで、適切なバックアップ戦略を立てることができます。バックアップと復元のポリシーによっては、質問のリストが長くなる可能性があります。

この章の詳細については、ホワイトペーパー「MySQLおよびMariaDBのデータベースバックアップに関するDevOpsガイド」で説明しています。

バックアップのスケジュール

ClusterControlを使用すると、スケジューリングは非常に簡単です。 [バックアップ]->[バックアップの作成]->[バックアップのスケジュール]に直接移動すると、次のダイアログが表示されます。

PostgreSQLとMongoDBの次のスクリーンショットに示すように、クラスタータイプに応じて、オプションが異なる場合があります。

ほとんどのオプションは自明であり、ユーザーガイドで詳細に説明されています。スケジュールが作成されると、[スケジュールされたバックアップ]タブで、構成バックアップの編集、バックアップの有効化/無効化、またはスケジュールの削除を行うことができます。

ClusterControlを使用してバックアップをスケジュールする場合は、すべての時間をClusterControlサーバーのUTCタイムゾーンでスケジュールする必要があることに注意してください。この背後にある理由は、バックアップ実行時間の混乱を遮断するためです。クラスタを使用する場合、データベースサーバーはさまざまなタイムゾーンとさまざまな地理的領域に分散する可能性があります。 1つの参照タイムゾーンを使用してそれらすべてを管理することで、バックアップが常に正しい時間に実行されるようになります。

時間が来たら、[アクティビティ]-> [ジョブ]を確認することで、バックアップの進行状況を監視できます。バックアップジョブが失敗した場合は、すぐにエラーが表示されます：

上記のログには、各バックアップエントリの[バックアップ]タブからもアクセスできます。

バックアップ後のチェックと検証

バックアップジョブが終了した後、それはあなたの責任が終わったことを意味するものではありません。フォローアップする必要があることがいくつかあります。最も重要なのは、作成されたバックアップの状態です。 ClusterControlは電子メール通知を提供し、ステータスについて通知します。もちろん、この通知サービスは、[設定]->[一般設定]->[電子メール通知設定]->[バックアップ：]の重大度に基づいて構成できます。

配信とは、このコンポーネントのアラームが発生した直後にClusterControlが電子メール通知を送信することを意味します。 ClusterControlが発生したアラームの毎日の要約を送信するIgnoreまたはDigestとして構成することもできます。

バックアップが正常に作成された場合は、バックアップが復元可能かどうかを確認することを強くお勧めします。選択したバックアップIDの[復元]ボタンをクリックしてバックアップ検証機能を使用すると、2つの復元オプションが表示されます。

「スタンドアロンホストでの復元と検証」には、データベース設定の一部ではない別のホストが必要です。 ClusterControlは、最初にターゲットホストにMySQLインスタンスをデプロイし、サービスを開始し、バックアップリポジトリからバックアップをコピーして、復元を開始します。完了したら、復元したサーバーをシャットダウンするか、サーバーを実行してサーバーをさらに調査できるようにするかを選択できます。

有用なバックアップのみをストレージに保持するためには、ハウスキーピングも重要です。したがって、必要に応じてバックアップの保持を構成します。デフォルトでは、ClusterControlは30日より古いバックアップをパージします。異なる保存期間で各バックアップスケジュールをカスタマイズすることもできます。

バックアップストレージがスペース制限に近づいている場合、またはバックアップをオフサイドでアーカイブする場合は、以下で強調表示されているように、ごみ箱アイコンをクリックしてファイルを手動で削除するか、クラウドにアップロードすることを選択できます。

執筆時点では、AWSS3とGCPCloudStorageがサポートされています。クラウドクレデンシャルは、[サイドメニュー]->[統合]->[クラウドプロバイダー]で事前に構成する必要があります。

それだけです、皆さん。ハッピークラスタリング！