끈질 기게 Amazon RDS 테스트 해 보았다 - Multi-AZ & Read Replica

아직해야 하나 인 Amazon RDS 검증 l. 아마 이것으로 마지막.

구성과하고 싶은 일
· 마스터는 Multi-AZ에서 오류가 발생하면 장애 조치한다.
· 위를 마스터로 리드 복제본을 만들 수 있습니다. 마스터 전환시의 동작을 확인한다.
페일 오버했을 때 Read Replica 복제를 중지하는 경우가 있다고해서 그 근처를 검증 해보고 싶다.

검증 절차
1. Multi-AZ에서 DB 인스턴스를 새로 시작합니다.

2. DB에 연결하여 테스트 테이블 작성. 클라이언트에서 업데이트 쉘을 흘린다.

3. 리드 복제 만들었습니다. 작성 후 업데이트가 동기화되어 있는지 확인합니다. 이외에 show slave status 실행.

4. 마스터를 다시 시작하여 장애 조치를 발생시킨다.

5. 리드 복제가 참조하는 대상과 업데이트 동기화 확인 및 show slave status 실행.

이후 해본 결과
1. 2. 대해서는 정상적으로 운영.
마스터 존 ap-northeast-1c 만들어진 복제는 ap-northeast-1b이었다.
3. 업데이트 동기화도 문제 없음. 이것은 이전 게시물시의 테스트에서도 확인이 끝난 상태.

다음 복제에서 SHOW SLAVE STATUS 결과입니다.

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event
Master_Host: rdsmaster.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com
Master_User: rdsrepladmin
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin-changelog.000011
Read_Master_Log_Pos: 4593
Relay_Log_File: relaylog.000008
Relay_Log_Pos: 4515
Relay_Master_Log_File: mysql-bin-changelog.000011
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
　　　　:
　　　　skip
　　　　:
Master_Server_Id: 1020329100

마스터에서 재부팅을 건다. 다음 재부팅 직후의 업데이트 상태.

:
:
99 dummy 2013-01-03 01:29:30
100 dummy 2013-01-03 01:29:40
101 dummy 2013-01-03 01:29:50
102 dummy 2013-01-03 01:30:00
103 dummy 2013-01-03 01:30:10
104 dummy 2013-01-03 01:30:20
105 dummy 2013-01-03 01:30:30
106 dummy 2013-01-03 01:30:41
107 dummy 2013-01-03 01:30:51　←여기서 멈췄다.

장애 조치 중에 약간 연결할 수없는 시간대가 있었지만 얼마 지나지 않아 연결을 재개했다.
이벤트 로그에서 31:45에 Complete가 있지만, 33 : 52 직후에 연결 가능 해졌다 때문에 실제 소요 시간은 역시 3 분 정도.

ERROR 2003 (HY000): Can’t connect to MySQL server on ‘rdsmaster.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com’ (111)

장애 조치 후 마스터 영역은 c에서 b로 바뀌고 복제 존과 같은되었다.
영역을 분리하고 생각해도,이 컨트롤은 이용자 측에서는없는 거지 ....

장애 조치시 업데이트 상황이지만, Multi-AZ 간 장애 조치의 경우 클라이언트에서 업데이트를 허용하지 그대로 멈춰 버리기 때문에 복제본에 동기화 인계가 어떻게 될지 알 수 없었다. 장애 조치 후 업데이트를 수동으로 다시 시작했는데 문제없이 동기화 잡힌, 이것은 가정에서.

참고로 다음 마스터 장애 조치 후 복제본에서 SHOW SLAVE STATUS.
두 번째 줄 Master_Host 엔드 포인트가 당초와 동일한 것은 당연하지만, 마지막 Master_Server_Id도 변하지 않았다. 또한 장애 조치시 교체한다? ? ?

*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event
Master_Host: rdsmaster.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com
Master_User: rdsrepladmin
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin-changelog.000014
Read_Master_Log_Pos: 3647
Relay_Log_File: relaylog.000014
Relay_Log_Pos: 3803
Relay_Master_Log_File: mysql-bin-changelog.000014
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
　　　　:
　　　　skip
　　　　:

Master_Server_Id : 1020329100 ← 장애 조치 이전과 다르지 않다

장애 조치시 데이터 업데이트가 멈추지 않는 사양에서 테스트 있다면 다행이지만, 이번은 단념. 업데이트를 수동으로 재개 후 복제가 참조를 이어 성공적으로 동기화를 취할 것만은 알았다.

업데이트의 무결성 내용은 sync_binlog = 1로두면 문제없이 실행되는 것이 아닌가? 추측한다. 어디 까지나 추측이지만. 참고로이 값은 RDS를 기본적으로 0하지만 1로 변경 위에 테스트하고있다. 복제시는 sync_binlog은 1, 무조건 1! 발상이 배어있는 걸로 ...