ClusterControlの中核となるのは自動化であり、データが安全にバックアップされ、問題が発生した場合に復元できるようになります。効果的なバックアップ戦略とディザスタリカバリ計画を立てることは、あらゆるアプリケーションや環境を成功させるための鍵です。
最新のリリースであるClusterControl1.5では、MySQLおよびMariaDBベースのシステムをバックアップするための多くの拡張機能が導入されています。
主な改善点の1つは、ClusterControlから選択したクラウドプロバイダーにバックアップする機能です。 Google CloudServicesやAmazonS3などのクラウドプロバイダーはそれぞれ、実質的に無制限のストレージを提供し、ローカルスペースのニーズを削減します。これにより、ローカルディスクスペースを気にせずに必要な限り、バックアップファイルをより長く保持できます。
ClusterControl1.5のエキサイティングな新しいバックアップ機能をすべて調べてみましょう...
バックアップ/復元ウィザードの再設計
まず、ユーザーエクスペリエンスを向上させるために、バックアップウィザードと復元ウィザードが改良されていることに気付くでしょう。画面の右側にサイドメニューとして読み込まれます：
バックアップリストも微調整されており、特定のバックアップをクリックするとバックアップの詳細が表示されます。
バックアップの場所と、バックアップ内にあるデータベースを表示できます。バックアップを復元したり、クラウドにアップロードしたりするオプションもあります。
PITR互換バックアップ
ClusterControlは、個別のスキーマダンプとデータダンプを使用して標準のmysqldumpバックアップを実行します。これにより、部分的なバックアップを簡単に復元できます。ただし、バックアップの整合性が損なわれるため（スキーマとデータは、2つの別々のセッションにダンプされます）、スレーブまたはポイントインタイムリカバリのプロビジョニングには使用できません。
mysqldump PITR互換のバックアップには、GTID情報、binlogファイル、および位置を含む1つのダンプファイルが含まれています。したがって、以下のスクリーンショットで強調表示されているように、バイナリログを生成するデータベースノードのみが「PITR互換」オプションを使用できます。
PITR互換オプションを切り替えると、ClusterControlは常にターゲットMySQLサーバーのすべてのデータベース、イベント、トリガー、およびルーチンに対してバックアップを実行するため、データベースとテーブルのフィールドはグレー表示されます。
完成したダンプファイルの最初の約50行に次の行が表示されます。
$ head -50 mysqldump_2017-11-07_072250_complete.sql
...
-- GTID state at the beginning of the backup
--
SET @@GLOBAL.GTID_PURGED='20dc5247-4a98-ee18-73af-5c79373388ee:1-1681';
--
-- Position to start replication or point-in-time recovery from
--
CHANGE MASTER TO MASTER_LOG_FILE='binlog.000001', MASTER_LOG_POS=2457790;
...この情報を使用して、バックアップからスレーブを構築したり、バイナリログと一緒にポイントインタイムリカバリを実行したりできます。この場合、「mysqlbinlog」ユーティリティを使用して、ダンプファイルで報告されたMASTER_LOG_FILEおよびMASTER_LOG_POSからリカバリを開始できます。バイナリログはClusterControlによってバックアップされないことに注意してください。
バックアップからスレーブを構築するもう1つの機能は、選択したマスターからではなく、PITR互換のバックアップから直接スレーブを構築する機能です。これは、マスターサーバーの負荷を軽減するための大きな利点です。このオプションは、MySQLレプリケーションまたはGaleraクラスターで使用できます。次のスクリーンショットに示すように、既存のバックアップを使用して、ステージングフェーズ中に既存のレプリケーションスレーブを再構築したり、新しいレプリケーションスレーブを追加したりできます。
ステージングが完了すると、スレーブは選択されたマスターに接続し、追いつき始めます。以前は、ClusterControlは、Percona Xtrabackupを使用して、選択したマスターから直接ストリーミングバックアップを実行していました。これは、操作がマスターで非ブロッキングであるにもかかわらず、大規模なデータセットをスケールアウトするときにマスターのパフォーマンスに影響を与える可能性があります。新しいオプションでは、バックアップがClusterControlに保存されている場合、スレーブでデータをステージングするときに、これらのホスト（ClusterControl +スレーブ）のみがビジーになります。
クラウドへのバックアップ
バックアップをクラウドに自動的にアップロードできるようになりました。これには、 clustercontrol-cloudと呼ばれるClusterControlモジュールをインストールする必要があります （クラウド統合モジュール）および clustercontrol-clud （クラウドダウンロード/アップロードCLI）v1.5以降で利用可能です。アップグレード手順はこれらのパッケージに含まれており、追加の構成は含まれていません。現在、サポートされているクラウドプラットフォームは、AmazonWebServicesとGoogleCloudPlatformです。クラウドクレデンシャルは、ClusterControl->設定->統合->クラウドプロバイダーで構成されます。
バックアップを作成またはスケジュールするときに、[バックアップをクラウドにアップロード]を切り替えると、次の追加オプションが表示されます。
この機能を使用すると、1回限りのアップロード、または完了後にバックアップをアップロードするようにスケジュールできます（AmazonS3またはGoogleCloud Storage）。その後、必要に応じてバックアップをダウンロードして復元できます。
mysqldumpのカスタム圧縮
この機能は、実際、ClusterControlv1.4.2のリリース後に最初に導入されました。 gzipに基づくバックアップ圧縮レベルを追加しました。以前は、バックアップ先がコントローラーノードにある場合、ClusterControlはデフォルトのバックアップ圧縮（レベル6）を使用していました。バックアップ先がデータベースホスト自体にある場合は、圧縮操作中のデータベースへの影響を最小限に抑えるために、最も低い圧縮（レベル1-最速、より少ない圧縮）が使用されました。
このバージョンでは、圧縮の側面が洗練されており、バックアップ先に関係なく、圧縮レベルをカスタマイズできるようになりました。 ClusterControlインスタンスをアップグレードすると、v1.5で明示的に編集しない限り、スケジュールされたすべてのバックアップが自動的にレベル6を使用するように変換されます。
データセットが大きく、長いバックアップ保持ポリシーと組み合わされ、ストレージスペースが限られている場合、バックアップの圧縮は非常に重要です。テキストベースのMysqldumpは、元のファイルサイズのディスクスペースを最大60％節約して、圧縮の恩恵を受けることができます。場合によっては、最高の圧縮率が最適なオプションですが、復元時の解凍時間が長くなります。
ボーナス機能：自動バックアップ検証
古いシステム管理者が言うように、バックアップは復元可能でなければバックアップではありません。バックアップ検証は、通常多くの人に無視されているものです。一部のシステム管理者は、このための社内ルーチンを開発しました。通常、自動化よりも手動です。ホストのプロビジョニング、MySQLのインストールと準備、バックアップファイルの転送、解凍、復元操作、検証手順、そしてプロセス後のシステムのクリーンアップなど、操作全体が複雑であるため、自動化は困難です。これらすべての面倒は、人々に信頼できるバックアップのそのような重要な側面を無視させます。一般に、バックアップ復元テストは、少なくとも月に1回、またはデータサイズやデータベース構造に大幅な変更があった場合に実行する必要があります。自分に合ったスケジュールを見つけて、スケジュールされたイベントで形式化します。
ClusterControlは、上記の検証手順を損なうことなく、新しいホストで復元を実行することにより、バックアップ検証を自動化できます。これは、少し遅れて、またはバックアップが完了した直後に実行できます。復元操作の終了コードに基づいてバックアップステータスを報告するか、バックアップが確認された場合は自動シャットダウンを実行するか、復元されたホストを実行してデータに対して追加の手動確認を実行します。
バックアップを作成またはスケジュールするときに、[バックアップの確認]が切り替えられている場合は、追加のオプションがあります。
「データベースソフトウェアのインストール」が有効になっている場合、ClusterControlはターゲットホスト上の既存のMySQLインストールをすべて削除し、既存のMySQLサーバーと同じバージョンでデータベースソフトウェアを再インストールします。それ以外の場合、復元されたホストに特定の設定がある場合は、このオプションをスキップできます。残りのオプションは自明です。
ボーナス機能：PostgreSQLを忘れないでください
MySQLとMariaDBのこの優れた機能に加えて、ClusterControl 1.5は、オンラインバイナリバックアップに使用できる追加のバックアップメソッド（pg_basebackup）をPostgreSQLに提供するようになりました。 pg_basebackupで作成されたバックアップは、後でポイントインタイムリカバリに使用したり、ログ配布またはストリーミングレプリケーションスタンバイサーバーの開始点として使用したりできます。
今のところ以上です。 ClusterControl v1.5を試してみて、新機能を試してみて、ご意見をお聞かせください。