MySQL Database Serviceでポイントインタイムリカバリを実施する

この記事は最終更新から2年以上経過しています。内容が古くなっている可能性があります。

はじめに

MySQL Database Service (以下 MDS) は自動バックアップの機能がありますが、
DBの運用ではバックアップからのリストアだけでなく、ポイントインタイムリカバリを行いたい場合もあるかと思います。

今回はOracleの以下のブログ記事で紹介されているMDSでのポイントインタイムリカバリを試してみました。

https://blogs.oracle.com/mysql/point-in-time-recovery-in-oci-mds-with-object-storage-%E2%80%93-part-1
https://blogs.oracle.com/mysql/point-in-time-recovery-in-oci-mds-with-object-storage-%e2%80%93-part-2

目次

事前準備

以下の準備が事前に必要となります。

  • MDSの作成
  • バックアップ計画
  • コンピュートインスタンス作成
  • オブジェクトストレージバケット作成

本記事ではオブジェクトストレージバケット作成のみ説明します。
MDSの作成についてはこちらの記事で、バックアップの作成はこちらの記事でも紹介しております。

バケット作成

バケットはオブジェクト・ストレージとアーカイブ・ストレージ -> バケット から作成します。

バケット作成を選択し、名前などを定義変更した後に作成ボタンを選択します。

バケットについて詳しくはこちらのドキュメントをご参照ください。
また。CLIを使用したバケットの作成方法は弊社ブログのこちらの記事でも触れられています。

バイナリログの保存

必要なパッケージを事前準備で作成したコンピュート・インスタンスにインストールします。
s3fs-fuseのインストールにはEPELが必要です。

次に、オブジェクトストレージバケットにアクセスするためのキーを取得します。

プロファイルのユーザー設定を選択

顧客秘密キーに移動し、秘密キーの生成ボタンを選択する

適当な秘密キーの名前を入力し、秘密キーの生成ボタンを選択する

生成されたキーが表示されます。このキーは控えておきます。

リストから生成したキーのアクセスキーも確認します。
アクセスキーにマウスオーバーするとコピーすることができため、これも控えておきます。

控えた秘密キーとアクセスキーを任意のファイルに記載します。
キーは1行でコロン区切りで<アクセスキー>:<秘密キー>の形式で記載します。

例えば、アクセスキーがhherk4eq9xp236exkyi8rtt3、秘密キーがvb4hysn+jn/mr5h8+43nfvk+6aの場合は以下のようになります。

作成したファイルのパーミッションを変更します。

ディレクトリを作成し、オブジェクトストレージのバケットをマウントします。

s3fsコマンドは以下のように指定します

  • バケット名は本手順の最初に作成したバケットの名前です
  • ディレクトリは直前に作成したディレクトリのパスです
  • キーファイルのパスは事前に作成した秘密キーとアクセスキーのファイルのパスです
  • ネームスペース名はアカウント作成時に割り当てられます。
    プロファイル -> テナンシから確認することができます。

マウントできたかどうかを確認してみます。/mnt/oci/にファイルを一つ作成します。

作成したss-bucketのオブジェクトを確認すると、先ほど作成したファイルが存在していることが確認できます。

バイナリログの取得

次にMDSインスタンスからバイナリログを取得し、/mnt/ociにストリーミングする設定をします。

専用のMySQLユーザーを作成します。

mysql_config_editorを使用して接続情報を保存します。

mysqlbinlog--read-from-remote-serverオプションを使用することでサーバーに接続してバイナリログを要求し、それをファイルに書き出すことができます。この機能を利用して、バイナリログを取得します。これにはREPLICATION SLAVE権限が必要です。

今回は、参照元のブログ記事に従いこのbinlog_to_object_storage.shを使用します。
スクリプト内でperformance_schema.file_instancesに対して、SELECTを実行するため、SELECT権限も必要となります。

このスクリプトを/root/bin/に配置します。

設定ファイルを作成します。
ファイルを作成には作成したログインパス、ディレクトリを指定します。

次にプロセスを開始するためのsystemdサービススクリプトを作成します。

デーモンをリロードした後、binlog_streaming@my-mds.serviceをスタートします。

起動していることを確認します。

/mnt/ociを確認するとログを取得できていることが確認できます。

バケットからもバイナリログが保存されていることが確認できます。

ポイントインタイムリカバリ

ストリーミングしたバイナリログを用いてリカバリを実施します。

事前準備

シナリオで使用するテーブルを作成します。

完全バックアップを手動で取得します。
取得方法はこちらの記事をご参照ください。

シナリオ

オペレーションミスを想定し、d1.t1からデータを削除してしまいます。
データを削除する前の状態までデータベースを戻します

まずはバイナリログから該当のDELETE文を探します。
今回はDELETE文がdelete from d1.t1 where c2 = "ccc";であることがわかっているため、”ccc”でバイナリログを探してみます。

複数ヒットしましたが、該当のDELETE文は直近のバイナリログの方にあると考えられるため、binary-log.000033の方をmysqlbinlogコマンドで詳しく見てみます。

DELETE文のGTIDは以下のようになっていることがわかります。

取得したバックアップをリストアします。リストア方法はこちらの記事をご参照ください。

リストアしたDBに接続し、GTIDセットを確認します。

テーブルはバックアップを取ったときの状態です。

gtid_executed が5d7d91f1-1b62-11ec-ad40-02001700c0e4:1-23
DELETE文のGTIDが5d7d91f1-1b62-11ec-ad40-02001700c0e4:27であるため、
今回は5d7d91f1-1b62-11ec-ad40-02001700c0e4:24-26までを含めます。

以下のコマンドでバイナリログを適用します。

リストアしたDBに接続してみると、DELETEを実行する直前までデータが復元されていることが確認できます。

まとめ

MDSからmysqlbinlogを取得し、バケットに保持する手順とバックアップとバイナリログを用いてポイントインタイムリカバリを実行する手順を確認しました。
また、今回の検証では触れませんでしたが、ライフサイクル・ルールを作成しバケット内のオブジェクトの保持期間を設定することができます。この機能を用いて、古いバイナリログはアーカイブ層に移動させたり、削除したりするといいでしょう。


Oracle Cloud

スマートスタイルTECHブログについて

スマートスタイルTECHブログでは、日頃OCIのサポート業務に従事している有資格者で構成された技術サポートチームがOCIに関する技術情報を発信しています。データベースのお困りごとはお気軽にご相談下さい。

\ お役立ち資料のご案内 /
導入事例
よかったらシェアしてね!
  • URLをコピーしました!
目次