Database Backup Serviceを使ってみる #2 成功編

この記事は Alibaba Cloud の日本サイト の環境(ドキュメントやアカウント、そのアカウントでの検証結果)に基づいて記載しています。 日本サイトと国際サイトでは各プロダクトごとに提供機能が一部異なることがあります(そのほとんどは国際サイトの方が日本サイトよりも多機能になっている)。記事の内容は適宜最新化する予定です。

前回、バックアップ計画を作成しようとすると ” no node to run this job: ~” のエラーメッセージが表示され先に進めることが出来ませんでした。 メッセージの内容的にはDatabase Backup Service側でバックアップジョブを実行するノードが存在しないということになります。 

とりあえず、一晩明けてバックアップ計画の作成からリトライします。

バックアップ計画の作成(リトライ)

まずは、Alibaba Cloud コンソールにログインし、Database Backup Serviceの管理画面にアクセスします。 

おや、昨日と挙動が違います。 ”DBSでアラートルールを設定していません”と警告が出てきました。 昨日の購入作業やバックアップ計画作業では一度も表示されていないメッセージです。 

メッセージの内容からDatabase Backup ServiceはCloud Monitorと連携可能で、アラートルールもこの画面でOKを押下するだけで自動作成してくれるとのこと。 今回はお任せの自動作成にします。

OKを押したあと、元のバックアップ計画の画面に戻ります。 

バックアップ計画の作成を進めます。

必要な情報を設定します。

前の画面で接続先に指定したMySQLに構成されたDatabaseが参照できるので、バックアップ対象として選択します。

バックアップスケジュールを指定します。

バックアップデータのライフサイクルの設定を行います。

昨日、失敗したポイントまで来ました。”事前チェックとタスクの開始”をクリックします。

また、同じエラーで失敗しました。

ドキュメントの再確認

まず、 ”事前チェックとタスクの開始” に関するトラブルシュートの情報が無いか確認します。

よくある質問にすぐに見つかりました。しかし、記載されている内容は今回の事象にまったく合致しません。

URLはこちら

Internationl サイトに情報が無いか探しにいきます。日本サイトと全く同じ内容です。(Internationalサイトがオリジナルで日本サイトには日本語に翻訳したものを記載しているのでしょう)

URLはこちら

サポートへ確認

サポートに確認し、結果、状況が解消されました(Alibaba Cloud側の問題だった模様)。 丁寧な対応ありがとうございました。

バックアップの計画の作成を再開

もう一度バックアップ計画の作成を進めます。 問題のエラーはもう発生しません。 しかし、事前チェックで3点失敗しています。これはDatabase Backup Serviceの問題ではなく、MySQLの設定が不足しているという為です。1つ1つ対応していきます。

失敗したチェック項目#1 ソースデータベースへの許可

これはDatabase Backup ServiceからMySQLへの接続において、MySQLのユーザの権限が不足していることを示しています。

”ソースデータベースの許可”行の右のアイコンをクリックします。 原因と対応手順が具体的に提示されます。

結果部分を下にスクロールするとMySQLで実施するべきgrantコマンドをオプション付きで提示されます。 

今回は”root”での接続をやめて新たに”dbsuser”を作成し、そのアカウントに権限を割り当てました。 以下の通り、ALL PRIVILEGESを与えているのでセキュリティ面で大きな違いはないのですが。

mysql> show grants for dbsuser@’%’;
+———————————————-+
| Grants for dbsuser@% |
+———————————————-+
| GRANT ALL PRIVILEGES ON . TO ‘dbsuser’@’%’ |
+———————————————-+
1 row in set (0.00 sec)

失敗したチェック項目#2 ソースデータベースへのbinlog

ソースデーターベースのlog_binの有効化です。こちらはmysqld.cnfを変更します。コメントアウトされているlog_binを有効化します。

#log_bin = /var/log/mysql/mysql-bin.log
log_bin = /var/log/mysql/mysql-bin.log

失敗したチェック項目#3 ソースデータベースのID

server_idを”1″から変える必要があるとのこと。こちらもmysql.cnfを変更します。

#server-id = 1
server-id = 2019

変更後にmysqldを再起動します。

root@bigriver:~# systemctl restart mysql.service

再度、事前チェックを実施します。 ”開始”をクリックします。

確認画面で”OK”をクリックします。

すみません、事前チェックがすべて成功した画面のキャプチャを取り忘れていました。 とりあえず、事前チェックが成功すると、”開始済み”となり、初回のバックアップも自動的に実行されます。本番系のシステムに実施する場合は気を付ける必要がありますね。どれ位の負荷がかかるかも不明なはずなので利用者が少ない時間帯などに実施する必要があるかもしれません。

バックアップ計画の確認

構成内容は以下。 OSSのバケット名が載っていますが、ACLは非公開なので大丈夫でしょう。

取得したバックアップの確認は”バックアップセットの表示”をクリックします。

OSSバケットのページが自動的に表示され、バックアップデータを確認することが可能です。

Database Backup Service を利用してバックアップを行うことが出来ました。

まとめ

色々とトラブルもありましたが無事、Database Backup Serviceを設定することが出来ました。

また、このブログサイトを提供する Web サーバ環境のバックアップを強化することが出来ました。こ れまではECSのスナップショットのみだったのですが、Database Backup Serviceを利用することでテーブル単位でのリストアを任意に行えるようになりました。 

以上