ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [RDS] MySQL 5.7 to 8.0 업그레이드 기록
    클라우드/AWS 2024. 7. 27. 15:59

    기억이 휘발되기 전에 기록을 정리해본다 ㅎ

     

    업그레이드 버전

    - 개발디비 : MySQL Community 5.7 ->  8.0

    - 운영 디비 : Aurora MySQL 5.7 -> 8.0

     

    업그레이드 순서

    1. 개발 디비, 운영 디비 시스템 스냅샷으로 미러링 방식으로 똑같이 복원

    2. 미러링 디비로 테스트 진행 

    3. 개발 디비 업그레이드 진행 (근무시간)

    4. 운영 디비 업그레이드 진행 (주말 새벽시간)

     

    크게 이 순서로 업그레이드 진행을 했다.

    RDS Extended Support 비용을 막기 위해 8.0 버전으로 올려야 했기 때문에 업그레이드를 진행했던것이었고, 중간에 장애도 나기도 했지만.. 결론적으로는 잘 마무리 됐다. (다음은 EKS 인데..깔깔)

     

    1) 개발 DB

    - 개발 디비는 크게 문제가 없었다. 

     

    1. 문제가 나면 즉각 롤백하기 위해 5.7 버전의 최종 스냅샷 생성 (약 5분소요)

    2. 업그레이드 진행

    - 엔진 버전은 latest 버전의 한 단계 낮은 버전인 8.0.36

    - 8.0 버전의 파라미터 그룹, 옵션 그룹 변경 (미리 만들어놨었고, 테스트 검증때 적용했던 그룹들)

    - 마이너 버전 자동업그레이드 미적용

    - cloudwatch log -> 슬로우 쿼리만 유지 (감사, 오류로그 제외)

    - gp2 -> gp3 타입으로 변경

     

    이정도로 설정하고 업그레이드 진행했음!

    순수 업그레이드 소요시간은 약 15분정도 걸렸고, gp2 -> gp3로 바꾸다 보니 스토리지 최적화가 정상화되는데는 시간이 걸렸다.

    하지만 서비스에는 문제가 없었기에, 업그레이드 완료 후 환경 세팅을 진행했다.

    고객사에서 테스트 디비로 검증했던 것처럼 똑같이 검증을 진행했다고 한다.

     

    2) 운영 DB

    - 업그레이드 자체에는 문제가 없었다. 업그레이드 전에 고객사에서 세팅을 진행했음

    - 운영 DB는 클러스터이기 때문에, 클러스터 파라미터 그룹/ 인스턴스 파라미터 그룹 미리 세팅이 필요했음 (기존에 테스트 완료)

    1. 최종 스냅샷 생성 (약 5분 소요)

    2. 파라미터 그룹 변경 (클러스터, 인스턴스) , 옵션 그룹은 변경이 불가능했음
    - 여기서 기존에 감사 로그 값 변경해주었다

    server_audit_logging : 0 -> 1
    server_audit_logs_upload : 0-> 1

    3. 업그레이드 진행 (약 25분 소요)

    - 메이저 버전의 기본값 8.0.32 로 진행

    - 파라미터 그룹 적용중으로 재부팅 진행 (약 2분)

     

    4.  서버 스크립트 및 fe 순차 배포 -> 고객사 진행 (약 60분)

     

    장애 발생

    업그레이드 완료 후 모니터링중..... 두번의 장애를 만났음

     

    1. api 호출 에러 발생

     

    max_prepared_stmt_count 값 변경

    -> 서버에서 동시에 유지할 수 있는 준비된 구문(prepared statements)의 최대 개수를 제어

    -> 너무 많이 올리면 메모리를 많이 쓰기때문에 적당히 올려야함

    -> 이 값을 기존 5.7 버전의 파라미터 값이랑 똑같이 맞춰줬더니 해결됐음

     

    2. connection pool 문제

     

    -  약 15분동안 cpu 90% 까지 치고, 연결 세션이 평소엔 10이하인데, 40이상을 기록해버렸다

    - connection_limit과 pool_timeout은 변경사항 없이 그대로인 상황, 얘는 문제가 아닌것 같았음

    - aurora_fwd_writer_max_connections_pct 얘 파라미터 값도 봤는데,, 얘는 리더 인스턴스로 받은 연결을 라이터로 넘겨서 쓰기 작업 필요한 연결을 넘기기 위한 기능이었음

    - cloudwatch 성능개선도우미를 키고, 상위 SQL 문을 살펴보았음

    -> 장애발생 시간대에 수상한 쿼리문이 많이 실행된걸 확인했다

    -> select문이고, 쿼리 호출하는 테이블에 인덱스 거는 방법 제안 (https://velog.io/@zunzero/AWS-RDS-%EC%84%B1%EB%8A%A5%EA%B0%9C%EC%84%A0%EB%8F%84%EC%9A%B0%EB%AF%B8 참고..)

     

    부하가 줄어든걸 확인했다. 그리고 이제는 장애가 발생하지 않는다...

    성능개선도우미...모니터링에 넘나 유용하다..

    정말 아찔했던 월요일이었다..! 

     

Designed by Tistory.