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 param
In particular, there are cases where the pending state persists despite not running out of CPU or memory. There is a case that it is due to lack of private ip.If the node group is shown as "Degraded" in the EKS cluster configuration and you can see the following error in Health issues. "Amazon Autoscaling was unable to launch instances because there are not enough free addresses in the subnet associated with your AutoScaling group(s)." And you can see that the number of "Available IP4 addresses" in the AWS VPC subnet used in the node group is 0. By designating the IP that the node group occupies, you can get some IPs back. kubectl set env -n kube-system daemonset/aws-node MINIMUM_IP_TARGET=10 WARM_IP_TARGET=2 kubectl get daemonset -n kube-system aws-node -o json | jq -r '.spec.template.spec.containers[] |select ( .name == "aws-node" ).env' You can see that the number of "Available IP4 addresses" in the AWS VPC subnet is increa