RDS Aurora PostgreSQL 버전 업그레이드 하기

Jihun Kim·2022년 1월 11일
0

기타

목록 보기
1/12
post-thumbnail

현재 Aurora PostgreSQL 버전 11.6을 사용중인데, 최근 아마존으로부터 Aurora 버전 업그레이드 요청이 왔다.

아마존에 따르면, 더이상 버전 11.6을 지원하지 않을 것이라고 한다. 3월 중에 강제로 버전을 올릴 예정이라고 하는데 그러면 서비스 운영 중에 문제가 생길 수 있으니 그 전에 알아서 서비스에 지장을 주지 않는 시기와 방법을 통해 업그레이드를 진행해야 한다는 과제가 생겼다.

업그레이드를 하기에 앞서, 몇 가지 확인해야 하는 사항들이 있었다.


확인 사항

엔진 정보가 무얼 의미할까?

  • 버전 번호는 major.minor 형식을 갖는다.
    ex) 10.7: major가 10, minor가 7
  • 만약, 9.6.12 → 10.7로 업그레이드 한다면 이는 메이저 버전 업그레이드에 해당한다.

서비스 무중단 버전업이 가능한가?

  • 공식문서에 따르면, 변경 도중 인스턴스가 중단 되므로 다운타임은 불가피 하다.

현재 버전에서 업그레이드 가능한 버전 확인하기

  1. 현재 사용하고 있는 DB 인스턴스 클래스에서 버전 몇 이상의 DB 엔진으로 업그레이드가 가능한가?
    • 이는 본인이 사용하고 있는 DB 인스턴스 클래스가 지원하는 DB 엔진 버전을 확인해 봐야 한다. 링크를 참고하면 된다.

  1. 현재 소스 버전에서 업그레이드 가능한 DB 엔진의 버전 확인
    • 아래의 명령어로 확인할 수 있다.
        aws rds describe-db-engine-versions \
          --engine aurora-postgresql \
          --engine-version {현재 버전} \
          --query 'DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`].{EngineVersion:EngineVersion}' \
          --output text
    → 확인 결과, 아래의 네 가지 버전으로 업그레이드가 가능하다. (이는 aws console의 각 데이터베이스에서 수정 클릭을 통해서도 확인이 가능하다.)
    ```
    11.7
    11.8
    11.9
    11.11
    11.12
    11.13
    ```

가장 최신 버전으로 업그레이드 하는 것도 좋지만 현재 본인이 사용하고 있는 기능에 지장이 없을 지 꼼꼼하게 확인해 보아야 한다.
가장 좋은 방법은 aws 공식 문서에서도 권고 하듯이 테스트 DB를 만들어 확인 해 보는 것이다.

그럼 이제 위의 사항들을 인지한 상태에서 업그레이드를 진행해 본다.



업그레이드 진행하기

아래 2, 3, 5,번은 확장을 사용하지 않는 경우 해당 사항이 없다. 바로 모의 테스트로 넘어가면 된다.

1. 버전 호환 파라미터 그룹 준비하기

사용자 지정 DB 인스턴스 또는 DB 클러스터 파라미터 그룹을 사용하는 경우 아래의 두 가지 옵션을 따른다.
이 경우는 aws console을 이용해 업데이트를 시도 하지 않고 aws-cli를 이용해 업데이트를 시도할 때에만 해당한다. 왜냐하면, 메이저 버전 업데이트를 시도할 경우 새 버전에 맞추어 파라미터 그룹을 지정해야 하는데 console에서는 default를 제공해 주지만 aws-cli의 경우 그렇지 않기 때문이다.

  • 따라서 aws-cli를 이용할 때는 파라미터 그룹을 명시해 주어야 한다. 이는 밑에서 자세히 설명해 놓았다.
  • RDB 버전에 맞는 파라미터 그룹을 생성하고 다른 파라미터와의 차이점 확인 후에 변경되는 파라미터를 업데이트 하면 된다.
  • 업그레이드 완료 후 해당 파라미터를 적용하려면 완료 후에 데이터베이스를 재부팅 해야 한다.

2. 업그레이드 시도 전, 열려 있는 준비된 트랜잭션을 모두 커밋 or 롤백 한다. 다음 쿼리를 통해 인스턴스에 열려 있는 트랜잭션이 없는지 확인할 수 있다.(선택)

 SELECT count(*) FROM pg_catalog.pg_prepared_xacts;
  • 그런데 만약 pg_catalog가 인스톨 되어 있지 않다면 해당 사항을 확인해 볼 수 없다.

3. 업그레이드 시도 전, reg 데이터 형식의 사용을 모두 제거해야 한다. 아래의 쿼리를 통해 지원되지 않는 reg 데이터 형식이 사용되고 있는지 확인할 수 있다.(선택)

 SELECT count(*) FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n, pg_catalog.pg_attribute a 
   WHERE c.oid = a.attrelid 
       AND NOT a.attisdropped 
       AND a.atttypid IN ('pg_catalog.regproc'::pg_catalog.regtype, 
                          'pg_catalog.regprocedure'::pg_catalog.regtype, 
                          'pg_catalog.regoper'::pg_catalog.regtype, 
                          'pg_catalog.regoperator'::pg_catalog.regtype, 
                          'pg_catalog.regconfig'::pg_catalog.regtype, 
                          'pg_catalog.regdictionary'::pg_catalog.regtype) 
       AND c.relnamespace = n.oid 
       AND n.nspname NOT IN ('pg_catalog', 'information_schema');
  • 여기서도 만약 pg_catalog가 인스톨 되어 있지 않다면 해당 사항을 확인해 볼 수 없다.

4. 백업 수행

  • 업그레이드 중에 DB 클러스터의 DB 클러스터 스냅샷이 생성되지만, 혹시 모르니 업그레이드 전에 수동 백업을 진행할 수도 있다.

5. 특정 확장을 최신 버전으로 업그레이드(선택)

  • 업그레이드 수행에 필요한 특정 확장들을 최신 버전으로 업그레이드 해야 한다.
    • 아래의 확장들이 그 대상이다.
       pgRouting
       
       postgis_raster
       
       postgis_tiger_geocoder
       
       postgis_topology
       
       address_standardizer
       
       address_standardizer_data_us 
    • 각 확장들에 대해 아래와 같이 업데이트 명령을 실행할 수 있다.
       ALTER EXTENSION <PostgreSQL-extension> UPDATE TO 'new-version'

6. unknown 데이터 형식 삭제하기(선택)

버전 10부터는 unknown 데이터 형식에 대한 지원이 중지 되었다. 따라서 unknown 데이터 형식을 찾아 삭제해야 한다. 찾는 방법은 다음과 같다.

 SELECT DISTINCT data_type FROM information_schema.columns WHERE data_type ILIKE 'unknown';

7. 업그레이드 모의 테스트

테스트 DB를 생성하기 위한 방법으로는 크게 2가지가 있는데 최근 스냅샷에서 데이터베이스 복원 또는 복제 를 하거나 S3에서 가져오기를 사용하는 방법이다.

1) S3에서 가져오기

만약 S3에 스냅샷을 저장하고 있다면 DB 생성시 S3에서 가져오기 버튼을 클릭해서 모든 데이터를 가져올 수 있다.

버킷의 하위 폴더에 들어 있는 스냅샷 데이터를 가져오려면 아래와 같은 방법으로 해야 한다.

예를 들어 이름이 backups인 하위 폴더의 S3에 백업 파일을 저장했고 여러 세트의 백업 파일이 각각 자체 디렉터리(gzip_backup1, gzip_backup2 등)에 들어 있다고 가정해봅시다. 이 경우 gzip_backup1 폴더의 파일에서 복원하려면 backups/gzip_backup1의 접두사를 지정합니다.

방법은 여기를 참고하면 된다.

→ 그러나 이 방법으로는 Mysql 하위 호환 버전만 생성된다. 따라서, 기존에 사용하던 PostgreSQL 호환 버전을 생성하고 싶다면 스냅샷 생성해 놓은 것이 있을 경우 스냅샷으로부터 데이터베이스를 생성하는 것이 좋다.

2) 스냅샷 통해 복원하기

메뉴에서 스냅샷에 들어가 최근 스냅샷을 찾고, 복원하고자 하는 스냅샷 체크 박스를 클릭한 후 우측 상단의 작업 > 스냅샷 복원 을 선택하면 된다.

→ 이 방법을 통해 PostgreSQL 호환 버전을 생성할 수 있다.
→ 기존의 DB와 똑같은 버전을 선택해서 생성하면 된다(다른 메이저 버전으로 복원은 불가능하다).

8. 프로덕션 인스턴스 업그레이드

콘솔에서 수동으로 업그레이드 하거나 AWS CLI 또는 RDS API를 사용하는 방법이 있는데 그건 이 페이지를 참고하면 될 것 같다. 아래에 더 자세하게 설명해 놓았다.

업그레이드 중에 진행 사항을 보고 싶다면?

진행 중인 업그레이드에 대한 자세한 내용은 Amazon RDS를 사용하여 pg_upgrade 유틸리티가 생성하는 두 개의 로그를 볼 수 있다. 이러한 로그는 pg_upgrade_internal.log 및 pg_upgrade_server.log이다.

요기를 참고하면 사용법을 자세히 볼 수 있다.
→ 그러나 이 방법 역시 해당 확장을 사용해야 확인이 가능하다.

9. 업그레이드 완료 후 PostgreSQL 확장 업그레이드 하기(5번에서 설명한 확장 버전 업그레이드 방법을 참고하면 될 것 같다.)



테스트 진행 내역

위에서 설명한 진행 방법을 토대로 실제 테스트를 진행해 보았다.

  • 프로덕션 DB로부터 생성해 놓은 스냅샷을 이용해 Aurora DB를 생성했다.
    → Aurora는 클러스터 내에 기본적으로 라이터 인스턴스를 한 개 가지며 다른 가용 영역에 리더 인스턴스를 추가할 수 있다. 이 때, DB 클러스터가 여러 가용영역을 가로지르며 존재하게 되며 각 리더 인스턴스는 copied DB를 DB 클러스터에 가지고 있게 된다.
  • 파라미터 그룹도 DB 버전에 맞게 변경되어야 한다.
    • aws cli로 버전 업그레이드 진행시 수동으로 값을 생성해 주어야 하지만, aws console에서 버전 업그레이드 진행시 default 값이 주어짐

      → 새로운 버전에 맞는 파라미터를 클러스터인스턴스용으로 두 가지 만들어 놓는다.
      → aws-cli를 이용할 경우 메이저 업그레이드 진행시 아래와 같이 파라미터 그룹을 명시해야 한다.(클러스터 --db-cluster-parameter-group-name {클러스터 파라미터 그룹} & 인스턴스 --db-instance-parameter-group-name {인스턴스 파라미터 그룹}) 아래의 예시는 버전 12로 메이저 업그레이드 할 때의 설정이다.

	aws rds modify-db-cluster \ 
    		--db-cluster-identifier {클러스터명} \
    		--engine-version {타겟 버전} \
    		--db-cluster-parameter-group-name postgresql12-cluster-paramter-group \
    		--db-instance-parameter-group-name postgresql12-paramter-group \
    		--allow-major-version-upgrade \
    		--apply-immediately
  • dev 환경에서 DB 엔드포인트를 테스트 DB로 변경 후 실제 서비스 사용시 이상이 없는지 확인한다.
    • 이에 따른 소요 시간도 함께 확인하여 업그레이드 진행 계획을 세울 때 참고해야 한다.
    • 다운타임이 불가피하기 때문에 트래픽이 적은 새벽 시간대에 업그레이드를 진행해야 한다.


만약 다운타임 없이 업그레이드를 진행해야 했다면?

만약 본인이 개발한 서비스가 다운타임 없이 업그레이드를 해야 하는 비트코인 거래소 같은 것이었다면 위의 방법으로 업그레이드를 진행하면 안된다. 무중단 업그레이드가 까다롭긴 해도 방법이 있긴 하다.

DMS를 이용한 db 이중화

  • dms에 cdc 옵션이 있다. 이 때, dms 통해 일단 db 이중화를 하고 master가 업데이트 하면 slave 쪽으로 데이터를 넘겨서 둘의 sync를 맞추는 방법을 사용하면 무중단 업그레이드가 가능했을 것이다.
    → 하지만 이 방법도 sync가 맞지 않는 상황이 발생할 수 있어 문제가 생길 수는 있다.

CDC란?

  • CDC는 AWS DMS 원본 데이터 스토어에서 진행중인 변경 사항을 캡처하는 작업을 말한다. 데이터를 마이그레이션하는 동안에도 이 변경 사항을 캡처할 수 있다.

  • 작업을 생성해 지원된 대상 데이터 스토어로 초기(전체 로드) 마이그레이션을 완료한 후 지속적 변경 사항을 캡처할 수도 있다.
    - 이 프로세스는 진행 중인 복제 또는 변경 데이터 캡처(CDC)라고 한다.

    • 또한, CDC가 실행 될 때는 데이터베이스 엔진의 기본 API를 사용하여 데이터베이스 로그에 대한 변경 사항을 수집한다.


참고

1) 블로그

2) 공식 문서

profile
쿄쿄

0개의 댓글