災害は通常、停止を引き起こします。これは、システムのダウンタイムとデータの潜在的な損失を意味します。停電を検出したら、DR計画をトリガーして停電から回復します。しかし、バックアップがない場合、または長時間のリカバリの後、それが必要なものではないことがわかる場合は、驚きです。
停止にはコストがかかる可能性がありますが、多くの場合、ビジネスに悪影響を与える可能性のある経済的影響があり、データの損失が会社を閉鎖する理由になる可能性があります。
データの損失を最小限に抑えるには、さまざまな場所にデータの複数のコピーを用意する必要があります。インフラストラクチャをさまざまなレイヤーで設計し、その下のレイヤーから各レイヤーを抽象化できます。たとえば、ハードウェア障害から保護するために、データベースインスタンスのクラスター用のレイヤーを構築します。データセンター間でデータベースを複製するため、データセンターの障害から身を守ることができます。レイヤーを追加するたびに複雑さが増し、管理が悪夢になる可能性があります。しかし、それでも、本質的には、バックアップがディザスタリカバリの中心的な位置を占めます。
そのため、信頼できるものであることを確認することが重要です。しかし、これを達成する方法は？オプションの1つは、バックアップスクリプトの最後の数行に基づいてバックアップが実行されたかどうかを確認することです。
簡単な例：
#!/bin/sh
mysqldump -h 192.168.1.1 -u user -ppassword dbname > filename.sql
if [ "$?" -eq 0 ]; then
echo "Success."
else
echo "Error."
fiしかし、バックアップスクリプトがまったく開始されなかった場合はどうなりますか？ Googleは、「Linux cron、実行されていません」の検索結果をかなり提供しています。
残念ながら、オープンソースデータベースはバックアップリポジトリを提供しないことがよくあります。
この記事では、ClusterControlを使用してバックアップが確実に実行され、オープンソースデータベースでエンタープライズグレードのデータベースを実現する方法について説明します。
ClusterControlは、運用レポートを対象としています。オペレーショナルレポーティングは、日々の企業活動の監視と制御をサポートします。バックアップレポートは多くのレポートの1つです。次のようなレポートを見つけることができます：
しかし、なぜこれが必要になるのでしょうか。
考えられるすべてのメトリック/グラフを備えた優れた監視ツールがすでにある可能性があり、メトリックとしきい値に基づいてアラートを設定している可能性があります（自動アドバイザーが推奨事項を提供したり、自動的に修正したりする場合もあります）。システムは重要です。それでも、多くの情報を処理できる必要があります。
これはどのように機能しますか？ ClusterControlは、バックアップジョブがトリガーされたときに、バックアッププロセス、システム、プラットフォーム、およびバックアップインフラストラクチャ内のデバイスに関する情報を収集します。その情報はすべて集約されてCMON（内部データベース）に格納されるため、特定のデータベースに追加でクエリを実行する必要はありません。さらに、実行中のクラスターがあることを検出したが、バックアップがなかった場合は、それも報告されます。
レポートの詳細では、場所、サイズ、時間、バックアップ方法に関する詳細データを含むバックアップIDを追跡できます。テンプレートはさまざまなデータベースタイプのデータで機能するため、混合環境を管理する場合、同じ感触と外観が得られます。さまざまなデータベースのバックアップをより適切に管理するのに役立ちます。
CLIレポート
コマンドラインインターフェイスを好む人のために、バックアップを追跡するための良いオプションClusterControlコマンドラインインターフェイス（CLI）。
CLIを使用すると、簡単なコマンドを使用してClusterControl内で使用できるほとんどの機能を実行できます。バックアップ実行とバックアップレポートはその1つです。
強力なGUIと組み合わせて使用すると、ClusterControlユーザーは、好みのエンジンを使用してオープンソースデータベース環境を管理するための代替方法を利用できます。
$ s9s backup --list --cluster-id=1 --long --human-readable
ID CID STATE OWNER HOSTNAME CREATED SIZE FILENAME
1 1 COMPLETED dba 10.0.0.5 07:21:39 252K mysqldump_2017-05-09_072135_mysqldb.sql.gz
1 1 COMPLETED dba 10.0.0.5 07:21:43 1014 mysqldump_2017-05-09_072135_schema.sql.gz
1 1 COMPLETED dba 10.0.0.5 07:22:03 109M mysqldump_2017-05-09_072135_data.sql.gz
1 1 COMPLETED dba 10.0.0.5 07:22:07 679 mysqldump_2017-05-09_072135_triggerseventsroutines.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:20 252K mysqldump_2017-05-09_073016_mysqldb.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:24 1014 mysqldump_2017-05-09_073016_schema.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:44 109M mysqldump_2017-05-09_073016_data.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:49 679 mysqldump_2017-05-09_073016_triggerseventsroutines.sql.gzバージョン1.4.1以降、インストーラースクリプトはこのパッケージをClusterControlノードに自動的にインストールします。 CLIはs9s-toolsパッケージの一部です。別のマシンに個別にインストールして、データベースクラスターをリモートで管理することもできます。 ClusterControlと同様に、安全なSSH通信を使用します。
データを取得できない場合、バックアップはバックアップではありません。バックアップの検証は、多くの企業が通常見落としていることです。 ClusterControlがバックアップの検証を自動化し、予期しない事態を回避する方法を見てみましょう。
ClusterControlで、クラスターを選択し、[バックアップ]セクションに移動してから、[バックアップの作成]を選択します。
自動検証バックアップ機能は、スケジュールされたバックアップで使用できるため、選択しましょう「バックアップのスケジュール」オプション。
バックアップをスケジュールするときは、方法やストレージなどの一般的なオプションを選択するだけでなく、スケジュール/頻度も指定する必要があります。この例では、MySQLバックアップ検証をセットアップします。ただし、PostgreSQLおよびTimescaleデータベースでも同じことが実現できます。
バックアップの確認をオンにすると、別のタブが表示されます。
ここでは、環境を準備するために必要なすべての手順を設定できます。 IPが提供されたら、そのようなバックアップをスケジュールしてください。バックアップが完了すると、一時的なバックアップ検証環境にコピーされます（「バックアップを復元する」オプション）。更新が成功すると、[バックアップリポジトリ]タブに確認のステータスが表示されます。
バックアップの実行に関するより多くの手がかりを得るためのもう1つの興味深いオプションは、ClusterControl統合サービスを使用することです。サードパーティのサービスを使用して、バックアップの実行ステータスを制御できます。
サードパーティツールの統合により、他の一般的なシステムとのアラートを自動化できます。現在、ClusterControlは、ServiceNow、PagerDuty、VictorOps、OpsGenie、Slack、Telegram、およびWebhookをサポートしています。
以下に、Slackチャネル統合の例を示します。バックアップイベントが発生するたびに、それはスラックチャネルに表示されます。
どの環境でもバックアップは必須です。これらはデータの保護に役立ち、あらゆる災害復旧シナリオの中心にあります。 ClusterControlは、データベースのバックアッププロセスを自動化し、障害が発生した場合に数回クリックするだけでデータベースを復元するのに役立ちます。また、それらが正常に実行され、信頼できることを確認できるため、災害が発生した場合でもデータが失われることはありません。