Aurora DB 클러스터에 대한 볼륨 복제 - Amazon Aurora

Aurora DB 클러스터에 대한 볼륨 복제

Aurora 복제를 사용하면 처음에는 원본과 동일한 데이터 페이지를 공유하지만 별도의 독립적인 볼륨인 새 클러스터를 생성할 수 있습니다. 이 프로세스는 빠르고 비용 효율적으로 진행되도록 설계되었습니다. 연결된 데이터 볼륨이 있는 새 클러스터를 복제본이라고 합니다. 복제본 생성은 스냅샷 복원과 같은 다른 기술을 사용하여 데이터를 물리적으로 복사하는 것보다 빠르고 공간 효율적입니다.

Aurora 복제 개요

Aurora는 기록 중 복사(Copy-on-Write) 프로토콜을 사용하여 복제본을 생성합니다. 이 메커니즘은 최소한의 추가 공간을 사용하여 초기 복제를 만듭니다. 복제가 처음 생성되면 Aurora는 소스 Aurora DB 클러스터와 새로운(복제된) Aurora DB 클러스터에서 사용하는 데이터의 단일 복사본을 유지합니다. 소스 Aurora DB 클러스터 또는 Aurora DB 클러스터 복제가 Aurora 스토리지 볼륨의 데이터를 변경한 경우에만 추가 스토리지가 할당됩니다. 기록 중 복사(Copy-on-Write) 프로토콜에 대한 자세한 내용은 Aurora 복제 작동 방식 섹션을 참조하세요.

Aurora 복제 작업은 데이터 손상 위험 없이 프로덕션 데이터를 사용하여 테스트 환경을 신속하게 설정하는 데 특히 유용합니다. 다음과 같은 여러 유형의 애플리케이션에 복제본을 사용할 수 있습니다.

  • 잠재적 변경 사항(예: 스키마 변경 및 파라미터 그룹 변경)을 실험하여 모든 영향을 평가합니다.

  • 데이터 내보내기 또는 복제본에서 분석 쿼리 실행과 같은 워크로드 집약적인 작업을 수행하는 경우

  • 개발, 테스트 또는 기타 용도로 프로덕션 DB 클러스터의 복사본을 생성합니다.

동일한 Aurora DB 클러스터에서 둘 이상의 복제본을 생성할 수 있습니다. 다른 복제본에서 여러 복제본을 생성할 수도 있습니다.

Aurora 복제본을 생성한 후 Aurora DB 인스턴스를 소스 Aurora DB 클러스터와 다르게 구성할 수 있습니다. 예를 들어 소스 프로덕션 Aurora DB 클러스터와 동일한 고가용성 요구 사항을 충족하기 위해 개발 목적으로 복제본이 필요하지 않을 수 있습니다. 이 경우 Aurora DB 클러스터에서 사용하는 여러 DB 인스턴스가 아닌 단일 Aurora DB 인스턴스로 복제본을 구성할 수 있습니다.

소스와 다른 배포 구성을 사용하여 복제를 생성하면 소스 Aurora DB 엔진의 최신 마이너 버전을 사용하여 복제본이 생성됩니다.

Aurora DB 클러스터에서 복제를 생성하면 소스 Aurora DB 클러스터를 소유하는 계정과 동일한 AWS 계정에서 복제본이 생성됩니다. 그러나 Aurora Serverless v2 및 프로비저닝된 Aurora DB 클러스터와 복제본을 다른 AWS 계정에 공유할 수도 있습니다. 자세한 내용은 AWS RAM과 Amazon Aurora에서 교차 계정 복제 섹션을 참조하세요.

복제본을 테스트, 개발 또는 다른 용도로 사용한 후 삭제할 수 있습니다.

Aurora 복제의 제한 사항

Aurora 복제는 다음과 같은 제한 사항이 있습니다.

  • AWS 리전에서 허용하는 최대 DB 클러스터 개수까지 원하는 만큼 복제본을 생성할 수 있습니다.

    쓰기 시 복사 프로토콜 또는 전체 복사 프로토콜을 사용하여 복제본을 생성할 수 있습니다. 전체 복사 프로토콜은 특정 시점 복구와 같은 역할을 합니다.

  • 소스 Aurora DB 클러스터에서 다른 AWS 리전에 복제본을 생성할 수 없습니다.

  • 병렬 쿼리 기능이 없는 Aurora DB 클러스터에서 병렬 쿼리를 사용하는 클러스터로의 복제본을 생성할 수 없습니다. 병렬 쿼리를 사용하는 클러스터에 데이터를 가져오려면 원본 클러스터의 스냅샷을 생성하여 병렬 쿼리 기능을 사용하는 클러스터에 복원합니다.

  • DB 인스턴스가 없는 Aurora DB 클러스터에서 복제본을 생성할 수 없습니다. 하나 이상의 DB 인스턴스가 있는 Aurora DB 클러스터만 복제할 수 있습니다.

  • 복제본을 Aurora DB 클러스터의 Virtual Private Cloud(VPC)와 다른 Virtual Private Cloud(VPC)에 생성할 수 있습니다. 이렇게 하면 VPC의 서브넷을 동일한 가용 영역에 매핑해야 합니다.

  • 프로비저닝된 Aurora DB 클러스터에서 Aurora 프로비저닝된 복제본을 생성할 수 있습니다.

  • Aurora Serverless v2 인스턴스가 있는 클러스터는 프로비저닝된 클러스터와 동일한 규칙을 따릅니다.

  • Aurora Serverless v1의 경우:

    • Aurora Serverless v1 DB 클러스터에서 프로비저닝된 복제본을 생성할 수 있습니다.

    • Aurora Serverless v1 또는 프로비저닝된 DB 클러스터에서 Aurora Serverless v1 복제본을 생성할 수 있습니다.

    • 암호화되지 않은 프로비저닝된 Aurora DB 클러스터에서는 Aurora Serverless v1 복제본을 생성할 수 없습니다.

    • 교차 계정 복제는 현재 Aurora Serverless v1 DB 클러스터 복제를 지원하지 않습니다. 자세한 내용은 계정 간 복제 제한 사항 섹션을 참조하세요.

    • 복제된 Aurora Serverless v1 DB 클러스터는 Aurora Serverless v1 DB 클러스터와 동일한 동작과 제한 사항이 있습니다. 자세한 내용은 Amazon Aurora Serverless v1 사용 섹션을 참조하세요.

    • Aurora Serverless v1 DB 클러스터는 항상 암호화됩니다. Aurora Serverless v1 DB 클러스터를 프로비저닝된 Aurora DB 클러스터로 복제하는 경우 프로비저닝된 Aurora DB 클러스터가 암호화됩니다. 암호화 키를 선택할 수 있지만 암호화를 비활성화할 수는 없습니다. 프로비저닝된 Aurora DB 클러스터에서 Aurora Serverless v1로 복제하려면 암호화되고 프로비저닝된 Aurora DB 클러스터로 시작해야 합니다.

Aurora 복제 작동 방식

Aurora 복제는 Aurora DB 클러스터의 스토리지 계층에서 작동합니다. 이는 Aurora 스토리지 볼륨을 지원하는 기본 내구 미디어 측면에서 빠르고 공간 효율적인 기록 중 복사(copy-on-write) 프로토콜을 사용합니다. Amazon Aurora 스토리지 개요에서 Aurora 클러스터 볼륨에 대해 자세히 알아보세요.

기록 중 복사(copy-on-write) 이해

Aurora DB 클러스터는 기본 Aurora 스토리지 볼륨의 페이지에 데이터를 저장합니다.

예를 들어, 다음 다이어그램에서 데이터 페이지(1, 2, 3, 4)가 네 개인 Aurora DB 클러스터(A)를 찾을 수 있습니다. 복제본 B가 Aurora DB 클러스터에서 생성된다고 가정해 보겠습니다. 복제본이 생성되면 데이터가 복사되지 않습니다. 대신 복제본은 소스 Aurora DB 클러스터와 동일한 페이지 집합을 가리킵니다.


                    소스 클러스터 A 및 복제본 B에 대해 4개의 페이지가 포함된 Amazon Aurora 클러스터 볼륨

복제본이 생성되면 일반적으로 추가 스토리지가 필요하지 않습니다. 기록 중 복사(copy-on-write) 프로토콜은 물리적 스토리지 미디어에서 소스 세그먼트와 동일한 세그먼트를 사용합니다. 소스 세그먼트의 용량이 전체 복제본 세그먼트에 충분하지 않은 경우에만 추가 스토리지가 필요합니다. 이 경우 소스 세그먼트는 다른 물리적 디바이스로 복사됩니다.

다음 다이어그램에서는 앞에서와 같이 동일한 클러스터 A와 해당 복제본 B를 사용하여 작동하는 기록 중 복사(copy-on-write) 프로토콜의 예를 찾을 수 있습니다. Aurora DB 클러스터(A)를 변경하여 페이지 1에 보관된 데이터가 변경된다고 가정해 보겠습니다. Aurora는 원본 페이지 1에 기록하는 대신 새 페이지 1[A]을 생성합니다. 클러스터(A)에 대한 Aurora DB 클러스터 볼륨은 이제 페이지 1[A], 2, 3, 4를 가리키고 복제본(B)은 여전히 원본 페이지를 참조합니다.


              Amazon Aurora 소스 DB 클러스터 볼륨과 해당 복제본 모두 변경 사항이 있습니다.

복제본에서 스토리지 볼륨의 페이지 4가 변경됩니다. 원본 페이지 4에 기록하는 대신 Aurora는 새 페이지 4[B]를 생성합니다. 이제 복제본은 페이지 1, 2, 3 및 페이지 4[B]를 가리키고 클러스터(A)는 계속해서 1[A], 2, 3 및 4를 가리킵니다.


        Amazon Aurora 소스 DB 클러스터 볼륨과 해당 복제본 모두 변경 사항이 있습니다.

시간이 경과하여 소스 Aurora DB 클러스터 볼륨과 복제본 모두가 변경될 경우 변경 사항을 캡처하고 저장하기 위해 점점 더 많은 스토리지가 필요합니다.

원본 클러스터 볼륨 삭제

하나 이상의 복제본이 연결된 소스 클러스터 볼륨을 삭제해도 복제본은 영향을 받지 않습니다. 복제본은 이전에 원본 클러스터 볼륨이 소유하던 페이지를 계속 가리킵니다.

Amazon Aurora 복제 생성

소스 Aurora DB 클러스터와 같은 AWS 계정에서 복제본을 생성합니다. 이를 위해 AWS Management Console 또는 AWS CLI 및 다음 절차를 사용할 수 있습니다.

다른 AWS 계정에서 복제본을 생성하거나 다른 AWS 계정과 복제본을 공유하도록 허용하려면 AWS RAM과 Amazon Aurora에서 교차 계정 복제의 절차를 사용합니다.

다음 프로시저에서는 AWS Management Console을 사용하여 Aurora DB 클러스터를 복제하는 방법에 대해 설명합니다.

AWS Management Console을 사용하여 복제본을 생성하면 하나의 Aurora DB 인스턴스가 있는 하나의 Aurora DB 클러스터가 생성됩니다.

이번 지침은 복제본을 생성하는 것과 동일한 AWS 계정에서 소유하고 있는 DB 클러스터에 적용됩니다. DB 클러스터를 다른 AWS 계정에서 소유하고 있다면 AWS RAM과 Amazon Aurora에서 교차 계정 복제 섹션을 참조하세요.

AWS을 사용해 AWS Management Console 계정에서 소유하는 DB 클러스터 복제본을 생성하려면
  1. AWS Management Console에 로그인한 후 https://console.aws.amazon.com/rds/에서 Amazon RDS 콘솔을 엽니다.

  2. 탐색 창에서 데이터베이스를 선택합니다.

  3. 목록에서 Aurora DB 클러스터를 선택하고 [작업(Actions)]에서 [복제본 생성(Create clone)]을 선택합니다.

    
                  Aurora DB 클러스터를 선택하여 복제본 생성을 시작합니다.

    설정, 연결성 및 Aurora DB 클러스터 복제본에 대한 기타 옵션을 구성할 수 있는 복제본 생성 페이지가 열립니다.

  4. DB 인스턴스 식별자에 복제된 Aurora DB 클러스터에 부여할 이름을 입력합니다.

  5. Aurora Serverless v1 DB 클러스터의 경우 용량 유형에서 프로비저닝됨 또는 서버리스를 선택합니다.

    소스 Aurora DB 클러스터가 Aurora Serverless v1 DB 클러스터이거나 암호화되고 프로비저닝된 Aurora DB 클러스터인 경우 [서버리스(Serverless)]를 선택합니다.

  6. Aurora Serverless v2 또는 프로비저닝된 DB 클러스터의 경우 클러스터 스토리지 구성에서 Aurora I/O-Optimized 또는 Aurora Standard 중 하나를 선택합니다.

    자세한 내용은 Amazon Aurora DB 클러스터의 스토리지 구성 섹션을 참조하세요.

  7. DB 인스턴스 크기 또는 DB 클러스터 용량을 선택합니다.

    • 프로비저닝된 복제본의 경우 DB 인스턴스 클래스를 선택합니다.

      
                                        프로비저닝된 복제본을 생성하려면 DB 인스턴스 크기를 지정합니다.

      제공된 설정을 수락하거나 복제본에 다른 DB 인스턴스 클래스를 사용할 수 있습니다.

    • Aurora Serverless v1 또는 Aurora Serverless v2 복제본의 경우 용량 설정을 선택합니다.

      
                                        Aurora DB 클러스터에서 Serverless 복제본을 생성하려면 용량을 지정합니다.

      제공된 설정을 수락하거나 복제본에 맞게 설정을 변경할 수 있습니다.

  8. 복제본에 필요에 따라 다른 설정을 선택하세요. Aurora DB 클러스터 및 인스턴스 설정에 대한 자세한 내용은 Amazon Aurora DB 클러스터 생성 섹션에서 참조하세요.

  9. 복제본 생성을 선택합니다.

복제본이 생성되면 복제본은 콘솔의 [데이터베이스(Databases)] 섹션에 다른 Aurora DB 클러스터와 함께 나열되고 현재 상태가 표시됩니다. 상태가 [사용 가능(Available)]이면 복제본을 사용할 준비가 된 것입니다.

Aurora DB 클러스터를 복제하기 위해 AWS CLI를 사용하는 데 몇 가지 단계가 필요합니다.

사용하는 restore-db-cluster-to-point-in-time AWS CLI 명령을 실행하면 Aurora DB 인스턴스가 없는 빈 Aurora DB 클러스터가 생성됩니다. 즉, 명령은 Aurora DB 클러스터만 복원하고, 해당 클러스터의 DB 인스턴스는 복원하지 않습니다. 복제본이 사용 가능한 후에 별도로 이 작업을 수행합니다. 프로세스의 두 단계는 다음과 같습니다.

  1. restore-db-cluster-to-point-in-time CLI 명령을 사용하여 복제본을 생성합니다. 이 명령과 함께 사용하는 파라미터는 생성 중인 빈 Aurora DB 클러스터(복제본)의 용량 유형 및 기타 세부 정보를 제어합니다.

  2. 복원된 Aurora DB 클러스터에 Aurora DB 인스턴스를 재생성하려면 create-db-instance CLI 명령을 사용하여 이 복제본에 대한 Aurora DB 인스턴스를 생성합니다.

복제본 생성

restore-db-cluster-to-point-in-time CLI 명령으로 전달하는 특정 파라미터는 다양합니다. 전달하는 항목은 소스 DB 클러스터의 엔진 모드 유형에 따라 다릅니다. 즉 Serverless 또는 프로비저닝된 복제본 유형 및 생성하려는 복제본 유형에 따라 다릅니다.

소스 Aurora DB 클러스터와 동일한 엔진 모드의 복제본을 생성하려면
  • restore-db-cluster-to-point-in-time CLI 명령을 사용하여 다음 파라미터에 대한 값을 지정합니다.

    • --db-cluster-identifier - 복제본에 대해 의미 있는 이름을 선택합니다. 복제본의 이름을 지정할 때 restore-db-cluster-to-point-in-time CLI 명령을 사용합니다. 그런 다음 create-db-instance CLI 명령에 복제본 이름을 전달합니다.

    • --restore-typecopy-on-write을 사용하여 소스 DB 클러스터의 복제본을 생성합니다. 이 파라미터가 없으면 restore-db-cluster-to-point-in-time은 복제본을 생성하는 대신 Aurora DB 클러스터를 복원합니다.

    • --source-db-cluster-identifier - 복제할 소스 Aurora DB 클러스터의 이름을 사용합니다.

    • --use-latest-restorable-time - 이 값은 소스 DB 클러스터에 대해 복원 가능한 최신 볼륨 데이터를 가리킵니다. 이를 사용하여 클론을 생성할 수 있습니다.

다음 예제에서는 my-source-cluster라는 이름의 클러스터에서 my-clone라는 이름의 복제본을 생성합니다.

Linux, macOS, Unix:

aws rds restore-db-cluster-to-point-in-time \ --source-db-cluster-identifier my-source-cluster \ --db-cluster-identifier my-clone \ --restore-type copy-on-write \ --use-latest-restorable-time

Windows의 경우:

aws rds restore-db-cluster-to-point-in-time ^ --source-db-cluster-identifier my-source-cluster ^ --db-cluster-identifier my-clone ^ --restore-type copy-on-write ^ --use-latest-restorable-time

이 명령은 복제본의 세부 사항을 포함하는 JSON 객체를 반환합니다. 클론에 대한 DB 인스턴스를 생성하기 전에 복제된 DB 클러스터를 사용할 수 있는지 확인합니다. 자세한 내용은 상태 확인 및 복제본 세부 정보 가져오기 섹션을 참조하세요.

소스 Aurora DB 클러스터와 다른 엔진 모드를 사용하여 복제본을 생성하는 방법
  • restore-db-cluster-to-point-in-time CLI 명령을 사용하여 다음 파라미터에 대한 값을 지정합니다.

    • --db-cluster-identifier - 복제본에 대해 의미 있는 이름을 선택합니다. 복제본의 이름을 지정할 때 restore-db-cluster-to-point-in-time CLI 명령을 사용합니다. 그런 다음 create-db-instance CLI 명령에 복제본 이름을 전달합니다.

    • --source-db-cluster-identifier - 복제할 소스 Aurora DB 클러스터의 이름을 사용합니다.

    • --restore-typecopy-on-write을 사용하여 소스 DB 클러스터의 복제본을 생성합니다. 이 파라미터가 없으면 restore-db-cluster-to-point-in-time은 복제본을 생성하는 대신 Aurora DB 클러스터를 복원합니다.

    • --use-latest-restorable-time - 이 값은 소스 DB 클러스터에 대해 복원 가능한 최신 볼륨 데이터를 가리킵니다. 이를 사용하여 클론을 생성할 수 있습니다.

    • --engine-mode - (선택 사항) 소스 Aurora DB 클러스터와 다른 유형의 복제본을 생성하는 경우에만 이 파라미터를 사용합니다. 다음과 같이 --engine-mode를 사용하여 전달할 값을 선택합니다.

      • provisioned을 사용하여 Aurora Serverless DB 클러스터에서 프로비저닝된 Aurora DB 클러스터 복제본을 생성합니다.

      • serverless를 사용하여 프로비저닝된 Aurora DB 클러스터에서 Aurora Serverless v1 DB 클러스터 복제본을 생성합니다. serverless 엔진 모드를 지정할 때 --scaling-configuration을 선택할 수도 있습니다.

    • --scaling-configuration - (선택 사항) --engine-mode serverless를 사용하여 Aurora Serverless v1 복제본의 최소 및 최대 용량을 구성합니다. 이 파라미터를 사용하지 않는 경우 Aurora가 DB 엔진의 기본 용량 값을 사용하여 복제본을 생성합니다.

    • --serverless-v2-scaling-configuration - (선택 사항) 이 파라미터를 사용하여 Aurora Serverless v2 복제본의 최소 및 최대 용량을 구성합니다. 이 파라미터를 사용하지 않는 경우 Aurora가 DB 엔진의 기본 용량 값을 사용하여 복제본을 생성합니다.

다음 예제에서는 my-source-cluster라는 이름의 프로비저닝된 Aurora DB 클러스터에서 Aurora Serverless v1 복제본(my-clone)을 생성합니다. 프로비저닝된 Aurora DB 클러스터가 암호화됩니다.

Linux, macOS, Unix:

aws rds restore-db-cluster-to-point-in-time \ --source-db-cluster-identifier my-source-cluster \ --db-cluster-identifier my-clone \ --engine-mode serverless \ --scaling-configuration MinCapacity=8,MaxCapacity=64 \ --restore-type copy-on-write \ --use-latest-restorable-time

Windows의 경우:

aws rds restore-db-cluster-to-point-in-time ^ --source-db-cluster-identifier my-source-cluster ^ --db-cluster-identifier my-clone ^ --engine-mode serverless ^ --scaling-configuration MinCapacity=8,MaxCapacity=64 ^ --restore-type copy-on-write ^ --use-latest-restorable-time

이 명령은 DB 인스턴스를 생성하는 데 필요한 복제본의 세부 정보가 포함된 JSON 객체를 반환합니다. 복제본 상태(빈 Aurora DB 클러스터)가 사용 가능(Available) 상태가 될 때까지는 작업을 수행할 수 있습니다.

참고

restore-db-cluster-to-point-in-time AWS CLI 명령은 해당 DB 클러스터의 DB 인스턴스가 아닌 DB 클러스터만 복원합니다. --db-cluster-identifier에 복원된 DB 클러스터의 식별자를 지정하여 복원된 DB 클러스터의 DB 인스턴스를 생성하려면 create-db-instance 명령을 호출해야 합니다. restore-db-cluster-to-point-in-time 명령이 완료되고 DB 클러스터를 사용 가능할 때만 DB 인스턴스를 생성할 수 있습니다.

예를 들어 복제하고자 하는 tpch100g라는 이름의 클러스터가 있다고 가정합니다. 다음 Linux 예제는 tpch100g-clone라는 복제된 클러스터와 새 클러스터용 tpch100g-clone-instance라는 기본 인스턴스를 만듭니다. --master-username--master-user-password와 같은 일부 파라미터를 제공할 필요가 없습니다. Aurora는 원본 클러스터에서 파라미터를 자동으로 결정합니다. 사용할 DB 엔진을 지정해야 합니다. 따라서 이 예제는 새 클러스터를 테스트하여 --engine 파라미터에 사용할 올바른 값을 결정합니다.

$ aws rds restore-db-cluster-to-point-in-time \ --source-db-cluster-identifier tpch100g \ --db-cluster-identifier tpch100g-clone \ --restore-type copy-on-write \ --use-latest-restorable-time $ aws rds describe-db-clusters \ --db-cluster-identifier tpch100g-clone \ --query '*[].[Engine]' \ --output text aurora-mysql $ aws rds create-db-instance \ --db-instance-identifier tpch100g-clone-instance \ --db-cluster-identifier tpch100g-clone \ --db-instance-class db.r5.4xlarge \ --engine aurora-mysql

상태 확인 및 복제본 세부 정보 가져오기

다음 명령을 사용하여 새로 생성된 빈 DB 클러스터의 상태를 확인할 수 있습니다.

$ aws rds describe-db-clusters --db-cluster-identifier my-clone --query '*[].[Status]' --output text

또는 다음 AWS CLI 쿼리를 사용하여 복제본에 대한 DB 인스턴스를 생성하는 데 필요한 다른 값 및 상태를 가져올 수 있습니다.

Linux, macOS, Unix:

aws rds describe-db-clusters --db-cluster-identifier my-clone \ --query '*[].{Status:Status,Engine:Engine,EngineVersion:EngineVersion,EngineMode:EngineMode}'

Windows의 경우:

aws rds describe-db-clusters --db-cluster-identifier my-clone ^ --query "*[].{Status:Status,Engine:Engine,EngineVersion:EngineVersion,EngineMode:EngineMode}"

이 쿼리는 다음과 비슷한 출력을 반환합니다.

[ { "Status": "available", "Engine": "aurora-mysql", "EngineVersion": "8.0.mysql_aurora.3.04.1", "EngineMode": "provisioned" } ]

복제본에 대한 Aurora DB 인스턴스 생성

create-db-instance CLI 명령을 사용하여 Aurora Serverless v2 또는 프로비저닝된 복제본에 대한 DB 인스턴스를 생성합니다. Aurora Serverless v1 클론을 위한 DB 인스턴스는 만들지 않습니다.

DB 인스턴스는 소스 DB 클러스터에서 --master-username--master-user-password 속성을 상속합니다.

다음은 프로비저닝된 복제본에 대한 DB 인스턴스를 생성하는 예제입니다.

Linux, macOS, Unix:

aws rds create-db-instance \ --db-instance-identifier my-new-db \ --db-cluster-identifier my-clone \ --db-instance-class db.r5.4xlarge \ --engine aurora-mysql

Windows의 경우:

aws rds create-db-instance ^ --db-instance-identifier my-new-db ^ --db-cluster-identifier my-clone ^ --db-instance-class db.r5.4xlarge ^ --engine aurora-mysql

복제본에 사용할 파라미터

다음 표에는 restore-db-cluster-to-point-in-time에서 Aurora DB 클러스터를 복제하는 데 사용되는 다양한 파라미터가 요약되어 있습니다.

파라미터 설명

--source-db-cluster-identifier

복제할 소스 Aurora DB 클러스터의 이름을 사용합니다.

--db-cluster-identifier

restore-db-cluster-to-point-in-time 명령을 사용하여 복제본을 생성할 때는 의미가 있는 이름을 지정하세요. 그런 다음 이 이름을 create-db-instance 명령으로 전달합니다.

--restore-type

copy-on-write--restore-type로 지정하여 소스 Aurora DB 클러스터를 복원하는 대신 소스 DB 클러스터의 복제본을 생성합니다.

--use-latest-restorable-time

이 값은 소스 DB 클러스터에 대해 복원 가능한 최신 볼륨 데이터를 가리킵니다. 이를 사용하여 클론을 생성할 수 있습니다.

--engine-mode

이 파라미터를 사용하여 소스 Aurora DB 클러스터와 다른 유형의 복제본을 생성합니다. 복제본에는 다음 값 중 하나가 포함되어야 합니다.

  • provisioned를 사용하여 Aurora Serverless v1 DB 클러스터에서 프로비저닝된 복제본 또는 Aurora Serverless v2 복제본을 생성합니다.

  • serverless를 사용하여 프로비저닝된 DB 클러스터 또는 Aurora Serverless v2 DB 클러스터에서 Aurora Serverless v1 복제본을 생성합니다.

    serverless 엔진 모드를 지정할 때 --scaling-configuration을 선택할 수도 있습니다.

--scaling-configuration

이 파라미터를 사용하여 Aurora Serverless v1 복제본의 최소 및 최대 용량을 구성합니다. 이 파라미터를 지정하지 않는 경우 Aurora가 DB 엔진의 기본 용량 값을 사용하여 복제본을 생성합니다.

--serverless-v2-scaling-configuration

이 파라미터를 사용하여 Aurora Serverless v2 복제본의 최소 및 최대 용량을 구성합니다. 이 파라미터를 지정하지 않는 경우 Aurora가 DB 엔진의 기본 용량 값을 사용하여 복제본을 생성합니다.

AWS RAM과 Amazon Aurora에서 교차 계정 복제

Amazon Aurora에서 AWS Resource Access Manager(AWS RAM)를 사용하여 사용자 AWS 계정에 속한 Aurora DB 클러스터와 복제본을 다른 AWS 계정 또는 조직과 공유할 수 있습니다. 이러한 교차 계정 복제는 데이터베이스 스냅샷을 생성하여 복원하는 것보다 훨씬 빠릅니다. Aurora DB 클러스터 중 하나의 복제본을 생성하고 복제본을 공유할 수 있습니다. 또는 Aurora DB 클러스터를 다른 AWS 계정과 공유하고 계정 소유자가 복제본을 생성하도록 합니다. 선택한 접근 방식은 사용 사례에 따라 다릅니다.

예를 들어 재무 데이터베이스의 복제본을 조직의 내부 감사 팀과 정기적으로 공유해야 할 수 있습니다. 이 경우 감사 팀은 사용하는 애플리케이션에 대한 자체 AWS 계정을 갖게 됩니다. 감사 팀의 AWS 계정에 Aurora DB 클러스터에 액세스하고 필요에 따라 복제할 수 있는 권한을 부여할 수 있습니다.

반면 외부 공급업체가 재무 데이터를 감사하는 경우 복제본을 직접 생성하는 것이 좋습니다. 그런 다음 외부 공급업체에게 복제본에 대한 액세스 권한만 부여합니다.

교차 계정 복제를 사용하여 개발 및 테스트와 같은 동일한 AWS 계정 내의 복제에 대해 동일한 사용 사례를 지원할 수 있습니다. 예를 들어 조직에서 프로덕션, 개발 및 테스트 등에 대해 다른 AWS 계정을 사용할 수 있습니다. 자세한 내용은 Aurora 복제 개요 섹션을 참조하세요.

따라서 복제본을 다른 AWS 계정과 공유하거나 다른 AWS 계정에서 Aurora DB 클러스터의 복제본을 만들 수 있도록 허용할 수 있습니다. 두 경우 모두 AWS RAM을 사용하여 공유 객체를 생성합니다. AWS 계정 간의 AWS 리소스 공유에 대한 전체 내용은 AWS RAM 사용 설명서를 참조하세요.

계정 간 복제본을 만들려면 원본 클러스터를 소유하고 있는 AWS 계정과 복제본을 생성하는 AWS 계정에서 몇 가지 작업이 필요합니다. 먼저 원본 클러스터 소유자가 클러스터를 수정하여 하나 이상의 계정에서 클러스터를 복제할 수 있도록 합니다. 계정 중 하나라도 다른 AWS 조직에 있으면 AWS는 공유 초대를 생성합니다. 다른 계정은 진행하기 전에 초대를 수락해야 합니다. 그러면 승인된 계정에서 클러스터를 복제할 수 있습니다. 이러한 프로세스 전체에서 클러스터는 고유한 Amazon 리소스 이름(ARN)으로 식별합니다.

동일한 AWS 계정 내의 복제와 마찬가지로 소스 또는 복제본에서 데이터를 변경한 경우에만 추가 스토리지 공간이 사용됩니다. 그런 다음 해당 시점에 스토리지 요금이 적용됩니다. 원본 클러스터가 삭제되면 스토리지 비용이 나머지 복제된 클러스터로 동일하게 배분됩니다.

계정 간 복제 제한 사항

Aurora 계정 간 복제는 다음과 같은 제한 사항이 있습니다.

  • Aurora Serverless v1 클러스터는 AWS 계정 간 복제가 불가능합니다.

  • AWS Management Console을 사용하여 공유 리소스에 대한 초대를 보거나 수락할 수 없습니다. AWS CLI, Amazon RDS API 또는 AWS RAM 콘솔을 사용하여 공유 리소스에 대한 초대를 보고 수락할 수 있습니다.

  • 새 복제본은 AWS 계정과 공유 중인 복제본에서만 생성할 수 없습니다.

  • AWS 계정과 공유 중인 리소스(복제본 또는 Aurora DB 클러스터)를 공유할 수 없습니다.

  • 단일 Aurora DB 클러스터에서 최대 15개의 교차 계정 복제본을 생성할 수 있습니다.

  • 이 15개의 교차 계정 복제본은 각각 다른 AWS 계정에서 소유해야 합니다. 즉, AWS 계정 내 클러스터의 교차 계정 복제본을 하나만 생성할 수 있습니다.

  • 클러스터를 복제한 후 교차 계정 복제본에 대한 제한을 적용하기 위해 원래 클러스터와 복제본이 동일한 것으로 간주됩니다. 동일한 AWS 계정 내에서 원래 클러스터와 복제된 클러스터의 교차 계정 복제본을 생성할 수 없습니다. 원래 클러스터와 해당 복제본의 총 교차 계정 복제본 수는 15개를 초과할 수 없습니다.

  • 클러스터가 ACTIVE 상태에 있을 때만 Aurora DB 클러스터를 다른 AWS 계정과 공유할 수 있습니다.

  • 다른 AWS 계정과 공유 중인 Aurora DB 클러스터의 이름은 변경할 수 없습니다.

  • 클러스터가 기본 RDS 키로 암호화되어 있으면 계정 간 복제본을 생성할 수 없습니다.

  • 다른 AWS 계정이 공유한 암호화된 Aurora DB 클러스터에서는 하나의 AWS 계정에 암호화되지 않은 복제본을 만들 수 없습니다. 또한 클러스터 소유자는 소스 클러스터의 AWS KMS key에 액세스할 수 있는 권한을 부여해야 합니다. 하지만 복제본을 생성할 때는 다른 키를 사용해도 됩니다.

다른 AWS 계정에서 클러스터를 복제하도록 허용

다른 AWS 계정에서 자신이 소유한 클러스터를 복제하도록 허용하려면 AWS RAM을 사용해 공유 권한을 설정합니다. 이때 다른 AWS 조직에 속한 나머지 계정 모두에게 초대장을 전송합니다.

AWS RAM 콘솔에서 자신이 소유한 리소스를 공유하는 방법에 대한 자세한 내용은 AWS RAM 사용 설명서에서 자신이 소유한 리소스 공유를 참조하세요.

다른 AWS 계정에 클러스터를 복제할 수 있는 권한 부여

공유하고 있는 클러스터가 암호화되어 있으면 해당 클러스터의 AWS KMS key도 공유합니다. 한 AWS 계정의 AWS Identity and Access Management(IAM) 사용자 또는 역할이 다른 계정의 KMS 키를 사용하도록 허용할 수 있습니다.

이를 위해서는 먼저 외부 계정(루트 사용자)을 AWS KMS을(를) 통해 KMS 키의 키 정책에 추가합니다. 개별 사용자 또는 역할이 아니고 사용자 또는 역할을 소유한 외부 계정을 추가하는 것입니다. 또한 사용자가 생성하는 KMS 키만 공유할 수 있으며, 기본 RDS 서비스 키는 공유하지 못합니다. KMS 키 액세스 제어에 대한 자세한 내용은 AWS KMS에 대한 인증 및 액세스 제어를 참조하세요.

클러스터를 복제할 수 있는 권한을 부여하려면
  1. AWS Management Console에 로그인한 후 https://console.aws.amazon.com/rds/에서 Amazon RDS 콘솔을 엽니다.

  2. 탐색 창에서 데이터베이스를 선택합니다.

  3. 세부 정보 페이지를 볼 수 있도록 공유할 DB 클러스터와 Connectivity & security(연결 및 보안) 탭을 차례대로 선택합니다.

  4. 다른 AWS 계정과 DB 클러스터 공유 섹션에서 해당 클러스터의 복제를 허용할 AWS 계정의 숫자 계정 ID를 입력합니다. 동일한 조직의 계정 ID라면 입력란에 입력을 시작한 후 메뉴에서 선택할 수 있습니다.

    중요

    경우에 따라 자신의 계정과 다른 AWS 조직에 속하는 계정에게 클러스터 복제를 허용해야 할 수도 있습니다. 이때는 보안을 이유로 콘솔은 해당 계정 ID의 소유자 또는 계정 존재 여부를 보고하지 않습니다.

    자신의 AWS 계정과 다른 AWS 조직에 속하는 계정 숫자를 입력할 때는 주의해야 합니다. 원하는 계정과의 공유 여부를 바로 확인하십시오.

  5. 확인 페이지에서 지정한 계정 ID가 정확한지 확인합니다. 확인 입력란에 share를 입력하여 확인합니다.

    [세부 정보(Details)] 페이지에서 [이 DB 클러스터를 공유하는 계정(Accounts that this DB cluster is shared with)] 아래 지정된 AWS 계정 ID를 보여 주는 항목이 나타납니다. 상태 열이 처음에는 대기 중으로 표시됩니다.

  6. 해당 AWS 계정 소유자에게 연락하거나, 혹은 두 계정을 모두 소유하고 있다면 해당 계정에 로그인합니다. 해당 계정 소유자에게 공유 초대장을 승인한 후 다음과 같이 DB 클러스터를 복제하도록 지시합니다.

클러스터를 복제할 수 있는 권한을 부여하려면
  1. 필요한 파라미터 정보를 수집합니다. 클러스터 ARN과 다른 AWS 계정의 숫자 ID가 필요합니다.

  2. AWS RAM CLI 명령인 create-resource-share를 실행합니다.

    Linux, macOS, Unix:

    aws ram create-resource-share --name descriptive_name \ --region region \ --resource-arns cluster_arn \ --principals other_account_ids

    Windows의 경우:

    aws ram create-resource-share --name descriptive_name ^ --region region ^ --resource-arns cluster_arn ^ --principals other_account_ids

    --principals 파라미터에서 다수의 계정 ID를 추가하려면 공백으로 각 ID를 구분하십시오. 자신의 AWS 조직 외부에 존재하는 계정 ID의 허용 여부를 지정하려면 --allow-external-principals에서 --no-allow-external-principals 또는 create-resource-share 파라미터를 추가합니다.

클러스터를 복제할 수 있는 권한을 부여하려면
  1. 필요한 파라미터 정보를 수집합니다. 클러스터 ARN과 다른 AWS 계정의 숫자 ID가 필요합니다.

  2. AWS RAM API 작업인 CreateResourceShare를 호출한 후 다음 값을 지정합니다.

    • 하나 이상의 AWS 계정에 대한 계정 ID를 principals 파라미터로 지정합니다.

    • 하나 이상의 Aurora DB 클러스터의 ARN을 resourceArns 파라미터로 지정합니다.

    • allowExternalPrincipals 파라미터에 부울 값을 추가하여 자신의 AWS 조직 외부에 존재하는 계정 ID의 허용 여부를 지정합니다.

기본 RDS 키를 사용하는 클러스터 재생성

공유하려는 암호화된 클러스터가 기본 RDS 키를 사용하는 경우 클러스터를 재생성해야 합니다. 이렇게 하려면 DB 클러스터의 수동 스냅샷을 생성하고 AWS KMS key을(를) 사용한 다음 클러스터를 새 클러스터로 복원합니다. 그런 다음 새 클러스터를 공유합니다. 이 프로세스를 수행하려면 다음 단계를 수행합니다.

기본 RDS 키를 사용해 암호화된 클러스터를 재생성하려면
  1. AWS Management Console에 로그인한 후 https://console.aws.amazon.com/rds/에서 Amazon RDS 콘솔을 엽니다.

  2. 탐색 창에서 스냅샷을 선택합니다.

  3. 자신의 스냅샷을 선택합니다.

  4. 작업에서 스냅샷 복사암호화 활성화를 차례대로 선택합니다.

  5. AWS KMS key에서 새롭게 사용할 암호화 키를 선택합니다.

  6. 복사된 스냅샷을 복원합니다. 이 작업을 수행하려면 의 절차를 수행합니다DB 클러스터 스냅샷에서 복원 새로운 DB 인스턴스는 새로운 암호화 키를 사용합니다.

  7. (선택 사항) 더 이상 필요 없다면 이전 DB 클러스터를 삭제합니다. 이 작업을 수행하려면 의 절차를 수행합니다DB 클러스터 스냅샷 삭제 단, 삭제 전에 새로운 클러스터에 필요한 데이터가 모두 있는지, 그리고 애플리케이션이 새로운 클러스터에 성공적으로 액세스하는지 확인하십시오.

소유하고 있는 클러스터가 다른 AWS 계정과 공유하는지 확인

다른 사용자에게 클러스터 공유 권한이 있는지 확인할 수 있습니다. 따라서 클러스터가 계정 간 최대 복제 수 제한에 접근하는지 파악하는 데 효과적입니다.

AWS RAM 콘솔을 사용하여 리소스를 공유하는 절차는 AWS RAM 사용 설명서에서 자신이 소유한 리소스 공유를 참조하세요.

소유한 클러스터가 다른 AWS 계정과 공유되는지 확인하려면 다음을 수행하세요.
  • 자신의 계정 ID를 리소스 소유자로, 그리고 클러스터 ARN을 리소스 ARN으로 사용하여 AWS RAM CLI 명령인 list-principals를 호출합니다. 다음 명령을 사용해 모든 공유 내역을 확인할 수 있습니다. 명령을 실행한 결과에서 클러스터 복제가 허용되는 AWS 계정을 알 수 있습니다.

    aws ram list-principals \ --resource-arns your_cluster_arn \ --principals your_aws_id
소유한 클러스터가 다른 AWS 계정과 공유되는지 확인하려면 다음을 수행하세요.
  • AWS RAM API 작업 ListPrincipals를 호출합니다. 자신의 계정 ID를 리소스 소유자로, 그리고 클러스터 ARN을 리소스 ARN으로 사용합니다.

다른 AWS 계정에서 소유하고 있는 클러스터 복제

다른 AWS 계정에서 소유한 클러스터를 복제하려면 AWS RAM을 사용해 복제 권한을 획득해야 합니다. 필요한 권한을 가져온 후에는 표준 절차에 따라 Aurora 클러스터를 복제합니다.

또한 현재 소유하고 있는 클러스터가 다른 AWS 계정에서 소유하고 있는 클러스터의 복제본인지 알 수도 있습니다.

AWS RAM 콘솔에서 다른 계정이 소유하고 있는 리소스를 사용해 작업하는 방법은 AWS RAM 사용 설명서에서 공유 리소스에 대한 액세스를 참조하세요.

다른 AWS 계정에서 소유하고 있는 클러스터 복제 초대장 보기

다른 AWS 조직의 AWS 계정에서 소유하고 있는 클러스터에 대한 복제 초대장 작업을 할 때는 AWS CLI, AWS RAM 콘솔 또는 AWS RAM API를 사용합니다. 현재 Amazon RDS 콘솔에서는 이러한 절차를 수행할 수 없습니다.

AWS RAM 콘솔에서 초대장 작업에 대한 절차는 AWS RAM 사용 설명서에서 공유 리소스에 대한 액세스를 참조하세요.

다른 AWS 계정에서 소유하고 있는 클러스터 복제 초대장을 보려면
  1. AWS RAM CLI 명령인 get-resource-share-invitations를 실행합니다.

    aws ram get-resource-share-invitations --region region_name

    위 명령을 실행한 결과에서 이전에 승인하거나 거부한 초대장을 포함해 클러스터 복제 초대장을 모두 볼 수 있습니다.

  2. (선택 사항) 자신의 작업이 필요한 초대장만 표시되도록 목록을 필터링할 수 있습니다. 파라미터로 --query 'resourceShareInvitations[?status==`PENDING`]'를 추가하기만 하면 됩니다.

다른 AWS 계정에서 소유하고 있는 클러스터 복제 초대장을 보려면
  1. AWS RAM API 작업 GetResourceShareInvitations를 호출합니다. 그러면 이전에 승인하거나 거부한 초대장을 포함해 해당하는 초대장이 모두 반환됩니다.

  2. (선택 사항) resourceShareAssociations 반환 필드에서 status 값의 PENDING 유무를 확인하여 자신의 작업이 필요한 초대장만 찾아볼 수 있습니다.

다른 AWS 계정에서 소유하고 있는 클러스터에 대한 공유 초대장 승인

다른 AWS 조직의 AWS 계정에서 소유하고 있는 클러스터에 대한 공유 초대장을 승인할 수 있습니다. 해당 초대장 작업은 AWS CLI, AWS RAM 및 RDS API 또는 AWS RAM 콘솔을 사용합니다. 현재 RDS 콘솔에서는 이러한 절차를 수행할 수 없습니다.

AWS RAM 콘솔에서 초대장 작업에 대한 절차는 AWS RAM 사용 설명서에서 공유 리소스에 대한 액세스를 참조하세요.

다른 AWS 계정에서 클러스터 공유 초대장을 승인하려면
  1. 앞에서 한 것처럼 AWS RAM CLI 명령인 get-resource-share-invitations를 실행하여 초대장 ARN을 찾습니다.

  2. 다음과 같이 AWS RAM CLI 명령인 accept-resource-share-invitation을 호출하여 초대장을 승인합니다.

    Linux, macOS, Unix:

    aws ram accept-resource-share-invitation \ --resource-share-invitation-arn invitation_arn \ --region region

    Windows의 경우:

    aws ram accept-resource-share-invitation ^ --resource-share-invitation-arn invitation_arn ^ --region region
다른 사용자의 클러스터 공유 초대장을 승인하려면
  1. 앞에서 한 것처럼 AWS RAM API 작업 GetResourceShareInvitations를 호출하여 초대장 ARN을 찾습니다.

  2. 해당 ARN을 resourceShareInvitationArn 파라미터로 RDS API 작업인 AcceptResourceShareInvitation에게 전달합니다.

다른 AWS 계정에서 소유하고 있는 Aurora 클러스터 복제

위와 같이 DB 클러스터를 소유하고 있는 AWS 계정의 초대장을 승인하였다면 이제 클러스터를 복제할 수 있습니다.

다른 AWS 계정에서 소유하고 있는 Aurora 클러스터를 복제하려면
  1. AWS Management Console에 로그인한 후 https://console.aws.amazon.com/rds/에서 Amazon RDS 콘솔을 엽니다.

  2. 탐색 창에서 데이터베이스를 선택합니다.

    데이터베이스 목록 상단에서 역할 값이 Shared from account #account_id인 항목이 1개 이상 표시됩니다. 보안을 이유로 직접 확인할 수 있는 원본 클러스터 정보는 제한적입니다. 확인할 수 있는 속성은 복제 클러스터에서 동일해야 하는 데이터베이스 엔진 및 버전 등입니다.

  3. 복제할 클러스터를 선택합니다.

  4. 작업에서 복제본 생성을 선택합니다.

  5. 콘솔 단원의 절차에 따라 복제 클러스터의 설정을 마칩니다.

  6. 필요하다면 복제 클러스터의 암호화를 활성화합니다. 복제할 클러스터가 암호화되어 있다면 복제 클러스터에서도 암호화를 활성화해야 합니다. 사용자와 클러스터를 공유한 AWS 계정 역시 클러스터를 암호화하는 데 사용된 KMS 키를 공유해야 합니다. 복제본을 암호화할 때는 동일한 KMS 키를 사용하거나, 사용자 고유의 KMS 키를 사용해도 좋습니다. 클러스터가 기본 KMS 키로 암호화되어 있으면 계정 간 복제본을 생성할 수 없습니다.

    암호화 키를 소유한 계정은 키 정책에 따라 대상 계정에게 키를 사용할 수 있는 권한을 부여해야 합니다. 이러한 프로세스는 대상 계정에게 키 사용 권한을 부여하는 키 정책에 따라 암호화된 스냅샷을 공유하는 방법과 비슷합니다.

다른 AWS 계정에서 소유하고 있는 Aurora 클러스터를 복제하려면
  1. 위와 같이 DB 클러스터를 소유하고 있는 AWS 계정의 초대장을 승인합니다.

  2. 다음과 같이 RDS CLI 명령인 source-db-cluster-identifierrestore-db-cluster-to-point-in-time 파라미터에서 원본 클러스터의 전체 ARN을 지정하여 클러스터를 복제합니다.

    source-db-cluster-identifier로 전달된 ARN을 아직 공유하지 않았다면 마치 지정된 클러스터가 존재하지 않는 것처럼 동일한 오류 메시지가 반환됩니다.

    Linux, macOS, Unix:

    aws rds restore-db-cluster-to-point-in-time \ --source-db-cluster-identifier=arn:aws:rds:arn_details \ --db-cluster-identifier=new_cluster_id \ --restore-type=copy-on-write \ --use-latest-restorable-time

    Windows의 경우:

    aws rds restore-db-cluster-to-point-in-time ^ --source-db-cluster-identifier=arn:aws:rds:arn_details ^ --db-cluster-identifier=new_cluster_id ^ --restore-type=copy-on-write ^ --use-latest-restorable-time
  3. 복제할 클러스터가 암호화되어 있으면 kms-key-id 파라미터를 추가하여 복제 클러스터도 암호화합니다. kms-key-id 값은 원본 DB 클러스터를 암호화할 때 사용한 것과 동일하거나, 혹은 사용자 고유의 KMS 키가 될 수도 있습니다. 단, 암호화 키를 사용할 수 있는 권한이 계정에게 있어야 합니다.

    Linux, macOS, Unix:

    aws rds restore-db-cluster-to-point-in-time \ --source-db-cluster-identifier=arn:aws:rds:arn_details \ --db-cluster-identifier=new_cluster_id \ --restore-type=copy-on-write \ --use-latest-restorable-time \ --kms-key-id=arn:aws:kms:arn_details

    Windows의 경우:

    aws rds restore-db-cluster-to-point-in-time ^ --source-db-cluster-identifier=arn:aws:rds:arn_details ^ --db-cluster-identifier=new_cluster_id ^ --restore-type=copy-on-write ^ --use-latest-restorable-time ^ --kms-key-id=arn:aws:kms:arn_details

    암호화 키를 소유한 계정은 키 정책에 따라 대상 계정에게 키를 사용할 수 있는 권한을 부여해야 합니다. 이러한 프로세스는 대상 계정에게 키 사용 권한을 부여하는 키 정책에 따라 암호화된 스냅샷을 공유하는 방법과 비슷합니다. 키 정책 예제는 다음과 같습니다.

    { "Id": "key-policy-1", "Version": "2012-10-17", "Statement": [ { "Sid": "Allow use of the key", "Effect": "Allow", "Principal": {"AWS": [ "arn:aws:iam::account_id:user/KeyUser", "arn:aws:iam::account_id:root" ]}, "Action": [ "kms:CreateGrant", "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "*" }, { "Sid": "Allow attachment of persistent resources", "Effect": "Allow", "Principal": {"AWS": [ "arn:aws:iam::account_id:user/KeyUser", "arn:aws:iam::account_id:root" ]}, "Action": [ "kms:CreateGrant", "kms:ListGrants", "kms:RevokeGrant" ], "Resource": "*", "Condition": {"Bool": {"kms:GrantIsForAWSResource": true}} } ] }
참고

restore-db-cluster-to-point-in-time AWS CLI 명령은 해당 DB 클러스터의 DB 인스턴스가 아닌 DB 클러스터만 복원합니다. 복원된 DB 클러스터에 대한 DB 인스턴스를 생성하려면 create-db-instance 명령을 호출합니다. --db-cluster-identifier에서 복원된 DB 클러스터의 식별자를 지정합니다.

restore-db-cluster-to-point-in-time 명령이 완료되고 DB 클러스터를 사용 가능할 때만 DB 인스턴스를 생성할 수 있습니다.

다른 AWS 계정에서 소유하고 있는 Aurora 클러스터를 복제하려면
  1. 위와 같이 DB 클러스터를 소유하고 있는 AWS 계정의 초대장을 승인합니다.

  2. RDS API 작업인 SourceDBClusterIdentifierRestoreDBClusterToPointInTime 파라미터에서 원본 클러스터의 전체 ARN을 지정하여 클러스터를 복제합니다.

    SourceDBClusterIdentifier로 전달된 ARN을 아직 공유하지 않았다면 마치 지정된 클러스터가 존재하지 않는 것처럼 동일한 오류 메시지가 반환됩니다.

  3. 복제할 클러스터가 암호화되어 있으면 KmsKeyId 파라미터를 추가하여 복제 클러스터도 암호화합니다. kms-key-id 값은 원본 DB 클러스터를 암호화할 때 사용한 것과 동일하거나, 혹은 사용자 고유의 KMS 키가 될 수도 있습니다. 단, 암호화 키를 사용할 수 있는 권한이 계정에게 있어야 합니다.

    볼륨을 복제할 때는 원본 클러스터를 암호화할 때 사용한 암호화 키를 사용할 수 있는 권한이 대상 계정에게 필요합니다. Aurora는 KmsKeyId에 지정된 암호화 키를 사용하여 새로 복제된 클러스터를 암호화합니다.

    암호화 키를 소유한 계정은 키 정책에 따라 대상 계정에게 키를 사용할 수 있는 권한을 부여해야 합니다. 이러한 프로세스는 대상 계정에게 키 사용 권한을 부여하는 키 정책에 따라 암호화된 스냅샷을 공유하는 방법과 비슷합니다. 키 정책 예제는 다음과 같습니다.

    { "Id": "key-policy-1", "Version": "2012-10-17", "Statement": [ { "Sid": "Allow use of the key", "Effect": "Allow", "Principal": {"AWS": [ "arn:aws:iam::account_id:user/KeyUser", "arn:aws:iam::account_id:root" ]}, "Action": [ "kms:CreateGrant", "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "*" }, { "Sid": "Allow attachment of persistent resources", "Effect": "Allow", "Principal": {"AWS": [ "arn:aws:iam::account_id:user/KeyUser", "arn:aws:iam::account_id:root" ]}, "Action": [ "kms:CreateGrant", "kms:ListGrants", "kms:RevokeGrant" ], "Resource": "*", "Condition": {"Bool": {"kms:GrantIsForAWSResource": true}} } ] }
참고

RestoreDBClusterToPointInTime RDS API 작업은 DB 클러스터만 복원하고, 해당 DB 클러스터의 DB 인스턴스는 복원하지 않습니다. RDS API 작업 CreateDBInstance를 호출하여 복원된 DB 클러스터의 기본 인스턴스를 만듭니다. DBClusterIdentifier에서 복원된 DB 클러스터의 식별자를 지정합니다. RestoreDBClusterToPointInTime 작업이 완료되고 DB 클러스터를 사용할 수 있어야만 DB 인스턴스를 생성할 수 있습니다.

DB 클러스터의 계정 간 복제본 여부 확인

DBClusters 객체는 각 클러스터의 계정 간 복제본 여부를 식별합니다. RDS CLI 명령인 include-shared를 실행할 때 describe-db-clusters 옵션을 사용해 자신에게 복제 권한이 있는 클러스터를 알아볼 수 있습니다. 하지만 해당 클러스터의 구성 세부 정보는 대부분 볼 수 없습니다.

DB 클러스터가 교차 계정 복제인지 확인하려면
  • RDS CLI 명령인 describe-db-clusters를 호출합니다.

    다음 예제는 실제 또는 잠재적 계정 간 복제 DB 클러스터가 describe-db-clusters 출력 시 어떻게 표시되는지 나타낸 것입니다. AWS 계정에서 소유하고 있는 기존 계정이라면 CrossAccountClone 필드에서 클러스터가 다른 AWS 계정에서 소유하고 있는 DB 클러스터의 복제본인지 알 수 있습니다.

    경우에 따라 AWS 필드에 자신과 다른 DBClusterArn 계정 번호의 항목이 존재할 수 있습니다. 이러한 경우 해당 항목은 다른 AWS 계정에서 소유하고 있지만 자신이 복제할 수 있는 클러스터라는 것을 의미합니다. 이러한 항목은 DBClusterArn 외에 다른 필드가 거의 없습니다. 복제 클러스터를 생성할 때는 StorageEncrypted, EngineEngineVersion 값을 원본 클러스터와 동일하게 지정합니다.

    $aws rds describe-db-clusters --include-shared --region us-east-1 { "DBClusters": [ { "EarliestRestorableTime": "2023-02-01T21:17:54.106Z", "Engine": "aurora-mysql", "EngineVersion": "8.0.mysql_aurora.3.02.0", "CrossAccountClone": false, ... }, { "EarliestRestorableTime": "2023-02-09T16:01:07.398Z", "Engine": "aurora-mysql", "EngineVersion": "8.0.mysql_aurora.3.02.0", "CrossAccountClone": true, ... }, { "StorageEncrypted": false, "DBClusterArn": "arn:aws:rds:us-east-1:12345678:cluster:cluster-abcdefgh", "Engine": "aurora-mysql", "EngineVersion": "8.0.mysql_aurora.3.02.0 ] }
DB 클러스터가 교차 계정 복제인지 확인하려면
  • RDS API 작업인 DescribeDBClusters를 호출합니다.

    AWS 계정에서 소유하고 있는 기존 계정이라면 CrossAccountClone 필드에서 클러스터가 다른 AWS 계정에서 소유하고 있는 DB 클러스터의 복제본인지 알 수 있습니다. AWS 필드에서 DBClusterArn 계정 번호가 다른 항목은 복제가 가능하지만 다른 AWS 계정에서 소유하고 있는 클러스터라는 것을 의미합니다. 이러한 항목은 DBClusterArn 외에 다른 필드가 거의 없습니다. 복제 클러스터를 생성할 때는 StorageEncrypted, EngineEngineVersion 값을 원본 클러스터와 동일하게 지정합니다.

    다음 예제는 실제 복제 클러스터와 잠재적 복제 클러스터를 모두 시연한 반환 값을 나타낸 것입니다.

    { "DBClusters": [ { "EarliestRestorableTime": "2023-02-01T21:17:54.106Z", "Engine": "aurora-mysql", "EngineVersion": "8.0.mysql_aurora.3.02.0", "CrossAccountClone": false, ... }, { "EarliestRestorableTime": "2023-02-09T16:01:07.398Z", "Engine": "aurora-mysql", "EngineVersion": "8.0.mysql_aurora.3.02.0", "CrossAccountClone": true, ... }, { "StorageEncrypted": false, "DBClusterArn": "arn:aws:rds:us-east-1:12345678:cluster:cluster-abcdefgh", "Engine": "aurora-mysql", "EngineVersion": "8.0.mysql_aurora.3.02.0" } ] }