MySQL 8.0 버전 업그레이드 테스트 및 블루그린 배포 성공 사례

mysql 버전 업그레이드를 위해 수집한 방법들을 여러 환경의 DB에 각각 적용해서 테스트 해보기로 했으며 테스트 후 결과를 공유하고 가장 마음에 드는 방식으로 진행 하기로 했습니다.

🚀 TEST 계획

---

AWS RDS 블루/그린 배포 사용 공식 문서

1. LOCAL

• 쿠버네티스에 띄워져있는 mysql 8.3 POD에 신규(8.0버전) DB 생성
• 기존 5.7 버전 DB 에서 dump한 sql 파일을 신규 DB에 적용

2. DEV (In-Place)

• 인스턴스 수정방식 적용

3. STAGING (Blue/Green)

• 기존 서버(블루) binlog_format mixed로 변경 → 변경사항 적용 위해 재부팅 필요, 2분정도 다운 발생
  • 업그레이드 하려는 DB 인스턴스는 이미 켜져있어 따로 작업 필요하지 않음.
• 업그레이드 버전에 적용할 파라미터 그룹 생성
  • 업그레이드 하려는 서버는 SQLMODE 중 ONLY_FULL_GROUP_BY를 제거 하지 않으면 에러 발생하므로 제거
• 그린 생성 및 테스트
  • 그린 생성시 미리 생성한 클러스터 파라미터 그룹 선택
• 그린 승격
• 블루 삭제

🚀 블루/그린 배포 성공 사례 수집

---

1. 클라우드게이트 RDS, 셀러게이트 RDS 업데이트 사례

   1. 총 6시간 소요
   2. 파라미터 그룹에서 charset 설정을 안해줬을때 데이터가 ? 로 저장되는 이슈
   3. aws 에서 메이저업그레이드 시 upgrade-precheck를 해준다고 함 → 에러발생 시 로그 확인가능

2. 여기어때 블로그

   1. *Aurora MySQL 2.11.2 to 3.04.1(MySQL* 8.0.28과 호환) 메이저 업그레이드 기준
   2. 블루에 적용되어 있는 클러스터 IAM Role은 그린으로 복제되지 않음. 블루 환경에 별도의 롤을 부여해 사용하고 있다면 그린에 추가해야 함
   3. 작업시간 및 작업준비에 필요한 시간을 1시간에서 5분 미만으로 약 90%이상 감소
   4. 운영환경 테스트 방법 - 가중치 기반 라우팅으로 9:1로 트래픽 분산

3. 블루/그린 배포를 이용한 Aurora MySQL 버전 무중단 업그레이드 경험 공유

   1. 새 파라미터 그룹을 생성 , binlog_format의 값을 ROW 로 설정 후 쓰기 인스턴스를 재부팅 재부팅 후 쓰기 인스턴스가 정상으로 돌아오기 까지는 약 2분 정도의 다운타임이 발생.
   2. 활성화 밑 재부팅 후 데이터베이스에 쓰기가 적어도 한 번은 발생해야 한다
   3. 그린 스테이징 생성 시 50기가 1시간 소요 → 데이터량이 많다면 적어도 교체 하루 전에 그린 배포를 생성하는 것을 권장
   4. 전환 시간의 기본 값은 300초이며, 30~3600초 사이로 조정 가능

4. Aurora 업데이트 사례

   1. 블루 쪽 클러스터 파라미터에 bin log 옵션이 MIXED로 켜져있어야 블루 ↔ 그린 싱크가능
   2. bin log 기본 옵션이 Fasle 이기때문에 설정 후 재부팅이 필요함
   3. binlog 사용시 데이터 베이스의 성능의 3~40% 정도가 감소한다고 하는데 다른 후기에선 크게 문제되지 않는다고 한다.
   4. RDS 블루그린배포 기능의 베타 버전때 적용한 사례

🚀 정리

---

• 그린 스테이징 생성 시 50기가 1시간 소요
• 전환 시점에 두 환경을 read_only=true 로 설정해 두지 않으면 이슈 발생함.
• 사례 중 파라미터 그룹에서 charset 설정을 안하고 default 일 때 데이터가 ? 로 저장되는 이슈
• 파라미터그룹에 binlog가 MIXED로 설정 되어있어야 한다와 ROW로 설정 되어있어야 한다는 의견이 엇갈리고 있다.
• 블루그린 배포는 T3 medium 이상만 지원한다는 글이 있음
  • 테스트 결과 T3 small 사이즈에서도 가능 한 것이 확인 되었다. aurora 한정 이거나 추후에 AWS 측에서 지원을 해준 것으로 보인다.