논리적 복제를 사용하여 Aurora PostgreSQL에 대한 메이저 버전 업그레이드 수행 - Amazon Aurora
요구 사항제한 사항파라미터 값 설정 및 확인Aurora PostgreSQL를 새로운 메이저 버전으로 업그레이드 업그레이드 후 작업 수행

논리적 복제를 사용하여 Aurora PostgreSQL에 대한 메이저 버전 업그레이드 수행

논리적 복제와 Aurora 고속 복제를 사용하면 변경되는 데이터를 새로운 메이저 버전 데이터베이스로 점진적으로 마이그레이션하면서도 현재 Aurora PostgreSQL 데이터베이스 버전을 사용하는 메이저 버전 업그레이드를 수행할 수 있습니다. 가동 중지 시간이 짧은 이 업그레이드 프로세스를 블루/그린 업그레이드라고 합니다. 데이터베이스의 현재 버전을 “블루” 환경이라고 하고 새 데이터베이스 버전을 “그린” 환경이라고 합니다.

Aurora 고속 클로닝은 소스 데이터베이스의 스냅샷을 생성하여 기존 데이터를 완전히 로드합니다. 고속 클로닝은 Aurora 스토리지 계층에 구축되는 기록 중 복사(copy-on-write) 프로토콜을 사용하므로, 짧은 시간 안에 데이터베이스 클론을 생성할 수 있습니다. 이 방법은 대규모 데이터베이스로 업그레이드할 때 매우 효과적입니다.

PostgreSQL에서의 논리적 복제는 사용자가 PostgreSQL 신규 버전으로 전환할 때까지 초기 인스턴스의 데이터 변경 사항을 추적하고 병렬로 실행되는 새 인스턴스로 전송합니다. 논리적 복제에서는 게시 및 구독 모델을 사용합니다. Aurora PostgreSQL 논리적 복제에 대한 자세한 내용은 Amazon Aurora PostgreSQL를 사용한 복제 섹션을 참조하세요.

작은 정보

관리형 Amazon RDS 블루/그린 배포 기능을 사용하여 메이저 버전 업그레이드에 필요한 가동 중지를 최소화할 수 있습니다. 자세한 내용은 데이터베이스 업데이트에 Amazon RDS 블루/그린 배포 사용 단원을 참조하십시오.

요구 사항

가동 중지 시간이 짧은 이 업그레이드 프로세스를 수행하려면 다음 요구 사항을 충족해야 합니다.

  • rds_superuser 권한이 있어야 합니다.

  • 업그레이드하려는 Aurora PostgreSQL DB 클러스터가 논리적 복제를 사용하여 메이저 버전 업그레이드를 수행할 수 있는 지원 버전을 실행해야 합니다. DB 클러스터에 마이너 버전 업데이트 및 패치가 있다면 적용해야 합니다. 이 기법에 사용되는 aurora_volume_logical_start_lsn 함수는 다음 버전의 Aurora PostgreSQL에서 지원됩니다.

    • 15.2 이상의 15 버전

    • 14.3 이상의 14 버전

    • 13.6 이상의 13 버전

    • 12.10 이상의 12 버전

    • 11.15 이상의 11 버전

    • 10.20 이상의 10 버전

    aurora_volume_logical_start_lsn 함수에 대한 자세한 내용은 aurora_volume_logical_start_lsn 섹션을 참조하세요.

  • 모든 테이블에는 프라이머리 키가 있거나 PostgreSQL ID 열이 포함되어야 합니다.

  • 두 (이전 및 신규 클러스터를 포함한) Aurora PostgreSQL DB 클러스터 간의 인바운드 및 아웃바운드 액세스를 허용하도록 VPC의 보안 그룹을 구성합니다. 특정 Classless Inter-Domain Routing(CIDR) 범위 또는 VPC나 피어 VPC의 다른 보안 그룹에 대한 액세스 권한을 부여할 수 있습니다. (피어 VPC에는 VPC 피어링 연결이 필요합니다.)

참고

실행 중인 논리적 복제 시나리오를 구성하고 관리하는 데 필요한 권한에 대한 자세한 내용은 PostgreSQL 핵심 설명서를 참조하십시오.

제한 사항

Aurora PostgreSQL DB 클러스터를 새 메이저 버전으로 업그레이드하기 위해 가동 중지 시간이 짧은 업그레이드를 수행할 때는 기본 PostgreSQL 논리적 복제 기능을 사용하게 됩니다. PostgreSQL 논리적 복제와 동일한 기능과 제한 사항이 있습니다. 자세한 내용은 PostgreSQL 논리적 복제를 참조하세요.

  • 데이터 정의 언어(DDL) 명령은 복제되지 않습니다.

  • 복제는 라이브 데이터베이스에서의 스키마 변경을 지원하지 않습니다. 스키마는 클로닝 프로세스 중에 원래 형태로 재생성됩니다. 클로닝 후 업그레이드가 완료되기 전에 스키마를 변경하면 변경 사항이 업그레이드된 인스턴스에 반영되지 않습니다.

  • 대형 객체는 복제되지 않지만 일반 테이블에 데이터를 저장할 수 있습니다.

  • 복제는 파티션을 나눈 테이블을 포함한 테이블에서만 지원됩니다. 뷰, 구체화된 뷰 또는 외부 테이블 같은 다른 유형의 관계로의 복제는 지원되지 않습니다.

  • 시퀀스 데이터는 복제되지 않으며 장애 조치 후 수동 업데이트가 필요합니다.

참고

이 업그레이드는 자동 스크립팅을 지원하지 않습니다. 모든 단계를 직접 수행해야 합니다.

파라미터 값 설정 및 확인

업그레이드하기 전에 Aurora PostgreSQL DB 클러스터의 라이터 인스턴스를 게시 서버로 작동하도록 구성합니다. 인스턴스는 다음 설정이 적용된 사용자 지정 DB 클러스터 파라미터 그룹을 사용해야 합니다.

  • rds.logical_replication – 이 파라미터를 1로 설정합니다. rds.logical_replication 파라미터는 미리 쓰기 로그 파일 관리를 제어하는 독립 실행형 PostgreSQL 서버의 wal_level 파라미터 및 기타 파라미터와 동일한 용도로 사용됩니다.

  • max_replication_slots – 이 파라미터를 생성할 총 구독 수로 설정합니다. AWS DMS를 사용 중인 경우 이 파라미터를 이 DB 클러스터에서 변경된 데이터를 캡처하는 데 사용할 AWS DMS 태스크의 숫자로 설정합니다.

  • max_wal_senders - 관리 태스크와 새 세션에 사용할 수 있도록 동시 연결 수에 약간의 여분을 더한 수로 설정합니다. AWS DMS를 사용하는 경우 max_wal_senders 수는 총 동시 세션 수에 특정 시간에 작동하는 AWS DMS 태스크 수를 더한 값과 같아야 합니다.

  • max_logical_replication_workers - 예상하는 논리적 복제 작업자 및 테이블 동기화 작업자 수로 설정합니다. 일반적으로는 복제 작업자 수를 max_wal_senders에 사용한 것과 동일한 값으로 설정하는 것이 안전합니다. 작업자는 서버에 할당된 백그라운드 프로세스 풀(max_worker_processes)에서 가져옵니다.

  • max_worker_processes - 서버의 백그라운드 프로세스 수로 설정합니다. 이 수는 복제, 자동 진공 처리 프로세스 및 동시에 수행될 수 있는 기타 유지 관리 프로세스에 작업자를 할당할 수 있을만큼 커야 합니다.

신규 버전의 Aurora PostgreSQL로 업그레이드하는 경우 이전 버전 파라미터 그룹에서 수정한 모든 파라미터를 복제해야 합니다. 이러한 파라미터는 업그레이드된 버전에 적용됩니다. pg_settings 테이블을 쿼리하여 파라미터 설정 목록을 얻어 새 Aurora PostgreSQL DB 클러스터에서 파라미터 설정을 다시 생성할 수 있습니다.

예를 들어 복제 파라미터의 설정을 얻으려면 다음 쿼리를 실행합니다.

SELECT name, setting FROM pg_settings WHERE name in 
('rds.logical_replication', 'max_replication_slots', 
'max_wal_senders', 'max_logical_replication_workers', 
'max_worker_processes');

Aurora PostgreSQL를 새로운 메이저 버전으로 업그레이드

게시자(블루) 준비 방법

  1. 다음 예제에서 소스 라이터 인스턴스(블루)는 PostgreSQL 버전 11.15를 실행하는 Aurora PostgreSQL DB 클러스터입니다. 이 복제 시나리오에서는 게시 노드입니다. 이 데모에서 소스 라이터 인스턴스는 일련의 값을 포함하는 샘플 테이블을 호스팅합니다.

    CREATE TABLE my_table (a int PRIMARY KEY);
INSERT INTO my_table VALUES (generate_series(1,100));

  2. 원본 인스턴스에서 게시자를 만들려면 psql(CLI for PostgreSQL) 또는 원하는 클라이언트를 사용하여 인스턴스의 라이터 노드에 연결해야 합니다. 각 데이터베이스에 다음 명령을 입력합니다.

    CREATE PUBLICATION publication_name FOR ALL TABLES;

    publication_name은 게시의 이름을 지정합니다.

  3. 인스턴스에서 복제 슬롯을 생성해야 합니다. 다음 명령은 복제 슬롯을 생성하고 pgoutput 논리적 디코딩 플러그인을 로드합니다. 이 플러그인은 미리 쓰기 로그(WAL)에서 읽은 콘텐츠를 논리적 복제 프로토콜로 변경하고, 게시 사양에 따라 데이터를 필터링합니다.

    SELECT pg_create_logical_replication_slot('replication_slot_name', 'pgoutput');
게시자를 복제하는 방법

  1. Amazon RDS 콘솔을 사용하여 원본 인스턴스의 클론을 만듭니다. Amazon RDS 콘솔에서 인스턴스 이름을 강조 표시한 다음 Actions(작업) 메뉴에서 Create clone(복제본 생성)을 선택합니다.

    Aurora MySQL DB 클러스터 버전 2에서 버전 3으로의 현재 위치 업그레이드

  2. 인스턴스의 고유 이름을 입력합니다. 대부분의 설정은 소스 인스턴스의 기본값입니다. 새 인스턴스에 필요한 변경 사항을 적용했다면 Create clone(복제본 생성)을 선택합니다.

    Aurora MySQL DB 클러스터 버전 2에서 버전 3으로의 현재 위치 업그레이드

  3. 대상 인스턴스가 시작되는 동안 라이터 노드의 Status(상태) 열에는 Status(상태) 열에 생성 중(Creating)이 표시됩니다. 인스턴스가 준비되면 인스턴스의 상태가 사용 가능(Aavailable)으로 변경됩니다.

업그레이드를 위해 클론 준비

  1. 클론은 배포 모델의 '그린' 인스턴스입니다. 이것은 복제 구독 노드의 호스트입니다. 노드를 사용할 수 있게 되면 psql에 연결하고 새 라이터 노드에 아래의 쿼리를 수행해 LSN(로그 시퀀스 번호)을 얻습니다. LSN은 WAL 스트림에서 레코드가 시작되는 부분을 나타냅니다.

    SELECT aurora_volume_logical_start_lsn();

  2. 쿼리의 응답에서 LSN 번호를 찾을 수 있습니다. 프로세스 후반부에 필요하니 이 번호를 메모해 두십시오.

    postgres=> SELECT aurora_volume_logical_start_lsn();
aurora_volume_logical_start_lsn 
---------------
0/402E2F0
(1 row)

  3. 클론을 업그레이드하기 전에 클론의 복제 슬롯을 삭제하세요.

    SELECT pg_drop_replication_slot('replication_slot_name');
클러스터를 새 메이저 버전으로 업그레이드

  • 공급자 노드를 복제한 후 Amazon RDS 콘솔을 사용하여 구독 노드에서 메이저 버전 업그레이드를 시작합니다. RDS 콘솔에서 인스턴스 이름을 강조 표시하고 Modify(수정) 버튼을 선택합니다. 업데이트된 버전과 업데이트된 파라미터 그룹을 선택하고, 설정을 즉시 적용하여 대상 인스턴스를 업그레이드합니다.

    Aurora MySQL DB 클러스터 버전 2에서 버전 3으로의 현재 위치 업그레이드

  • CLI를 사용하여 업그레이드를 수행할 수도 있습니다.

    aws rds modify-db-cluster —db-cluster-identifier $TARGET_Aurora_ID —engine-version 13.6 —allow-major-version-upgrade —apply-immediately
가입자(그린)를 준비하는 방법

  1. 업그레이드 후에 클론이 사용 가능해지면 psql에 연결하고 구독을 정의합니다. 이렇게 하려면 CREATE SUBSCRIPTION 명령에서 다음 옵션을 지정해야 합니다.

    • subscription_name – 구독의 이름입니다.

    • admin_user_name - rds_superuser 권한이 있는 관리자 사용자의 이름입니다.

    • admin_user_password - 관리자 사용자와 연결된 암호입니다.

    • source_instance_URL - 게시 서버 인스턴스의 URL입니다.

    • database - 구독 서버가 연결할 데이터베이스입니다.

    • publication_name - 게시 서버의 이름입니다.

    • replication_slot_name - 복제 슬롯의 이름입니다.

    CREATE SUBSCRIPTION subscription_name 
CONNECTION 'postgres://admin_user_name:admin_user_password@source_instance_URL/database' PUBLICATION publication_name 
WITH (copy_data = false, create_slot = false, enabled = false, connect = true, slot_name = 'replication_slot_name');

  2. 구독을 생성한 후 pg_replication_origin 뷰를 쿼리하여 복제 원본의 식별자인 roname 값을 검색합니다. 각 인스턴스에는 roname이 하나씩 있습니다.

    SELECT * FROM pg_replication_origin;

    예:

    postgres=> 
SELECT * FROM pg_replication_origin;
 
roident | roname 
---------+----------
1 | pg_24586

  3. 게시 노드의 이전 쿼리에서 저장한 LSN과 명령의 [INSTANCE] 구독 노드에서 반환된 roname을 입력합니다. 이 명령은 pg_replication_origin_advance 함수를 사용하여 복제를 위한 로그 시퀀스의 시작점을 지정합니다.

    SELECT pg_replication_origin_advance('roname', 'log_sequence_number');

    roname은 pg_replication_origin 뷰에서 반환된 식별자입니다.

    log_sequence_number는 aurora_volume_logical_start_lsn 함수의 이전 쿼리에서 반환된 값입니다.

  4. 그런 다음 ALTER SUBSCRIPTION... ENABLE 절을 사용하여 논리적 복제를 켭니다.

    ALTER SUBSCRIPTION subscription_name ENABLE;

  5. 이 시점에서 복제가 제대로 작동하는지 확인할 수 있습니다. 게시 인스턴스에 값을 추가한 다음 값이 구독 노드에 복제되었는지 확인합니다.

    그런 다음 아래 명령을 사용하여 게시 노드의 복제 지연을 모니터링합니다.

    SELECT now() AS CURRENT_TIME, slot_name, active, active_pid, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(),
confirmed_flush_lsn)) AS diff_size, pg_wal_lsn_diff(pg_current_wal_lsn(),
confirmed_flush_lsn) AS diff_bytes FROM pg_replication_slots WHERE slot_type = 'logical';

    예:

    postgres=> SELECT now() AS CURRENT_TIME, slot_name, active, active_pid, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), 
confirmed_flush_lsn)) AS diff_size, pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn) AS diff_bytes FROM pg_replication_slots WHERE slot_type = 'logical';
 
current_time                   | slot_name             | active | active_pid | diff_size | diff_bytes 
-------------------------------+-----------------------+--------+------------+-----------+------------
2022-04-13 15:11:00.243401+00  | replication_slot_name | t      | 21854      | 136 bytes | 136
(1 row)

    diff_size 및 diff_bytes 값을 사용하여 복제 지연을 모니터링할 수 있습니다. 이러한 값이 0에 도달하면 복제본이 원본 DB 인스턴스를 따라잡은 것입니다.

업그레이드 후 작업 수행

업그레이드가 완료되면 콘솔 대시보드 Status(상태) 열에 인스턴스 상태가 Available(사용 가능)로 표시됩니다. 새 인스턴스에서는 다음을 수행하는 것이 좋습니다.

  • 라이터 노드를 가리키도록 애플리케이션을 리디렉션합니다.

  • 케이스로드를 관리하고 라이터 노드에 문제가 발생할 경우 고가용성을 제공할 수 있도록 리더 노드를 추가합니다.

  • Aurora PostgreSQL DB 클러스터는 때때로 운영 체제 업데이트가 필요합니다. 이러한 업데이트에는 glibc 라이브러리의 최신 버전도 포함될 수 있습니다. 이러한 업데이트를 진행하는 중에는 Aurora PostgreSQL에서 지원되는 데이터 정렬에 설명된 지침을 따르는 것이 좋습니다.

  • 액세스를 보장하기 위해 새 인스턴스의 사용자 권한을 업데이트합니다.

새 인스턴스에서 애플리케이션과 데이터를 테스트한 후에는 초기 인스턴스를 제거하기 전에 최종 백업을 만드는 것이 좋습니다. Aurora 호스트에서 논리적 복제를 사용하는 자세한 방법은 Aurora PostgreSQL DB 클러스터의 논리적 복제 설정 단원을 참조하십시오.