ブログシリーズの過去4回の投稿では、クラスタリング/レプリケーション（MySQL / Galera、MySQLレプリケーション、MongoDBとPostgreSQL）の展開、既存のデータベースとクラスターの管理と監視、パフォーマンスの監視と正常性について説明しました。最後の投稿では、 HAProxyとProxySQLを介してセットアップを高度に利用可能にする方法。
データベースが稼働し、高可用性が実現したので、データのバックアップをどのように確保しますか？
バックアップは、ディザスタリカバリ、開発に対してテストするための本番データの提供、さらにはスレーブノードのプロビジョニングなど、さまざまな目的に使用できます。この最後のケースは、ClusterControlによってすでにカバーされています。レプリケーション設定に新しい（レプリカ）ノードを追加すると、ClusterControlはマスターノードのバックアップ/スナップショットを作成し、それを使用してレプリカを構築します。マスターへの余分な負荷を回避したい場合は、既存のバックアップを使用してレプリカをステージングすることもできます。バックアップが抽出され、準備され、データベースが稼働していると、ClusterControlは自動的にレプリケーションをセットアップします。
インスタントバックアップの作成
基本的に、バックアップの作成は、Galera、MySQLレプリケーション、PostgreSQL、MongoDBで同じです。バックアップセクションは、ClusterControl>バックアップの下にあります。 デフォルトでは、クラスターの作成されたバックアップのリストが表示されます（存在する場合）。それ以外の場合は、バックアップを作成するためのプレースホルダーが表示されます：
ここから、[バックアップの作成]ボタンをクリックして、インスタントバックアップを作成したり、新しいバックアップをスケジュールしたりできます。
作成されたすべてのバックアップは、「バックアップをクラウドにアップロード」を切り替えることでクラウドにアップロードすることもできます。ただし、動作するクラウドのクレデンシャルを指定する必要があります。デフォルトでは、31日より古いバックアップはすべて削除されます（バックアップ保持設定で構成可能）。または、永久に保持するか、カスタム期間を定義するかを選択できます。
「バックアップの作成」と「バックアップのスケジュール」は、スケジュール部分と後者の増分バックアップオプションを除いて、同様のオプションを共有します。そのため、バックアップの作成機能（インスタントバックアップとも呼ばれます）について詳しく説明します。
これらのさまざまなデータベースにはすべて異なるバックアップツールがあるため、選択できるオプションには明らかにいくつかの違いがあります。たとえば、MySQLでは、mysqldumpとxtrabackup（フルおよびインクリメンタル）のどちらかを選択できます。 MongoDBの場合、ClusterControlはmongodumpとmongodb-consistent-backup（beta）をサポートし、PostgreSQL、pg_dump、pg_basebackupはサポートされます。 MySQLにどちらを選択するかわからない場合は、mysqldumpとxtrabackupの違いと使用例についてこのブログを確認してください。
MySQLとGaleraのバックアップ
前の段落で述べたように、mysqldumpまたはxtrabackup（フルまたはインクリメンタル）のいずれかを使用してMySQLバックアップを作成できます。 「バックアップの作成」ウィザードでは、バックアップを実行するホスト、バックアップファイルを保存する場所、およびそのディレクトリと特定のスキーマ（xtrabackup）またはスキーマとテーブル（mysqldump）を選択できます。
バックアップしているノードが（本番）トラフィックを受信していて、余分なディスク書き込みが邪魔になるのではないかと心配している場合は、[コントローラーに保存]オプションを選択してバックアップをClusterControlホストに送信することをお勧めします。これにより、バックアップによってネットワーク経由でClusterControlホストにファイルがストリーミングされます。このノードに十分なスペースがあり、ClusterControlホストでストリーミングポートが開いていることを確認する必要があります。
圧縮と圧縮レベルを使用するかどうかについては、他にもいくつかのオプションがあります。圧縮レベルが高いほど、バックアップサイズは小さくなります。ただし、圧縮および解凍プロセスにはより高いCPU使用率が必要です。
バックアップの方法としてxtrabackupを選択すると、非同期、バックアップロック、圧縮、xtrabackup並列スレッド/gzipなどの追加オプションが開きます。非同期オプションは、Galeraクラスターからノードを非同期化する場合にのみ適用できます。バックアップロックは、新しいMDLロックタイプを使用して、非トランザクションテーブルおよびすべてのテーブルのDDLステートメントへの更新をブロックします。これは、InnoDB固有のワークロードに対してより効率的です。 Galera Clusterで実行している場合は、このオプションを有効にすることをお勧めします。
インスタントバックアップをスケジュールした後、アクティビティ>ジョブでバックアップジョブの進行状況を追跡できます。 ：
完了すると、バックアップリストの下に新しいエントリが表示されるはずです。
PostgreSQLのバックアップ
MySQLのインスタントバックアップと同様に、Postgresデータベースでバックアップを実行できます。 Postgresバックアップでは、pg_dumpallまたはpg_basebackupの2つのバックアップ方法がサポートされています。 ClusterControlは、選択したバックアップ方法に関係なく、常に完全バックアップを実行することに注意してください。
この点については、「PostgreSQLDBAになる-論理的および物理的なPostgreSQLバックアップ」で詳しく説明しました。
MongoDBのバックアップ
MongoDBの場合、ClusterControlは、Perconaによって開発された標準のmongodumpおよびmongodb-consistent-backupをサポートします。後者はまだベータ版であり、シャードクラスターのセットアップに適したMongoDBのクラスター整合性のあるポイントインタイムバックアップを提供します。シャーディングされたMongoDBクラスターは、複数のレプリカセット、構成レプリカセット、およびシャードサーバーで構成されているため、mongodumpのみを使用して一貫したバックアップを作成することは非常に困難です。
ウィザードでは、バックアップするデータベースノードを選択する必要がないことに注意してください。 ClusterControlは、最も正常なセカンダリレプリカをバックアップノードとして自動的に選択します。それ以外の場合は、プライマリが選択されます。バックアップの実行中は、バックアッププロセスが完了するまで、選択したバックアップノードがロックされます。
バックアップのスケジュール
インスタントバックアップの作成を試してみたので、バックアップをスケジュールすることでそれを拡張できます。
スケジュール設定は非常に簡単です。バックアップを作成する必要がある日と実行する必要がある時間を選択できます。
エクストラバックアップには、増分バックアップという追加機能があります。増分バックアップは、最後のバックアップ以降に変更されたデータのみをバックアップします。もちろん、開始点として完全バックアップがない場合、増分バックアップは役に立ちません。 2つの完全バックアップの間に、必要な数の増分バックアップを作成できます。ただし、復元には時間がかかります。
スケジュールが設定されると、[スケジュールされたバックアップ]タブにジョブが表示され、[編集]ボタンをクリックして編集できます。インスタントバックアップと同様に、これらのジョブはバックアップの作成をスケジュールし、[アクティビティ]タブで進行状況を追跡できます。
バックアップリスト
バックアップリストは、ClusterControl>バックアップの下にあります。 これにより、作成されたすべてのバックアップのクラスターレベルの概要がわかります。各エントリをクリックすると、行が展開され、バックアップに関する詳細情報が表示されます。
ClusterControlがジョブを実行したとき、各バックアップにはバックアップログが添付されます。このログは[その他のアクション]ボタンで利用できます。
クラウドでのオフサイトバックアップ
現在、データベースホストまたはClusterControlホストのいずれかに多くのバックアップが保存されているため、インフラストラクチャが完全に停止した場合に備えて、バックアップが失われないようにする必要もあります。 （例：DC on fireまたはflooded）したがって、ClusterControlを使用すると、バックアップをオフサイトのクラウドに保存またはコピーできます。サポートされているクラウドプラットフォームは、Amazon S3、Google Cloud Storage、AzureCloudStorageです。
アップロードプロセスは、バックアップが正常に作成された直後に実行されます（[バックアップをクラウドにアップロード]を切り替えた場合）。または、バックアップリストのクラウドアイコンボタンを手動でクリックすることもできます。
クラウドクレデンシャルを選択し、それに応じてバックアップ場所を指定します：
バックアップの復元および/または検証
バックアップリストインターフェイスから、特定のバックアップの[復元]ボタンをクリックするか、[バックアップの復元]ボタンをクリックして、クラスター内のホストにバックアップを直接復元できます。
優れた機能の1つは、最後に作成された完全バックアップを追跡し、そこから増分バックアップを開始するため、完全バックアップと増分バックアップを使用してノードまたはクラスターを復元できることです。次に、次の完全バックアップまで、すべての増分バックアップと一緒に完全バックアップをグループ化します。これにより、完全バックアップから開始して、その上に増分バックアップを適用して復元できます。
ClusterControlは、既存のデータベースノードでの復元、または新しいスタンドアロンホストでの復元と検証をサポートしています。
これらの2つのオプションは、新しいホスト情報用の追加オプションがあることを確認することを除いて、非常によく似ています。復元ウィザードに従う場合は、新しいホストを指定する必要があります。 「データベースソフトウェアのインストール」が有効になっている場合、ClusterControlはターゲットホスト上の既存のMySQLインストールをすべて削除し、既存のMySQLサーバーと同じバージョンでデータベースソフトウェアを再インストールします。
バックアップが復元されて検証されると、復元ステータスに関する通知が届き、ノードが自動的にシャットダウンされます。
ポイントインタイムリカバリ
MySQLの場合、xtrabackupとmysqldumpの両方を使用して、ポイントインタイムリカバリを実行し、マスタースレーブレプリケーションまたはGaleraCluster用の新しいレプリケーションスレーブをプロビジョニングすることもできます。 mysqldump PITR互換のバックアップには、GTID情報、binlogファイル、および位置を含む1つのダンプファイルが含まれています。したがって、バイナリログを生成するデータベースノードでのみ、「PITR互換」オプションを使用できます。
PITR互換オプションを切り替えると、ClusterControlはターゲットMySQLサーバーのすべてのデータベース、イベント、トリガー、およびルーチンに対して常に完全バックアップを実行するため、データベースとテーブルのフィールドはグレー表示されます。
次に、バックアップを復元します。バックアップがPITRと互換性がある場合、ポイントインタイムリカバリを実行するためのオプションが表示されます。そのための2つのオプションがあります-「時間ベース」と「位置ベース」。 「時間ベース」の場合は、曜日と時刻を渡すだけです。 「位置ベース」の場合、復元する場所に正確な位置を渡すことができます。 mysqlbinlogユーティリティを使用してbinlogの位置を取得する必要がある場合もありますが、これは復元するためのより正確な方法です。ポイントインタイムリカバリの詳細については、このブログをご覧ください。
バックアップ暗号化
普遍的に、ClusterControlはMySQL、MongoDB、PostgreSQLのバックアップ暗号化をサポートしています。バックアップは、AES-256CBCアルゴリズムを使用して保存時に暗号化されます。自動生成されたキーは、/ etc / cmon.d / cmon_X.cnf（XはクラスターID）の下のクラスターの構成ファイルに保存されます：
$ sudo grep backup_encryption_key /etc/cmon.d/cmon_1.cnf
backup_encryption_key='JevKc23MUIsiWLf2gJWq/IQ1BssGSM9wdVLb+gRGUv0='バックアップ先がローカルでない場合、バックアップファイルは暗号化された形式で転送されます。この機能は、基盤となるストレージシステムへのフルアクセスがないクラウド上のオフサイトバックアップを補完します。
最終的な考え
データをバックアップする方法と、データをオフサイトに安全に保存する方法を説明しました。回復は常に別のものです。 ClusterControlは、オンプレミスに保存されている、またはクラウドからコピーされた過去に作成されたバックアップからデータベースを自動的に回復できます。
明らかに、特に接続を保護するという側面では、データを保護することにはさらに多くのことがあります。これについては、次のブログ投稿で取り上げます！