Amazon RDS Blue/Green Deployments

In order to avoid some errors I experienced when proceeding as described in the official

documentation, I describe what I did in order.

1) Modify parameters of source_database

* error: Blue Green Deployments requires cluster parameter group has binlog enabled.

RDS

Parameter groups: source-params-group

binlog_format => MIXED

mysql> show global variables like 'binlog_format';

2) Insert a row after rebooting the source database, to avoid this error.

* error: Correct the replication errors and then switch over.

Read Replica Replication Error - IOError: 1236, reason: Got fatal error 1236 from master

when reading data from binary log: 'Could not find first log file name in binary log index file'

=> To Fix: You need to change the data in the source database.

INSERT INTO dummy_table (`favorite_id`, `favorite_order`, `user_id`, `board_id`)

VALUES ('100001', '1', '11111', '11111');

3) Modify the parameters in the target database parameter group

The target database parameter group must be "binlog_format => MIXED".

4) Create Green cluster from Blue cluster

aws rds create-blue-green-deployment \

--blue-green-deployment-name source_database-bg \

--source arn:aws:rds:xxx:xxx:db:source_database\

--target-engine-version 5.7 \

--target-db-parameter-group-name source-params-group

4-1) Check two clusters

ex)

source_database Regional cluster (Blue)

- source_database Writer instance

=>

source_database-bg Blue/Green Deployment

- source_database-green-yyy Regional cluster (Green)

- source_database-green-xxx Writer instance

4-2) Check target database parameter group status

ex)

DB cluster parameter group

target database parameter group should have "binlog_format => MIXED"

Pending reboot

=> Need to reboot

5) Check Data Synchronization

=> Insert a row into the source database.

INSERT INTO dummy_table (`favorite_id`, `favorite_order`, `user_id`, `board_id`)

VALUES ('100003', '1', '11111', '11111');

=> Check in target database

SELECT * FROM dummy_table where favorite_id in (100001, 100003);

If sync doesn't work, Switch-over will be failed.

6) Switch-over

Run default 5 minutes

7) Clean-up

After conversion, Blue/Green Deployments do not delete the old production environment.

You can access the old production environment for further validation and performance/

regression testing if needed.

To check whether there is no interruption, query the db every second and record the result

in elasticsearch.

Access to the existing db was stopped for about 1 minute, but at that point, it was

determined that the endpoint of the app was switched to a new db, not the existing db

(therefore, there may be a momentary in-app service stop)

Test result)

-. Endpoints are automatically switched to the new db, so there is no need to change the app.

-. If a problem occurs when switching over in the middle,

it does not proceed and the service is maintained with the existing db (no effect)

-. Right after the start of the 5-minute switch over,

the existing db is converted to readonly (therefore, a server operation notice is required)

-. Connection of existing db may be interrupted (less than 1 minute)