제로 다운타임을 위한 블루/그린 배포 사용법: RDS MySQL의 기본 키 업데이트

안녕하세요, DB 관리자를 위한 유용한 정보를 제공하는 블로거입니다. 오늘은 AWS RDS MySQL에서 제로 다운타임으로 기본 키를 업데이트하는 방법에 대해 설명드리겠습니다. 이 방법은 데이터베이스의 큰 테이블 구조를 수정해야 할 경우 특히 유용합니다.

블루/그린 배포란?

블루/그린 배포 전략은 애플리케이션을 위해 두 개의 개별적이고 동일한 환경을 생성하는 방법입니다. 현재 운영 중인 환경을 "블루"라고 하고, 수정 또는 새 버전을 포함하는 환경을 "그린"이라고 간주합니다. 이러한 지속적인 배포 방식은 데이터베이스 업데이트 시 최소한의 다운타임을 보장합니다.

환경 설정

이제 기본 키가 최대값에 가까워진 테이블을 레플리카 환경에서 변경하는 전 과정에 대해 다룹니다. 블루/그린 환경을 만들기 위해 먼저 Aurora 버전 및 클러스터 파라미터의 binlog_format를 row로 설정해야 합니다.

1. 블루/그린 환경 생성:

   • 배포 아웃헨 전환 메뉴에서 "블루/그린 배포 생성" 버튼을 선택합니다.
   • 배포 식별자를 설정하고, 환경 구성을 검토한 후 필요한 버전 변경을 수행해 주세요.

2. 노드 가용성 확인:

   • 녹색 환경의 모든 노드가 가용해질 때까지 기다립니다.

수정 과정 시작

이제 테이블을 수정할 준비가 되었습니다. 여기서는 컬럼의 데이터 유형을 int에서 bigint로 변경할 것입니다. 이 과정에서 레플리카의 일관성을 유지하기 위해 replica_type_conversions를 ALL_NON_LOSSY로 설정해야 합니다.

CALL mysql.rds_stop_replication;

테이블 정의 확인 및 컬럼 수정:

ALTER TABLE joinit DROP FOREIGN KEY joinit_ibfk_1;
ALTER TABLE joinit MODIFY COLUMN g bigint NOT NULL;
ALTER TABLE joinit_fk MODIFY COLUMN i bigint NOT NULL;
ALTER TABLE joinit ADD CONSTRAINT joinit_ibfk_1 FOREIGN KEY (g) REFERENCES joinit_fk (i) ON DELETE RESTRICT ON UPDATE CASCADE;

레플리케이션 재시작 및 스위치오버

모든 수정이 완료되면 레플리케이션을 다시 시작하고 스위치오버를 진행합니다. 스위치오버는 작업 버튼에서 "스위치오버" 옵션을 선택하여 수행할 수 있습니다.

결론

블루/그린 배포 전략을 사용하면 RDS 복제의 제약 때문에 발생할 수 있는 다운타임 문제를 해결할 수 있습니다. 이후 필요한 검증을 마치면 구 버전 노드를 삭제하여 환경을 완전히 정리할 수 있습니다.

더 궁금한 점이나 관련 링크는 AWS 공식 문서에서 확인하실 수 있습니다:

• 블루/그린 배포 가이드
• 블루/그린 배포 고려사항

감사합니다. 데이터베이스 관리에 있어 항상 성공을 기원합니다!