スマートスタイル TECH BLOG|データベース&クラウドの最新技術情報を配信

Oracle MySQL Cloud Serviceを使ってみました-嵌ったこと&解決編

はじめに

今回は、Oracle MySQL Cloud Serviceを検証しながら嵌ったこと&その解決方法について書いてみたいと思います。

嵌ったこと

1.Oracle Cloud パスワードを変更した際は、バックアップに注意!
2.ストレージがいっぱい!
3.Point-in-Time リカバリーにはできる/できないパターンが存在する?!

同じことで嵌っている方、いらっしゃいませー!
では早速、見ていきましょう。

1.Oracle Cloud パスワードを変更した際は、バックアップに注意!

Oracle Cloudのパスワードを変更した後、バックアップの設定を変える際や、バックアップを行う際、エラーが起こりました。
実際のエラー内容は、下記の通りです。

a.バックアップの再有効化時、「SM-BKP-5021」エラー

b.バックアップ時、「SM-BKP-5106」エラー

■原因

バックアップ用のストレージ・クラウドのパスワードを更新していなかったため、起こっていました。
Oracle MySQL Cloud Service – Updating the Password for Backing Up to the Storage Cloud

■解決策

Service Credentials画面のパスワードをOracle Cloudの更新後のパスワードに変更します。
Oracle Cloudのパスワードを忘れた場合や、ロックされた場合、特にパスワード有効期限切れなどで、パスワードを変更する場合があり得ると思いますので、その場合は忘れずにあわせて変更しましょう。

インスタンスのアクションメニュー → 「Service Credentials」選択します。

表示された「Service Credentials」画面でパスワードを更新し「Update」ボタンをクリックします。

■確認

バックアップを実行し、成功していることが確認できました。
※下から上の順で、バックアップ失敗 → パスワード変更 → バックアップ成功

■おまけ

従来のクラウド・アカウントのパスワード有効期限は120日間であるため、約4ヵ月に1回はパスワードを更新する必要があります。
Administering Oracle Identity Cloud Service – Understanding the Criteria for Password Policies

パスワード有効期限は、「設定」メニュー → 「パスワード・ポリシーの変更」画面 → 「有効期限」の方で変更可能ですので、下記のマニュアル、もしくは、チュートリアルをご覧になってください。

2.ストレージがいっぱい!

大量のデータ作成をしていましたが、エラーが発生し、動かなくなりました。

再度、TeraTermで接続をしてみても、なかなか下記の画面から進まず。

■原因

やっと表示されましたが、MySQL InformationのStatusがNOT RUNNINGになっています。
確認すると、「data」ストレージがいっぱいになっていました。

動かなかったので、いったん、再起動してみました。すると、67%まで減りました。

■解決策

ストレージを追加します。

インスタンスのInstance Overview → Resorcesのアクションメニュー →「 Add Storage」選択します。

表示された「Add Storage」画面で「使用可能なデータベース・ストレージ」を入力し、「Yes, Add Storage」ボタンを押下します。
※入力した値は、現状のストレージ・サイズより追加されるサイズではなく、変えたいストレージ・サイズです。現状25GBで、25GBを追加した場合は、50GBを入力します。なお、現状より小さい値は入力できません。

3.Point-in-time リカバリーにはできる/できないパターンが存在する?!

この前のバックアップ&リストア編を書きながら、当初検証として考えていたパターンの何パターンが、Point-in-Time リカバリーに失敗していました。

■検証パターン

その内の一つが下記のパターンです。

エラー内容は、下記の通りです。

■原因

PITRはできるパターン/できないパターンがありました。
MySQL Enterprise Backupのマニュアルには「フルバックアップと増分バックアップの間」や「 2 つの増分バックアップの間の任意の時点の状態」にリストアできると書いています。

Using MySQL Enterprise Backup and the binary log files included by default in the incremental backups it creates (except when they are created with the –use-tts option), you can restore your database to its state at an arbitrary time tR in between a full backup and an incremental backup or in between two incremental backups.

https://dev.mysql.com/doc/mysql-enterprise-backup/4.1/en/advanced.point.html

検証では、スケジュールのバックアップがまだ実施されていない、かつ、増分バックアップが行われていない状態で、オンデマンド・バックアップ(full backup)を行っていたため、PITRができなかったということがわかりました。

Oracle MySQL Cloud Serviceでは、スケジュールバックアップが設定されていたら、週に1回はフルバックアップ、フルバックアップ以外の日は増分バックアップが行われるため、「フルバックアップと増分バックアップ」、「増分バックアップと増分バックアップ」の任意の状態にリストアできるということは、想定通りのスケジュールのバックアップに対し、PITRが保証できるということです。

■解決策

では、PITRできないのか?!
と聞かれたら、画面上ではできません。
しかし、バイナリログを利用すると、すべてのパターンとは限りませんが、上記のパターンに対してPITRできます。
Point-in-Time (Incremental) Recovery Using the Binary Log

フルバックアップからリストアを行い、その後はバイナリログからデータ登録(B)の部分を取得し、DBに反映させる方法です。
計画は下記の通りです。

1.バイナリログの退避(mysqlbinlog使用)
2.フルバックアップへリストアを実施(データ登録Bの直後の状態に戻る)
3.退避させておいたバイナリログからデータ登録(B)の内容を取得しファイルに保存
4.保存したファイルを実行させ、DBに反映

ここから下は、おまけです。
実際に計画を実施し、PITRしてみました。


0.データ状況確認

  • インスタンスを作成 → データ登録(A) の直後
  • インスタンスを作成 → データ登録(A) → オンデマンド・バックアップ(full)→ データ登録(B) の直後
  • インスタンスを作成 → データ登録(A) → オンデマンド・バックアップ(full)→ データ登録(B) → データ削除の直後

1.バイナリログの退避(mysqlbinlog使用)

リストアを実施すると、バイナリログが空になってしまうので、事前にバイナリログを退避しておきましょう。
※バイナリログを利用し、PITRする方法ついては下記のマニュアルに詳しく説明されていますので、参照してください。
Point-in-Time (Incremental) Recovery Using the Binary Log

2.オンデマンド・バックアップからリストアを実施(データ登録Bの直後の状態に戻る)

フルバックアップからリストアを実施します。
※実行方法は、「バックアップ&リストア-【10.特定のバックアップからのリストア実施】」を参照してください。

では、データを確認してみましょう。
「データ登録(A)」の登録後と同じであることが確認できました。

リストア後、バイナリログフォルダを確認してみると、全部なくなっています。

3.退避させておいたバイナリログからデータ登録(B)の内容を取得しファイルに保存

先ほど、退避させておいたファイルから、データ登録(B)に該当する内容を特定します。
データ登録は、「2018-08-09 07:04:31」から「2018-08-09 07:14:39」の間に行っていたため、その間のログだけを残し、保存しておきます。

  • mysql_restore.sql

4.保存したファイルを実行させ、DBに反映

修正したSQLファイルを実行します。

実行後、データを確認します。

以上で、リカバリーできることが確認できました。


Oracle Cloud

 

Return Top