ほとんどの組織はデータを失うことを許せないため、最近では高可用性が必須です。ただし、高可用性には常に値札が付いています（これは大きく異なる可能性があります）。ほぼ即時のアクションを必要とするセットアップには、通常、本番セットアップを正確に反映する高価な環境が必要になります。ただし、他にも安価なオプションがあります。これらでは、ディザスタリカバリクラスタにすぐに切り替えることができない場合がありますが、それでもビジネス継続性は可能です（そして予算を浪費することはありません）。
このタイプのセットアップの例は、「コールドスタンバイ」DR環境です。これにより、災害が発生した場合に外部の場所で新しい環境を起動しながら、経費を削減できます。このブログ投稿では、そのような設定を作成する方法を示します。
このクラスターを展開するために、無料でダウンロードできるClusterControlを使用しました。 DR環境では、EC2を使用します（ただし、他のクラウドプロバイダーでもかまいません）。
対処しなければならない主な問題は、ディザスタリカバリ環境でデータベースを復元するための新しいデータをどのように確保する必要があるかということです。もちろん、理想的には、EC2でレプリケーションスレーブを稼働させます...しかし、その場合は料金を支払う必要があります。予算が厳しい場合は、バックアップでそれを回避することができます。最悪のシナリオでは、すべてのデータを回復することはできないため、これは完全なソリューションではありません。
「最悪のシナリオ」とは、元のデータベースサーバーにアクセスできない状況を意味します。それらに到達できれば、データは失われていなかったでしょう。
ClusterControlを使用してバックアップスケジュールを設定し、データが失われる可能性を減らします。また、ClusterControl機能を使用してバックアップをクラウドにアップロードします。データセンターが利用できない場合は、選択したクラウドプロバイダーにアクセスできることを期待できます。
ClusterControlでのバックアップスケジュールの設定
まず、クラウドのクレデンシャルを使用してClusterControlを構成する必要があります。
これは、左側のメニューの[統合]を使用して行うことができます。
クラウドとしてAmazonWebServices、Google Cloud、またはMicrosoftAzureを選択できますClusterControlにバックアップをアップロードさせます。 ClusterControlがS3を使用してバックアップを保存するAWSを進めます。
次に、キーIDとキーシークレットを渡し、デフォルトのリージョンを選択する必要がありますこの一連の資格情報の名前を選択します。
これが完了すると、追加したばかりのクレデンシャルが次のように表示されます。 ClusterControl。
次に、バックアップスケジュールの設定に進みます。
ClusterControlを使用すると、バックアップをすぐに作成するか、スケジュールすることができます。 2番目のオプションを使用します。次のスケジュールを作成する必要があります：
- 1日に1回作成される完全バックアップ
- 10分ごとに作成される増分バックアップ。
毎日午前2時に実行される完全バックアップから開始します。マスターを使用してバックアップを取得し、コントローラーの/ root /backups/ディレクトリに保存します。 「バックアップをクラウドにアップロード」オプションも有効にします。
次に、デフォルト構成にいくつかの変更を加えます。自動的に選択されたフェイルオーバーホストを使用することにしました（マスターが使用できない場合、ClusterControlは使用可能な他のノードを使用します）。また、ネットワーク経由でバックアップを送信するため、暗号化を有効にしたかったのです。
次に、資格情報を選択するか、既存のS3バケットを選択するか、必要に応じて新しいもの。
基本的に、増分バックアップのプロセスを繰り返していますが、今回は10分ごとにバックアップを実行するための「詳細」ダイアログ。
残りの設定も同様で、S3バケットを再利用することもできます。
バックアップスケジュールは上記のようになります。手動で完全バックアップを開始する必要はありません。ClusterControlはスケジュールどおりに増分バックアップを実行し、使用可能な完全バックアップがないことを検出すると、増分バックアップではなく完全バックアップを実行します。
このような設定により、外部システムのデータを10分の粒度で復元できると言っても過言ではありません。
ディザスタリカバリインスタンスでバックアップを復元する必要がある場合は、いくつかの手順を実行する必要があります。このプロセスを時々テストして、正しく機能し、実行に習熟していることを確認することを強くお勧めします。
まず、ターゲットサーバーにAWSコマンドラインツールをインストールする必要があります：
[email protected]:~# apt install python3-pip
[email protected]:~# pip3 install awscli --upgrade --user次に、適切な資格情報を使用して構成する必要があります：
[email protected]:~# ~/.local/bin/aws configure
AWS Access Key ID [None]: yourkeyID
AWS Secret Access Key [None]: yourkeySecret
Default region name [None]: us-west-1
Default output format [None]: jsonこれで、S3バケット内のデータにアクセスできるかどうかをテストできます。
[email protected]:~# ~/.local/bin/aws s3 ls s3://drbackup/
PRE BACKUP-1/
PRE BACKUP-2/
PRE BACKUP-3/
PRE BACKUP-4/
PRE BACKUP-5/
PRE BACKUP-6/
PRE BACKUP-7/次に、データをダウンロードする必要があります。バックアップ用のディレクトリを作成します。バックアップセット全体をダウンロードする必要があることを忘れないでください。完全バックアップから、適用する最後の増分バックアップまでです。
[email protected]:~# mkdir backups
[email protected]:~# cd backups/これで、2つのオプションがあります。バックアップを1つずつダウンロードすることもできます：
[email protected]:~# ~/.local/bin/aws s3 cp s3://drbackup/BACKUP-1/ BACKUP-1 --recursive
download: s3://drbackup/BACKUP-1/cmon_backup.metadata to BACKUP-1/cmon_backup.metadata
Completed 30.4 MiB/36.2 MiB (4.9 MiB/s) with 1 file(s) remaining
download: s3://drbackup/BACKUP-1/backup-full-2019-08-20_113009.xbstream.gz.aes256 to BACKUP-1/backup-full-2019-08-20_113009.xbstream.gz.aes256
[email protected]:~# ~/.local/bin/aws s3 cp s3://drbackup/BACKUP-2/ BACKUP-2 --recursive
download: s3://drbackup/BACKUP-2/cmon_backup.metadata to BACKUP-2/cmon_backup.metadata
download: s3://drbackup/BACKUP-2/backup-incr-2019-08-20_114009.xbstream.gz.aes256 to BACKUP-2/backup-incr-2019-08-20_114009.xbstream.gz.aes256特にローテーションのスケジュールが厳しい場合は、バケットのすべてのコンテンツをサーバーにローカルにあるものと同期することもできます。
[email protected]:~/backups# ~/.local/bin/aws s3 sync s3://drbackup/ .
download: s3://drbackup/BACKUP-2/cmon_backup.metadata to BACKUP-2/cmon_backup.metadata
download: s3://drbackup/BACKUP-4/cmon_backup.metadata to BACKUP-4/cmon_backup.metadata
download: s3://drbackup/BACKUP-3/cmon_backup.metadata to BACKUP-3/cmon_backup.metadata
download: s3://drbackup/BACKUP-6/cmon_backup.metadata to BACKUP-6/cmon_backup.metadata
download: s3://drbackup/BACKUP-5/cmon_backup.metadata to BACKUP-5/cmon_backup.metadata
download: s3://drbackup/BACKUP-7/cmon_backup.metadata to BACKUP-7/cmon_backup.metadata
download: s3://drbackup/BACKUP-3/backup-incr-2019-08-20_115005.xbstream.gz.aes256 to BACKUP-3/backup-incr-2019-08-20_115005.xbstream.gz.aes256
download: s3://drbackup/BACKUP-1/cmon_backup.metadata to BACKUP-1/cmon_backup.metadata
download: s3://drbackup/BACKUP-2/backup-incr-2019-08-20_114009.xbstream.gz.aes256 to BACKUP-2/backup-incr-2019-08-20_114009.xbstream.gz.aes256
download: s3://drbackup/BACKUP-7/backup-incr-2019-08-20_123008.xbstream.gz.aes256 to BACKUP-7/backup-incr-2019-08-20_123008.xbstream.gz.aes256
download: s3://drbackup/BACKUP-6/backup-incr-2019-08-20_122008.xbstream.gz.aes256 to BACKUP-6/backup-incr-2019-08-20_122008.xbstream.gz.aes256
download: s3://drbackup/BACKUP-5/backup-incr-2019-08-20_121007.xbstream.gz.aes256 to BACKUP-5/backup-incr-2019-08-20_121007.xbstream.gz.aes256
download: s3://drbackup/BACKUP-4/backup-incr-2019-08-20_120007.xbstream.gz.aes256 to BACKUP-4/backup-incr-2019-08-20_120007.xbstream.gz.aes256
download: s3://drbackup/BACKUP-1/backup-full-2019-08-20_113009.xbstream.gz.aes256 to BACKUP-1/backup-full-2019-08-20_113009.xbstream.gz.aes256ご存知のとおり、バックアップは暗号化されています。 ClusterControlに保存されている暗号化キーが必要です。コピーがメインのデータセンターの外の安全な場所に保管されていることを確認してください。到達できない場合、バックアップを復号化することはできません。キーはClusterControl構成にあります：
[email protected]:~# grep backup_encryption_key /etc/cmon.d/cmon_1.cnf
backup_encryption_key='aoxhIelVZr1dKv5zMbVPLxlLucuYpcVmSynaeIEeBnM='base64を使用してエンコードされているため、バックアップの復号化を開始する前に、まずデコードしてファイルに保存する必要があります。
echo "aoxhIelVZr1dKv5zMbVPLxlLucuYpcVmSynaeIEeBnM =" | openssl enc-base64-d>パス
これで、このファイルを再利用してバックアップを復号化できます。今のところ、1つの完全バックアップと2つの増分バックアップを実行するとします。
mkdir 1
mkdir 2
mkdir 3
cat BACKUP-1/backup-full-2019-08-20_113009.xbstream.gz.aes256 | openssl enc -d -aes-256-cbc -pass file:/root/backups/pass | zcat | xbstream -x -C /root/backups/1/
cat BACKUP-2/backup-incr-2019-08-20_114009.xbstream.gz.aes256 | openssl enc -d -aes-256-cbc -pass file:/root/backups/pass | zcat | xbstream -x -C /root/backups/2/
cat BACKUP-3/backup-incr-2019-08-20_115005.xbstream.gz.aes256 | openssl enc -d -aes-256-cbc -pass file:/root/backups/pass | zcat | xbstream -x -C /root/backups/3/データが復号化されたので、MySQLサーバーのセットアップに進む必要があります。理想的には、これは実稼働システムとまったく同じバージョンである必要があります。 MySQL用のPerconaServerを使用します：
cd ~
wget https://repo.percona.com/apt/percona-release_latest.generic_all.deb
sudo dpkg -i percona-release_latest.generic_all.deb
apt-get update
apt-get install percona-server-5.7複雑なことは何もありません。通常のインストールだけです。準備ができたら、停止してデータディレクトリの内容を削除する必要があります。
service mysql stop
rm -rf /var/lib/mysql/*バックアップを復元するには、Xtrabackupが必要です。これはCCがバックアップを作成するために使用するツールです（少なくともPeronaとOracle MySQLの場合、MariaDBはMariaBackupを使用します）。このツールは、運用サーバーと同じバージョンでインストールすることが重要です。
apt install percona-xtrabackup-24xtrabackup --prepare --apply-log-only --target-dir=/root/backups/1/
xtrabackup --prepare --apply-log-only --target-dir=/root/backups/1/ --incremental-dir=/root/backups/2/
xtrabackup --prepare --target-dir=/root/backups/1/ --incremental-dir=/root/backups/3/最後のコマンドで、xtrabackupが未完了のトランザクションのロールバックを実行できるようにしました。その後、増分バックアップを適用することはありません。次に、データディレクトリにバックアップを入力し、MySQLを起動して、すべてが期待どおりに機能するかどうかを確認します。
[email protected]:~/backups# mv /root/backups/1/* /var/lib/mysql/
[email protected]:~/backups# chown -R mysql.mysql /var/lib/mysql
[email protected]:~/backups# service mysql start
[email protected]:~/backups# mysql -ppass
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 6
Server version: 5.7.26-29 Percona Server (GPL), Release '29', Revision '11ad961'
Copyright (c) 2009-2019 Percona LLC and/or its affiliates
Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> show schemas;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| proxydemo |
| sbtest |
| sys |
+--------------------+
6 rows in set (0.00 sec)
mysql> select count(*) from sbtest.sbtest1;
+----------+
| count(*) |
+----------+
| 10506 |
+----------+
1 row in set (0.01 sec)ご覧のとおり、すべてが良好です。 MySQLは正しく起動し、それにアクセスすることができました（そしてデータはそこにあります！）データベースを別の場所で正常に稼働状態に戻すことができました。必要な合計時間は、データのサイズに厳密に依存します。S3からデータをダウンロードし、復号化して解凍し、最後にバックアップを準備する必要がありました。それでも、これは非常に安価なオプションであり（S3データのみを支払う必要があります）、災害が発生した場合にビジネスを継続するためのオプションを提供します。