home
Rds 버전 업그레이드 후기
Mysql 5.x -> 8.x 업그레이드
- 10월 31일에 Aurora2가 EOL이 되어서 Aurora3로 업데이트를 한 뒤, 잊지 말아야할 것들을 정리
- 최근 진행했던 RDS MySQL 버전 업그레이드 과정에서 경험한 주요 이슈들과 해결 방안을 공유하려고 한다.
RDS MySQL 버전 업그레이드 시 중요 고려사항
클러스터 파라미터 그룹 관리의 중요성
파라미터 그룹 마이그레이션 시 주의점
- 버전 업그레이드 시 가장 중요한 점은 기존 클러스터의 커스터마이즈된 파라미터 설정값들을 새로운 버전의 파라미터 그룹에 정확히 반영하는 것이다.
- 이는 서비스의 정상 운영에 직접적인 영향을 미치는 요소다.
실제 발생 사례: 타임존 설정 미반영
- 본인의 경우는
time_zone = Asia/Seoul
파라미터 설정이 새 버전 업그레이드 과정에서 누락되어 심각한 문제가 발생했다.
- 클러스터의 시간대가 기본값인
UTC+0
으로 설정되어 운영 환경에 배포됨 - 레거시 코드의
SET TIMESTAMP
구문들이 잘못된 시간값으로 데이터를 기록함 - 결제 및 정산 관련 데이터의 시간 정확성 위험이 발생함
해결을 위한 다운타임 발생
- 타임존 설정 변경 후에는 클러스터 내 모든 인스턴스의 재부팅이 필요
- 특히 Writer 인스턴스의 재부팅은 서비스 다운타임으로 이어짐
- Blue-Green 배포 방식을 채택했다면 이러한 문제를 방지할 수 있었으나, 비용 절감을 위해 선택하지 않은 것이 결과적으로 더 큰 리스크를 초래했다.
업그레이드 롤백 문제 해결
- 개발 환경 DB 클러스터 업그레이드 중 지속적인 롤백 현상이 발생
- AWS는 이러한 문제 해결을 위한 로그 확인 방법을 제공하고 있다.
Aurora MySQL 주 버전 업그레이드 실패 원인 조사 - Amazon Aurora
문제 원인 분석
- 로그 분석 결과 다음과 같은 오류를 확인할 수 있었다:
"level": "Error",
"dbObject": "takemm.ticket",
"description": "Table `takemm.ticket` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
해당 오류는 이전 버전과 호환되지 않는 FULLTEXT 인덱스가 존재하는 것이 원인이었다.
해결 방안
- 문제 해결을 위해 다음과 같은 절차를 수행
- 테이블 데이터 백업
- 기존 테이블 삭제
- 새로운 테이블 생성
- 백업 데이터 복원
이러한 과정을 통해 성공적으로 업그레이드를 완료할 수 있었다.
결론
RDS MySQL 버전 업그레이드는 세심한 계획과 준비가 필요한 작업이다. 특히 파라미터 그룹 설정의 정확한 마이그레이션과 사전 호환성 검증이 중요하다. 또한, 운영 환경에서는 가능한 Blue-Green 배포 방식을 고려하여 리스크를 최소화하는 것이 바람직하다.
예약어 피하기
- 버전을 업그레이드 하면서 기존 코드에서 에러가 발생하는 일이 발생
rank
와 같은 예약어가 쿼리문에 존재하여 에러 발생
컬럼명에 써서 쿼리에 넣으면 에러가 날 수도 있는 예약어 모음
order
– 주문 테이블에서 자주 사용
rank
– 순위 관련 컬럼
desc
– description의 줄임말로 자주 사용
date
– 날짜 컬럼
time
– 시간 컬럼
timestamp
– 타임스탬프 컬럼
group
– 그룹 관련 컬럼
key
– 키 값 저장할 때
status
– 상태값 저장
default
– 기본값 관련
check
– 체크 관련
procedure
– 프로시저 관련
function
– 함수 관련
type
– 타입 지정
case
– 케이스 구분
table
– 테이블명으로 사용 시
column
– 컬럼 관련
index
– 인덱스 관련
primary
– 기본키 관련
foreign
– 외래키 관련
references
– 참조 관련
- 그냥 쓰고 ```` (백틱)을 사용해도 된다.
- 근데 그냥 쓰는 것 보다는 더 명확한 이름을 쓰는 게 좋을 것 같다.
- 추가로 테이블명은 복수형을 권장한다.