こちらは Aurora の Blue/Green デプロイで少し遊んでみた の続きです。
前回は、入口で大きく躓いて時間がなくなったため、Blue/Green 環境構築後のスイッチオーバーまで試すことができませんでした。
そのため、Green 環境を作成するところから再チャレンジしてみます。
5. Green 環境を再作成する
前回使った（元）Blue 環境のクラスタで再びブルー/グリーンデプロイを作成します。
Blue 環境に接続してみます。
Blue環境に接続
$ mysql -u admin -h my56.cluster-XXXX.ap-northeast-1.rds.amazonaws.com -p
（中略）
mysql> show processlist;
+----+----------+--------------------+------+---------+------+------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+----------+--------------------+------+---------+------+------------+------------------+
| 7 | rdsadmin | localhost | NULL | Sleep | 1 | cleaned up | NULL |
| 8 | rdsadmin | localhost | NULL | Sleep | 1 | cleaned up | NULL |
| 9 | rdsadmin | localhost | NULL | Sleep | 0 | cleaned up | NULL |
| 10 | rdsadmin | localhost | NULL | Sleep | 6 | cleaned up | NULL |
| 11 | admin | 172.31.40.50:52838 | NULL | Query | 0 | init | show processlist |
+----+----------+--------------------+------+---------+------+------------+------------------+
5 rows in set (0.00 sec)
特に何かのプロセスが走っているわけではなさそうです。
Blue環境のbinlog設定
mysql> call mysql.rds_show_configuration;
+------------------------+-------+------------------------------------------------------------------------------------------------------+
| name | value | description |
+------------------------+-------+------------------------------------------------------------------------------------------------------+
| binlog retention hours | NULL | binlog retention hours specifies the duration in hours before binary logs are automatically deleted. |
+------------------------+-------+------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
mysql> show binary logs;
+----------------------------+-----------+
| Log_name | File_size |
+----------------------------+-----------+
| mysql-bin-changelog.000001 | 120 |
| mysql-bin-changelog.000002 | 120 |
| mysql-bin-changelog.000003 | 120 |
+----------------------------+-----------+
3 rows in set (0.00 sec)
Blue 環境のbinlog retention hours は設定されていませんね。この状態では、クラスタを一時停止したときに binlog は保持されないので、Blue/Green 環境構築中にクラスタを一時停止できないのも分かります。
実際、一時停止から復帰した状態でSHOW BINARY LOGSすると binlog が存在しないのが分かります（Aurora MySQL v1 で binlog のファイルサイズが 120 バイトの場合、DDL・DML および行データは記録されていません）。
Green 環境作成中に Blue 環境にデータを追加してみる
このタイミングで Blue 環境に DB（スキーマ）とテーブルを作成し、データをINSERTしてみます。
Blue環境にデータを追加
mysql> create database bg_test;
Query OK, 1 row affected (0.02 sec)
mysql> use bg_test;
Database changed
mysql> create table test_table (id int primary key auto_increment, val int not null, str text);
Query OK, 0 rows affected (0.04 sec)
mysql> insert into test_table set val = 100, str = 'abcdefg';
Query OK, 1 row affected (0.01 sec)
mysql> insert into test_table set val = 110, str = 'ABCDEFG';
Query OK, 1 row affected (0.01 sec)
mysql> show binary logs;
+----------------------------+-----------+
| Log_name | File_size |
+----------------------------+-----------+
| mysql-bin-changelog.000001 | 120 |
| mysql-bin-changelog.000002 | 120 |
| mysql-bin-changelog.000003 | 952 |
+----------------------------+-----------+
3 rows in set (0.01 sec)
binlog にも記録されたようです。
Green 環境の作成が完了したらデータレプリケーションの成否を確認する
Green 環境に接続して確認します。
Green環境で確認
$ mysql -u admin -h my56-green-syojh1.cluster-XXXX.ap-northeast-1.rds.amazonaws.com -p
（中略）
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| bg_test |
| mysql |
| performance_schema |
| sakila |
+--------------------+
5 rows in set (0.01 sec)
mysql> use bg_test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+-------------------+
| Tables_in_bg_test |
+-------------------+
| test_table |
+-------------------+
1 row in set (0.00 sec)
mysql> select * from test_table;
+----+-----+---------+
| id | val | str |
+----+-----+---------+
| 1 | 100 | abcdefg |
| 2 | 110 | ABCDEFG |
+----+-----+---------+
2 rows in set (0.00 sec)
複製されていますね。
binlog レプリケーションも確認してみます。
レプリケーション確認
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.7.15.0
Master_User: rdsrepladmin
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin-changelog.000003
Read_Master_Log_Pos: 952
Relay_Log_File: relaylog.000005
Relay_Log_Pos: 1125
Relay_Master_Log_File: mysql-bin-changelog.000003
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table: mysql.rds_replication_status,mysql.rds_monitor,mysql.rds_sysinfo,mysql.rds_configuration,mysql.rds_history
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 952
Relay_Log_Space: 1464
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 2056585966
Master_UUID: 2d99a024-273f-3a6b-bdff-e4b44775b2f4
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
1 row in set (0.00 sec)
なぜかMaster_Hostが（Blue 環境の本来の IP アドレスとは全く別の）10.7.15.0になっていますね。
6. Green 環境をバージョンアップする
こちらも前回やったのですが、再び Aurora MySQL v2 にバージョンアップしてみます。
Green 環境バージョンアップ中に Blue 環境にデータを追加してみる
Blue 環境に接続し、データを追加します。
Blue環境にデータを追加
mysql> insert into test_table set val = 120, str = 'hijklmn';
Query OK, 1 row affected (0.01 sec)
mysql> insert into test_table set val = 130, str = 'HIJKLMN';
Query OK, 1 row affected (0.01 sec)
mysql> show binary logs;
+----------------------------+-----------+
| Log_name | File_size |
+----------------------------+-----------+
| mysql-bin-changelog.000001 | 120 |
| mysql-bin-changelog.000002 | 120 |
| mysql-bin-changelog.000003 | 1514 |
+----------------------------+-----------+
3 rows in set (0.00 sec)
Green 環境のバージョンアップが完了したらデータレプリケーションの成否を確認する
バージョンアップが完了したようです。
Green 環境に接続し、確認します。
Green環境でデータ確認
$ mysql -u admin -h my56-green-syojh1.cluster-XXXX.ap-northeast-1.rds.amazonaws.com -p
（中略）
mysql> use bg_test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> select * from test_table;
+----+-----+---------+
| id | val | str |
+----+-----+---------+
| 1 | 100 | abcdefg |
| 2 | 110 | ABCDEFG |
| 3 | 120 | hijklmn |
| 4 | 130 | HIJKLMN |
+----+-----+---------+
4 rows in set (0.00 sec)
複製されていました。
7. スイッチオーバーする
いよいよスイッチオーバーです。
その前に、Blue 環境に接続し、接続先インスタンスのバージョンを確認しておきます。
Blue環境でバージョン確認
$ mysql -u admin -h my56.cluster-XXXX.ap-northeast-1.rds.amazonaws.com -p
（中略）
mysql> select @@aurora_version;
+------------------+
| @@aurora_version |
+------------------+
| 1.23.4 |
+------------------+
1 row in set (0.01 sec)
1.23.4 ですね。
スイッチオーバーします。
タイムアウトの設定がありますね。
（「VPC」には VPC の ID ではなくてなぜかセキュリティグループの ID が表示されています）
レプリカ設定の詳細を開くと、Blue 環境と Green 環境の差異が表示されます。
スイッチオーバーが始まり、
数分待つと完了です…と思ったら不吉なメッセージが。なにこれこわい。
再読み込みしても画面の動きが不安定だったので、ブラウザでページを開き直しました。
切り替え完了です！
本番側のエンドポイントが入れ替わっていますね。
さて、先ほどの Blue 環境への接続で、バージョンを確認してみます。
Blue環境のバージョン再確認
mysql> select @@aurora_version;
ERROR 2013 (HY000): Lost connection to MySQL server during query
No connection. Trying to reconnect...
Connection id: 42
Current database: *** NONE ***
+------------------+
| @@aurora_version |
+------------------+
| 2.11.0 |
+------------------+
1 row in set (0.03 sec)
スイッチオーバー時に一度接続が切れていたので再接続されて、バージョン 2.11.0 に変わっていることが確認できました！
ちなみに、スイッチオーバー後、切り戻し方向のレプリケーションは設定されないようです。ちょっと残念ですが仕方がないところではあります。
旧Blue環境に接続して確認
$ mysql -u admin -h my56-old1.cluster-XXXX.ap-northeast-1.rds.amazonaws.com -p
（中略）
mysql> show slave status\G
Empty set (0.01 sec)
mysql> select @@read_only;
+-------------+
| @@read_only |
+-------------+
| 1 |
+-------------+
1 row in set (0.00 sec)
また、Writer インスタンスに接続されていますが、read_onlyは1になっていますね。
そして、スイッチオーバー後の旧 Blue 環境は一時停止可能なようです（フラグ？）。
8. ブルー/グリーンデプロイを削除する
スイッチオーバーが完了したので、ブルー/グリーンデプロイを削除します。
この後、一番下の「my56-stg」だけは消えましたが、いつまで経っても完了しません。
どうやら、旧 Blue 環境を一時停止したのがいけなかったようです（なぜアラートが出なかった？）。
旧 Blue 環境を起動し、手作業で各インスタンスを削除しました。
9. 続きは…
アドベントカレンダーで何か書 くかもしれません きました。