はじめに
今回は、Oracle MySQL Cloud Serviceを検証しながら嵌ったこと＆その解決方法について書いてみたいと思います。
嵌ったこと
１．Oracle Cloud パスワードを変更した際は、バックアップに注意！
２．ストレージがいっぱい！
３．Point-in-Time リカバリーにはできる／できないパターンが存在する？！
同じことで嵌っている方、いらっしゃいませー！
では早速、見ていきましょう。
１．Oracle Cloud パスワードを変更した際は、バックアップに注意！
Oracle Cloudのパスワードを変更した後、バックアップの設定を変える際や、バックアップを行う際、エラーが起こりました。
実際のエラー内容は、下記の通りです。
a．バックアップの再有効化時、「SM-BKP-5021」エラー
|
1 2 3 4 |
2018/04/25 2時58分11秒 UTC Activity Submitted 2018/04/25 2時58分11秒 UTC Activity Started 2018/04/25 2時58分11秒 UTC SM-BKP-5021: The credentials and storage container for accessing Object Storage are incorrect. Response code returned: 401. Update credentials or storage container and try again. 2018/04/25 2時58分11秒 UTC Activity Ended |
b．バックアップ時、「SM-BKP-5106」エラー
|
1 2 3 4 5 6 7 8 |
2018/04/25 18時30分03秒 UTC Activity Submitted 2018/04/25 18時30分03秒 UTC Activity Started 2018/04/25 18時37分11秒 UTC Backup process failed during backup. 2018/04/25 18時39分11秒 UTC SM-BKP-5106: Operation failed and will be retried. 2018/04/25 20時19分48秒 UTC Backup process failed during backup. 2018/04/25 20時21分48秒 UTC SM-BKP-5106: Operation failed and will be retried. 2018/04/25 22時01分37秒 UTC Backup process failed during backup. 2018/04/25 22時01分38秒 UTC Activity Ended |
■原因
バックアップ用のストレージ・クラウドのパスワードを更新していなかったため、起こっていました。
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
パスワード有効期限は、「設定」メニュー → 「パスワード・ポリシーの変更」画面 → 「有効期限」の方で変更可能ですので、下記のマニュアル、もしくは、チュートリアルをご覧になってください。
- マニュアル：Administering Oracle Identity Cloud Service – Modifying the Custom Password Policy
- チュートリアル：「Customize the password policy」→「6. Customize the password policy」
２．ストレージがいっぱい！
大量のデータ作成をしていましたが、エラーが発生し、動かなくなりました。
|
1 2 |
mysql> INSERT INTO users_info( users_id, name, address, email, memo) SELECT num+1, CONCAT("山田 太郎", num+1), CONCAT("大阪府大阪市○○○", num+1), CONCAT("user_", num+1, "@example.com"), CONCAT("メモ△△△×××○○○□□□", num+1) FROM foo; ERROR 1114 (HY000): The table 'users_info' is full |
再度、TeraTermで接続をしてみても、なかなか下記の画面から進まず。
■原因
やっと表示されましたが、MySQL InformationのStatusがNOT RUNNINGになっています。
確認すると、「data」ストレージがいっぱいになっていました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
******************************************************************************** * Welcome to * * MySQL Cloud Service * * by * * Oracle * * If you are an unauthorised user please disconnect IMMEDIATELY * ******************************************************************************** ******************************* MySQL Information ****************************** * Status: NOT RUNNING ******************************************************************************** ************************** Storage Volume Information ************************** * Volume Used Use% Available Size Mounted on * * MySQLlog 11G ------ 20% 46G 59G /u01/translog * * backup 1.3G -- 3% 46G 50G /u01/backup * * bin 3.0G -------- 32% 6.3G 9.8G /u01/bin * * data 24G ---------------------- 100% 0 25G /u01/data * ******************************************************************************** [opc@XXXXX-mysql2-mysql-1 ~]$ |
動かなかったので、いったん、再起動してみました。すると、67％まで減りました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
******************************************************************************** * Welcome to * * MySQL Cloud Service * * by * * Oracle * * If you are an unauthorised user please disconnect IMMEDIATELY * ******************************************************************************** ******************************* MySQL Information ****************************** * Status: RUNNING * * Version: 5.7.21 * ******************************************************************************** ************************** Storage Volume Information ************************** * Volume Used Use% Available Size Mounted on * * MySQLlog 11G ------ 20% 46G 59G /u01/translog * * backup 1.3G -- 3% 46G 50G /u01/backup * * bin 3.0G -------- 32% 6.3G 9.8G /u01/bin * * data 16G --------------- 67% 7.9G 25G /u01/data * ******************************************************************************** [opc@XXXXX-mysql2-mysql-1 ~]$ |
■解決策
ストレージを追加します。
インスタンスのInstance Overview → Resorcesのアクションメニュー →「 Add Storage」選択します。
表示された「Add Storage」画面で「使用可能なデータベース・ストレージ」を入力し、「Yes, Add Storage」ボタンを押下します。
※入力した値は、現状のストレージ・サイズより追加されるサイズではなく、変えたいストレージ・サイズです。現状25GBで、25GBを追加した場合は、50GBを入力します。なお、現状より小さい値は入力できません。
３．Point-in-time リカバリーにはできる／できないパターンが存在する？！
この前のバックアップ＆リストア編を書きながら、当初検証として考えていたパターンの何パターンが、Point-in-Time リカバリーに失敗していました。
■検証パターン
その内の一つが下記のパターンです。
- インスタンスを作成 → データ登録(A) → オンデマンド・バックアップ（full）→ データ登録(B) → データ削除 → 削除する前の時点（データ登録(B)登録後）へPoint-in-Time リカバリーを実施
- データ登録
テーブルを作成し、10分間、1秒ごとにデータを挿入
※登録及び確認方法は、「バックアップ＆リストア-【１．データ登録】」を参照してください。 - オンデマンド・バックアップ：Available Backupsのアクションメニュー → Backup now
※実行方法は、「バックアップ＆リストア-【８．オンデマンド・バックアップの実施】」を参照してください。 - Point-in-Time リカバリー（以下、PITR）：Available Backupsのアクションメニュー → Restore Instance
※実行方法は、「バックアップ＆リストア-【６．過去のある時点へのリストア実施】」を参照してください。
- データ登録
エラー内容は、下記の通りです。
|
1 2 3 4 5 |
2018/08/09 7時25分24秒 UTC Activity Submitted 2018/08/09 7時25分24秒 UTC Activity Started 2018/08/09 7時25分24秒 UTC Submitted the restoration precheck for remote execution 2018/08/09 7時25分34秒 UTC No scheduled full backup found for recovery time. 2018/08/09 7時25分34秒 UTC Activity Ended |
■原因
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に反映させる方法です。
計画は下記の通りです。
１．バイナリログの退避（mysqlbinlog使用）
２．フルバックアップへリストアを実施（データ登録Bの直後の状態に戻る）
３．退避させておいたバイナリログからデータ登録(B)の内容を取得しファイルに保存
４．保存したファイルを実行させ、DBに反映
ここから下は、おまけです。
実際に計画を実施し、PITRしてみました。
０．データ状況確認
- インスタンスを作成 → データ登録(A) の直後
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
mysql> select count(*) from test_backup; +----------+ | count(*) | +----------+ | 600 | +----------+ 1 row in set (0.01 sec) mysql> select * from test_backup order by id limit 5; +----+--------------------+---------------------+ | id | text | reg_date | +----+--------------------+---------------------+ | 1 | データ登録(A) | 2018-08-09 06:38:18 | | 2 | データ登録(A) | 2018-08-09 06:38:19 | | 3 | データ登録(A) | 2018-08-09 06:38:20 | | 4 | データ登録(A) | 2018-08-09 06:38:21 | | 5 | データ登録(A) | 2018-08-09 06:38:22 | +----+--------------------+---------------------+ 5 rows in set (0.00 sec) mysql> select * from test_backup order by id desc limit 5; +-----+--------------------+---------------------+ | id | text | reg_date | +-----+--------------------+---------------------+ | 600 | データ登録(A) | 2018-08-09 06:48:26 | | 599 | データ登録(A) | 2018-08-09 06:48:25 | | 598 | データ登録(A) | 2018-08-09 06:48:24 | | 597 | データ登録(A) | 2018-08-09 06:48:23 | | 596 | データ登録(A) | 2018-08-09 06:48:22 | +-----+--------------------+---------------------+ 5 rows in set (0.00 sec) |
- インスタンスを作成 → データ登録(A) → オンデマンド・バックアップ（full）→ データ登録(B) の直後
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
mysql> select count(*) from test_backup; +----------+ | count(*) | +----------+ | 1200 | +----------+ 1 row in set (0.00 sec) mysql> select * from test_backup where id > 600 order by id limit 5; +-----+--------------------+---------------------+ | id | text | reg_date | +-----+--------------------+---------------------+ | 601 | データ登録(B) | 2018-08-09 07:04:31 | | 602 | データ登録(B) | 2018-08-09 07:04:32 | | 603 | データ登録(B) | 2018-08-09 07:04:33 | | 604 | データ登録(B) | 2018-08-09 07:04:34 | | 605 | データ登録(B) | 2018-08-09 07:04:35 | +-----+--------------------+---------------------+ 5 rows in set (0.00 sec) mysql> select * from test_backup where id > 600 order by id desc limit 5; +------+--------------------+---------------------+ | id | text | reg_date | +------+--------------------+---------------------+ | 1200 | データ登録(B) | 2018-08-09 07:14:39 | | 1199 | データ登録(B) | 2018-08-09 07:14:38 | | 1198 | データ登録(B) | 2018-08-09 07:14:37 | | 1197 | データ登録(B) | 2018-08-09 07:14:36 | | 1196 | データ登録(B) | 2018-08-09 07:14:34 | +------+--------------------+---------------------+ 5 rows in set (0.00 sec) |
- インスタンスを作成 → データ登録(A) → オンデマンド・バックアップ（full）→ データ登録(B) → データ削除の直後
|
1 2 3 4 5 6 7 8 9 10 |
mysql> delete from test_backup; Query OK, 1200 rows affected (0.01 sec) mysql> select count(*) from test_backup; +----------+ | count(*) | +----------+ | 0 | +----------+ 1 row in set (0.00 sec) |
１．バイナリログの退避（mysqlbinlog使用）
リストアを実施すると、バイナリログが空になってしまうので、事前にバイナリログを退避しておきましょう。
※バイナリログを利用し、PITRする方法ついては下記のマニュアルに詳しく説明されていますので、参照してください。
Point-in-Time (Incremental) Recovery Using the Binary Log
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
[oracle@pitrtest-mysql-1 inno-bin-logs]$ pwd /u01/translog/inno-bin-logs [oracle@pitrtest-mysql-1 inno-bin-logs]$ ll total 6299508 -rw-r----- 1 oracle oracle 1073741824 Aug 9 07:23 ib_logfile0 -rw-r----- 1 oracle oracle 1073741824 Aug 9 06:28 ib_logfile1 -rw-r----- 1 oracle oracle 1073741824 Aug 9 06:28 ib_logfile2 -rw-r----- 1 oracle oracle 1073741824 Aug 9 06:28 ib_logfile3 -rw-r----- 1 oracle oracle 1073741824 Aug 9 06:28 ib_logfile4 -rw-r----- 1 oracle oracle 1073741824 Aug 9 06:28 ib_logfile5 -rw-r----- 1 oracle oracle 177 Aug 9 06:28 pitrtest-mysql-1.000001 -rw-r----- 1 oracle oracle 8211780 Aug 9 07:23 pitrtest-mysql-1.000002 -rw-r----- 1 oracle oracle 104 Aug 9 06:28 pitrtest-mysql-1.index [oracle@pitrtest-mysql-1 inno-bin-logs]$ mysqlbinlog pitrtest-mysql-1.000002 > /tmp/mysql_restore.sql |
２．オンデマンド・バックアップからリストアを実施（データ登録Bの直後の状態に戻る）
フルバックアップからリストアを実施します。
※実行方法は、「バックアップ＆リストア-【１０．特定のバックアップからのリストア実施】」を参照してください。
では、データを確認してみましょう。
「データ登録（A）」の登録後と同じであることが確認できました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
mysql> select count(*) from test_backup; +----------+ | count(*) | +----------+ | 600 | +----------+ 1 row in set (0.00 sec) mysql> select * from test_backup order by id limit 5; +----+--------------------+---------------------+ | id | text | reg_date | +----+--------------------+---------------------+ | 1 | データ登録(A) | 2018-08-09 06:38:18 | | 2 | データ登録(A) | 2018-08-09 06:38:19 | | 3 | データ登録(A) | 2018-08-09 06:38:20 | | 4 | データ登録(A) | 2018-08-09 06:38:21 | | 5 | データ登録(A) | 2018-08-09 06:38:22 | +----+--------------------+---------------------+ 5 rows in set (0.00 sec) mysql> select * from test_backup order by id desc limit 5; +-----+--------------------+---------------------+ | id | text | reg_date | +-----+--------------------+---------------------+ | 600 | データ登録(A) | 2018-08-09 06:48:26 | | 599 | データ登録(A) | 2018-08-09 06:48:25 | | 598 | データ登録(A) | 2018-08-09 06:48:24 | | 597 | データ登録(A) | 2018-08-09 06:48:23 | | 596 | データ登録(A) | 2018-08-09 06:48:22 | +-----+--------------------+---------------------+ 5 rows in set (0.00 sec) |
リストア後、バイナリログフォルダを確認してみると、全部なくなっています。
|
1 2 |
[oracle@pitrtest-mysql-1 inno-bin-logs]$ ll total 0 |
３．退避させておいたバイナリログからデータ登録(B)の内容を取得しファイルに保存
先ほど、退避させておいたファイルから、データ登録（B）に該当する内容を特定します。
データ登録は、「2018-08-09 07:04:31」から「2018-08-09 07:14:39」の間に行っていたため、その間のログだけを残し、保存しておきます。
- mysql_restore.sql
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 |
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/; /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; DELIMITER /*!*/; # at 4 #180809 6:28:35 server id 1 end_log_pos 123 CRC32 0x38d05b11 # Warning: this binlog is either in use or was not closed properly. ROLLBACK/*!*/; BINLOG ' E99rWw8BAAAAdwAAAHsAAAABAAQANS43LjIyLWVudGVycHJpc2UtY29tbWVyY2lhbC1hZHZhbmNl ZC1sb2cAAAAAAAAAAAAT32tbEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA ARFb0Dg= '/*!*/; ################################################################### #（上の１２行目までは、メタ情報とイベントフォーマットであるため、残しておきます。 # その下の内容は、「データ登録（A）」の内容であるため、削除します） ################################################################### # at 7958259 #180809 7:04:31 server id 1 end_log_pos 7958324 CRC32 0x687c1693 /*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/; SET @@SESSION.GTID_NEXT= '6e2bdfbb-9b9d-11e8-ae94-c6b05a306347:623'/*!*/; # at 7958324 #180809 7:04:31 server id 1 end_log_pos 7958410 CRC32 0x2fe522ef SET TIMESTAMP=1533798271/*!*/; BEGIN /*!*/; # at 7958410 # at 7958511 #180809 7:04:31 server id 1 end_log_pos 7958576 CRC32 0xc9037b22 # at 7958576 #180809 7:04:31 server id 1 end_log_pos 7958640 CRC32 0x172b8d65 BINLOG ' f+drWxMBAAAAQQAAADBweQAAAHUAAAAAAAEACm15ZGF0YWJhc2UAC3Rlc3RfYmFja3VwAAMDDxID yAAAACJ7A8k= f+drWx4BAAAAQAAAAHBweQAAAHUAAAAAAAEAAgADB/hZAgAAEuODh+ODvOOCv+eZu+mMsihCKZmg knEfZY0rFw== '/*!*/; ################################################################### #（省略・・・） ################################################################### # at 8205047 #180809 7:14:39 server id 1 end_log_pos 8205112 CRC32 0x6944c3be /*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/; SET @@SESSION.GTID_NEXT= '6e2bdfbb-9b9d-11e8-ae94-c6b05a306347:1222'/*!*/; # at 8205112 #180809 7:14:39 server id 1 end_log_pos 8205198 CRC32 0xb86d252a SET TIMESTAMP=1533798879/*!*/; BEGIN /*!*/; # at 8205198 # at 8205299 #180809 7:14:39 server id 1 end_log_pos 8205364 CRC32 0xe342becc # at 8205364 #180809 7:14:39 server id 1 end_log_pos 8205428 CRC32 0xff348cf0 BINLOG ' 3+lrWxMBAAAAQQAAADQ0fQAAAHUAAAAAAAEACm15ZGF0YWJhc2UAC3Rlc3RfYmFja3VwAAMDDxID yAAAAMy+QuM= 3+lrWx4BAAAAQAAAAHQ0fQAAAHUAAAAAAAEAAgADB/iwBAAAEuODh+ODvOOCv+eZu+mMsihCKZmg knOn8Iw0/w== '/*!*/; # at 8205428 #180809 7:14:39 server id 1 end_log_pos 8205459 CRC32 0x436f6c38 COMMIT/*!*/; ################################################################### #（「データ削除」の内容であるため、削除します） ################################################################### COMMIT/*!*/; SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/; DELIMITER ; # End of log file /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/; /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/; |
４．保存したファイルを実行させ、DBに反映
修正したSQLファイルを実行します。
|
1 |
mysql -u root -p mydatabase < /tmp/mysql_restore.sql |
実行後、データを確認します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
mysql> select count(*) from test_backup; +----------+ | count(*) | +----------+ | 1200 | +----------+ 1 row in set (0.00 sec) mysql> select * from test_backup order by id limit 5; +----+--------------------+---------------------+ | id | text | reg_date | +----+--------------------+---------------------+ | 1 | データ登録(A) | 2018-08-09 06:38:18 | | 2 | データ登録(A) | 2018-08-09 06:38:19 | | 3 | データ登録(A) | 2018-08-09 06:38:20 | | 4 | データ登録(A) | 2018-08-09 06:38:21 | | 5 | データ登録(A) | 2018-08-09 06:38:22 | +----+--------------------+---------------------+ 5 rows in set (0.00 sec) mysql> select * from test_backup order by id desc limit 5; +------+--------------------+---------------------+ | id | text | reg_date | +------+--------------------+---------------------+ | 1200 | データ登録(B) | 2018-08-09 07:14:39 | | 1199 | データ登録(B) | 2018-08-09 07:14:38 | | 1198 | データ登録(B) | 2018-08-09 07:14:37 | | 1197 | データ登録(B) | 2018-08-09 07:14:36 | | 1196 | データ登録(B) | 2018-08-09 07:14:34 | +------+--------------------+---------------------+ 5 rows in set (0.00 sec) |
以上で、リカバリーできることが確認できました。
