バックアップからのMySQLまたはMariaDBGaleraクラスターの完全な復元

データベースクラスターの定期的なバックアップを実行することは、高可用性と障害復旧のために不可欠です。何らかの理由でクラスター全体を失い、バックアップから完全に復元する必要がある場合は、信頼性の高い最新のバックアップから開始する必要があります。

バックアップのベストプラクティス

適切なスケジュールバックアップ体制のために考慮すべきいくつかの推奨事項：

• 少なくとも2つの以前の完全バックアップからの壊滅的な障害から完全に回復できるはずです。最新の完全バックアップが破損、紛失、または破損した場合に備えて
• バックアップには、選択したサイクル内（通常は毎週）に少なくとも1つの完全バックアップが含まれている必要があります
• バックアップを現在のデータの場所から離れた場所、できればオフサイトに保存します。
• 安全性を高めるためにmysqldumpとXtrabackupを組み合わせて使用​​し、1つの方法に依存しないでください。
• 定期的にバックアップをテスト復元します。例： 2か月ごと。

通常、毎週の完全バックアップと毎日の増分バックアップで十分です。一定期間バックアップを数回保持することは常に良い計画です。おそらく、毎週のバックアップを1か月間保持します。これにより、緊急の場合、または何らかの理由でローカルバックアップファイルが破損した場合に、古いデータベースを回復できます。

mysqldumpまたはXtrabackup

mysqldump MySQLをバックアップする最も一般的な方法である可能性が非常に高いです。データの論理バックアップを実行し、SQLステートメントを使用して各テーブルから読み取り、データをテキストファイルにエクスポートします。 mysqldumpの復元 ダンプファイルを作成するのと同じくらい簡単です。主な欠点は、大規模なデータベースでは非常に低速であり、「ホット」ではなく、InnoDBバッファープールを一掃することです。

Xtrabackupはホットバックアップを実行し、バックアップ中にデータベースをロックせず、通常は高速です。ホットバックアップは、アプリケーションをブロックせずに実行されるため、高可用性にとって重要です。 Galeraは同期レプリケーションに依存しているため、これはGaleraで使用する場合にも重要な要素です。ただし、xtrabackupの復元は、手動の方法を使用すると少し注意が必要な場合があります。

ClusterControlは、mysqldumpとXtrabackup（フルおよびインクリメンタル）の両方のスケジューリング、およびUIからのバックアップ復元をサポートします。

バックアップからの完全な復元

この投稿では、MariaDB Galera Clusterで実行されている空のクラスターにXtrabackup（フル+インクリメンタル）を復元する方法を紹介します。これらの手順は、CodershipのPerconaXtraDBClusterまたはGaleraClusterforMySQLでも機能するはずです。

元のクラスターでは、完全エクストラバックアップが毎日スケジュールされ、増分バックアップが1時間ごとに作成されていました。次のスクリーンショットに示すように、バックアップはClusterControlに保存されます。

ここで、元のクラスターが失われ、新しいクラスターに完全に復元する必要があると仮定します。手順は次のとおりです。

0. 新しいClusterControlサーバーをセットアップします。
1. 新しいMariaDBクラスターをセットアップします。
2. バックアップレコードとファイルを新しいClusterControlサーバーにエクスポートします。
3. 復元プロセスを開始します。
4. 残りのノードを起動します。

次の図は、この演習のアーキテクチャを示しています。

ステップ1-新しいMariaDBクラスターをセットアップする

ClusterControlをインストールし、新しいMariaDBクラスターをデプロイします。 ClusterControl-> Deploy-> Deploy Database Cluster-> MySQL Galeraに移動し、デプロイメントダイアログで必要な情報を指定します：

[展開]ボタンをクリックして、展開を開始します。古いサーバーにはクラスターしかないため、この新しいインスタンスではクラスターIDは同一（クラスターID：1）である必要があります。

古いClusterControlサーバーで、backup_recordsテーブルをダンプファイルにエクスポートします。

$ mysqldump -uroot -p --single-transaction --no-create-info cmon backup_records > backup_records.sql

次に、古いサーバーから新しいClusterControlサーバーへのバックアップファイルのリモートコピーを実行します。

$ scp -r /root/backups 192.168.55.150:/root/
$ scp ~/backup_records.sql 192.168.55.150:~

次に、新しいClusterControlサーバーのIPアドレスを反映するようにダンプファイルを変更します。 IPアドレスのドットをエスケープすることを忘れないでください：

$ sed -i "s/192\.168\.55\.170/192\.168\.55\.150/g" backup_records.sql

新しいClusterControlサーバーで、ダンプファイルをインポートします。

$ mysql -uroot -p cmon < backup_records.sql

新しいClusterControlサーバーでバックアップリストが正しいことを確認します。

ご覧のとおり、以前のIPアドレス（192.168.55.170）のすべてのオカレンスは、新しいIPアドレス（192.168.55.150）に置き換えられています。これで、新しいサーバーで復元を実行する準備が整いました。

ステップ3-復元を実行する

ClusterControl UIを介して復元を実行するのは、ポイントアンドクリックの簡単な手順です。復元するバックアップを選択し、「復元」ボタンをクリックします。利用可能な最新の増分バックアップを復元します（バックアップ：9）。バックアップ名のすぐ下にある[復元]ボタンをクリックすると、次の復元前ダイアログが表示されます。

バックアップサイズはかなり小さいようです（165.6kB）。 ClusterControlは、完全なXtrabackupを保持するバックアップセット6の下にグループ化されたすべての増分バックアップを準備するため、実際には問題ではありません。復元後のオプションもいくつかあります：

• バックアップを復元する-バックアップを復元するノードを選択します。
• Tmp Dir-ディレクトリは、バックアップの準備中に一時ストレージとしてローカルClusterControlサーバーで使用されます。推定されたMySQLデータディレクトリと同じ大きさである必要があります。
• 復元されたノードからのクラスターのブートストラップ-これは新しいクラスターであるため、これをオンに切り替えて、復元が成功した後にClusterControlがクラスターを自動的にブートストラップするようにします。
• バックアップを復元する前にdatadirのコピーを作成する-復元されたデータが破損しているか、期待どおりでない場合は、以前のMySQLデータディレクトリのバックアップが作成されます。これは新しいクラスターなので、無視します。

Percona Xtrabackupの復元により、クラスターが停止します。 ClusterControlは次のことを行います：

1. クラスター内のすべてのノードを停止します。
2. 選択したノードでバックアップを復元します。
3. 選択したノードをブートストラップします。

復元の進行状況を確認するには、[アクティビティ]->[ジョブ]->[バックアップの復元]に移動し、[完全なジョブの詳細]ボタンをクリックします。次のように表示されます：

実行する必要がある重要なことの1つは、復元プロセス中にターゲットノード（192.168.55.151）でMySQLエラーログの出力を監視することです。復元が完了した後、ブートストラッププロセス中に、次の行が表示され始めます。

Version: '10.1.22-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:52 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:53 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:54 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:55 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)

パニックにならない。このバックアップセットには新しいClusterControlcmonパスワードのcmonログイン資格情報が保存されないため、これは予想される動作です。代わりに、古いcmonユーザーを復元/置換しました。このDBノードで次のステートメントを実行して、cmonユーザーをサーバーに再付与する必要があります。

GRANT ALL PRIVILEGES ON *.* to [email protected]'192.168.55.150' IDENTIFIED BY 'mynewCMONpassw0rd' WITH GRANT OPTION;
FLUSH PRIVILEGES;

その後、ClusterControlはブートストラップされたノードに接続し、ノードとバックアップの状態を判別できるようになります。すべて問題がなければ、次のように表示されます。

この時点で、ターゲットノードはブートストラップされて実行されています。 [ノード]->[ノード]->[ノードの開始]を選択し、[初期開始を実行する]チェックボックスをオンにして、残りのノードを開始できます。

これで復元が完了し、[パフォーマンス]-> [DB Growth]で、新しく復元されたデータセットの更新されたサイズが報告されることが期待できます：

復元しました！