당신이 시도하는 패턴은 다음과 같습니다 앱을 current_db에 기록
- 동안, next_db는 새로운 인덱스를 구축하는 파괴적인 작업을 수행합니다. next_db는 ... 잡는다되면
- [어려운] 안전하게
- 가 이전 마스터를 오프라인 (또는 재 구축하거나 인덱스를 추가, 또는 무엇이든, 지금 불필요한입니다)
next_db하는 current_db에서 응용 프로그램 트래픽을 전환
MySQL을 사용하면 2 단계에 대해 신중을 기해야합니다. 특히 앱이 2 이상의 인스턴스에서 실행되는 경우 특히주의해야합니다. 앱 계층의 일부가 current_db에 쓰고 앱의 일부가 next_db에 쓰는 경우 조심하지 않으면 안 좋은 일이 발생할 수 있습니다.
- 3 초 컷오프 : current_db에 대한 모든 쓰기를 중지하고 next_db가 완전히 복제되었는지 확인한 후 next_db에 쓰기를 시작합니다. next_db가 hot이고 ready 인 경우,이 cut-over 간격은 입력하는 속도에 따라 1-3 초의 "중단 시간"을 초래합니다.
- 가동 중지 시간 없음 : 2 개의 db 인스턴스 작성 작성시 DB 디자인에주의해야합니다. MySQL의 가장 중요한 문제는 두 개의 db 인스턴스에서 자동으로 증가하는 행 ID에 홀수와 짝수 번호를 사용하는 것입니다. 그렇지 않으면 두 DB 인스턴스 모두 동일한 ID를 가진 새로운 DB 행을 생성하게됩니다! 나쁜 상태! 데이터 손상!
불행히도 RDS 읽기 복제본 승격은 제로 다운 타임 스키마를 수행하는 데 충분하지 않은 것으로 보입니다. 다음은 RDS 문서에서 읽기 복제본 승격에 대한 내용입니다.
승격 프로세스를 완료하는 데 몇 분이 걸립니다. 읽기 복제본을 승격하면 복제가 중지되고 읽기 복제본이 으로 재부팅됩니다. 재부팅이 완료되면 단일 AZ 데이터베이스 인스턴스로 읽기 복제본을 사용할 수 있습니다 ( ).
제로 다운 타임을위한 트릭이 아닙니다. 그러나 그 메커니즘을 사용하여 "Three [Minute] Cutover"업데이트를 안전하게 수행 할 수 있습니다. 슬프게도 재부팅 때문에 분이 걸립니다.
- 읽기 복제본을 추가하고
- 마크가 쓰기 가능 (link) - 복제를 읽고 DB ROW 업데이트를 보내하지 마십시오 전달 호환 스키마 업데이트를 [적용 마스터에 잡을 수 있도록 방법은 다음과 같습니다! ]
- 오래된 마스터에 대한 트래픽을 중지 (b/c 복제가 거의 끝남)합니다. 앱이 지원하면이 시간 동안 읽기 전용 모드로 실행되거나 대기열에 스풀 쓰기가 가능합니다.
- 홍보 복제본 (link)은 ~ 3 분이 소요됩니다.
- 승격 한 새 DB 인스턴스에서 앱을 가리 키십시오.
- 앱이 정상적으로 작동하는지 확인합니다 (1 시간이 지나면 편집증에 걸릴 수 있음).
- 오래된 DB 인스턴스를 삭제합니다. 당신이 진정으로 "다운 타임이없는"업데이트를하려면
, 당신은 조사해야합니다 : http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html
최종 단어 : 당신이해야 할 선택하든, 나는의 모의 버전으로 한 번 연습을 권하고 싶습니다 당신의 당신의 라이브 시스템에서 그것을 시도하기 전에 응용 프로그램! :-)
해당 색인이 마스터 RDS에 있습니까? – error2007s
아니요, 마스터에 없습니다. – Michael
실행중인 버전을 모르지만이 모든 문제는 완전히 불필요 할 수 있습니다 ... MySQL 5.6에서는 테이블을 잠그지 않고 인덱스를 추가 할 수 있습니다. –