여러 계정에 걸쳐 데이터베이스 및 계정 오브젝트 복제하기¶

1단계. 복제가 활성화된 데이터베이스에 대한 복제 비활성화하기¶

복제 또는 장애 조치 그룹에 추가하기 위해 기본 데이터베이스와 연결된 보조 데이터베이스에 대한 복제를 비활성화하는 SYSTEM$DISABLE_DATABASE_REPLICATION 함수를 실행합니다.

기본 데이터베이스가 있는 원본 계정에서 다음 SQL 문을 실행합니다.

SELECT SYSTEM$DISABLE_DATABASE_REPLICATION('mydb');

2단계. 기본 장애 조치 그룹에 데이터베이스를 추가하고 보조 장애 조치 그룹 생성하기¶

데이터베이스에 대한 복제를 성공적으로 비활성화했으면, 원본 계정의 장애 조치 그룹에 기본 데이터베이스를 추가할 수 있습니다.

그런 다음 대상 계정에 보조 장애 조치 그룹을 생성합니다. 보조 장애 조치 그룹이 대상 계정에서 새로 고쳐지면 이전의 보조 데이터베이스가 자동으로 보조 장애 조치 그룹의 구성원으로 추가되고, 기본 데이터베이스의 변경 사항으로 새로 고쳐집니다.

기본 및 보조 장애 조치 그룹 생성에 대한 자세한 내용은 워크플로 섹션을 참조하십시오.

예¶

선호하는 Snowflake 클라이언트에서 다음 SQL 문을 실행하여 계정 및 데이터베이스 오브젝트 복제 및 장애 조치를 활성화하고 오브젝트를 새로 고칩니다.

전제 조건: 조직의 계정에 대한 복제 활성화¶

조직 관리자(ORGADMIN 역할)는 원본 및 대상 계정에 대해 복제를 활성화해야 합니다.

계정에 대한 복제를 활성화하기 위해, ORGADMIN 역할을 가진 사용자는 SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER 함수를 사용하여 ENABLE_ACCOUNT_DATABASE_REPLICATION 매개 변수를 true 로 설정합니다. 조직의 여러 계정을 사용해 동일한 ORGADMIN 계정에서 복제할 수 있습니다.

ORGADMIN 계정에 로그인하여 조직에서 각 원본 계정과 대상 계정에 대해 복제를 활성화합니다.

USE ROLE ORGADMIN;

-- View the list of the accounts in your organization
-- Note the organization name and account name for each account for which you are enabling replication
SHOW ACCOUNTS;

-- Enable replication by executing this statement for each source and target account in your organization
SELECT SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER('<organization_name>.<account_name>', 'ENABLE_ACCOUNT_DATABASE_REPLICATION', 'true');

SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER 함수는 레거시 계정 로케이터 식별자를 지원하지만, 조직에 (다양한 리전에서) 같은 로케이터를 공유하는 계정이 여러 개 있을 때 예기치 않은 결과를 초래합니다.

1단계: 원본 계정에서 CREATE FAILOVER GROUP 권한이 있는 역할 만들기 — 선택 사항¶

역할을 생성하고 CREATE FAILOVER GROUP 권한을 부여합니다. 이 단계는 선택 사항입니다. 이 역할을 이미 만든 경우 2단계: 원본 계정에서 기본 장애 조치 그룹 생성하기 항목으로 건너뛰십시오.

USE ROLE ACCOUNTADMIN;

CREATE ROLE myrole;

GRANT CREATE FAILOVER GROUP ON ACCOUNT
    TO ROLE myrole;

2단계: 원본 계정에서 기본 장애 조치 그룹 생성하기¶

기본 장애 조치 그룹을 생성하고 현재(원본) 계정에서 동일 조직의 하나 이상의 대상 계정으로 특정 오브젝트의 복제 및 장애 조치를 활성화합니다.

SHOW REPLICATION ACCOUNTS;

+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| snowflake_region | created_on                    | account_name | account_locator | comment         | organization_name | is_org_admin |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| AWS_US_WEST_2    | 2020-07-15 21:59:25.455 -0800 | myaccount1   | myacctlocator1  |                 | myorg             | true         |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| AWS_US_EAST_1    | 2020-07-23 14:12:23.573 -0800 | myaccount2   | myacctlocator2  |                 | myorg             | false        |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| AWS_US_EAST_2    | 2020-07-25 19:25:04.412 -0800 | myaccount3   | myacctlocator3  |                 | myorg             | false        |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+

USE ROLE myrole;

CREATE FAILOVER GROUP myfg
    OBJECT_TYPES = USERS, ROLES, WAREHOUSES, RESOURCE MONITORS, DATABASES, INTEGRATIONS, NETWORK POLICIES
    ALLOWED_DATABASES = db1, db2
    ALLOWED_INTEGRATION_TYPES = API INTEGRATIONS
    ALLOWED_ACCOUNTS = myorg.myaccount2
    REPLICATION_SCHEDULE = '10 MINUTE';

3단계: 대상 계정에서 CREATE FAILOVER GROUP 권한이 있는 역할 만들기 — 선택 사항¶

대상 계정에서 역할을 생성하고 CREATE FAILOVER GROUP 권한을 부여합니다. 이 단계는 선택 사항입니다. 이 역할을 이미 만든 경우 4단계: 대상 계정에 보조 장애 조치 그룹 생성하기 항목으로 건너뛰십시오.

USE ROLE ACCOUNTADMIN;

CREATE ROLE myrole;

GRANT CREATE FAILOVER GROUP ON ACCOUNT
    TO ROLE myrole;

4단계: 대상 계정에 보조 장애 조치 그룹 생성하기¶

원본 계정의 기본 장애 조치 그룹의 복제본으로서 대상 계정에 보조 장애 조치 그룹을 생성합니다.

이 항목의 2단계: 원본 계정에서 기본 장애 조치 그룹 생성하기 에서 복제를 활성화한 각 대상 계정에서 CREATE FAILOVER GROUP … AS REPLICA OF 문을 실행합니다.

각 대상 계정에서 실행됨:

USE ROLE myrole;

CREATE FAILOVER GROUP myfg
  AS REPLICA OF myorg.myaccount1.myfg;

5단계. 대상 계정의 보조 장애 조치 그룹을 수동으로 새로 고침 — 선택 사항¶

대상 계정의 오브젝트를 수동으로 새로 고치려면 ALTER FAILOVER GROUP … REFRESH 명령을 실행합니다.

모범 사례로서 CREATE FAILOVER GROUP 또는 ALTER FAILOVER GROUP 항목을 사용하여 REPLICATION_SCHEDULE 매개 변수를 설정해 보조 새로 고침을 예약하는 것이 좋습니다.

6단계. 역할에 장애 조치 그룹에 대한 FAILOVER 권한 부여하기 — 선택 사항¶

대상 계정에서 보조 복제 또는 장애 조치 그룹에서 장애 조치를 수행하는 명령을 실행하려면, 장애 조치 그룹에 대한 FAILOVER 권한 이 있는 역할을 사용해야 합니다. FAILOVER 권한은 현재 복제되지 않으며 각 소스 및 대상 계정에서 부여해야 합니다.

자세한 내용은 역할 및 권한 부여 복제 섹션을 참조하십시오.

예를 들어, 장애 조치 그룹 my_fg 의 역할 my_failover_role 에 FAILOVER 권한을 부여하려면 그룹에서 OWNERSHIP 권한이 있는 역할을 사용하여 대상 계정 에서 다음 문을 실행합니다

GRANT FAILOVER ON FAILOVER GROUP myfg TO ROLE my_failover_role;

지정된 권한 세트로 사용자 지정 역할을 만드는 방법에 대한 지침은 사용자 지정 역할 만들기 섹션을 참조하십시오.

보안 오브젝트 에 대해 SQL 작업을 수행하기 위한 역할과 권한 부여에 대한 일반적인 정보는 액세스 제어의 개요 섹션을 참조하십시오.

SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME()을 사용하여 전역 ID 적용하기¶

원본 계정과 대상 계정에서 동일한 이름을 가진 일치하는 오브젝트를 연결하면 일부 오브젝트 유형의 손실을 방지할 수 있습니다. SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME 함수는 대상 계정의 계정 오브젝트에 전역 식별자를 추가합니다.

장애 조치 그룹 myfg 의 object_types 목록에 포함된 유형의 대상 계정에 있는 계정 오브젝트에 전역 식별자를 적용합니다.

ACCOUNTADMIN 역할을 사용하여 다음 SQL 문을 실행합니다.

SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('myfg');

사용자 및 역할의 초기 복제¶

USERS 및 ROLES 오브젝트 유형에 대한 초기 새로 고침 작업의 동작은 대상 계정에 동일한 이름을 가진 일치하는 오브젝트가 있는지 여부에 따라 달라질 수 있습니다.

• 대상 계정에 원본 계정의 사용자와 같은 이름을 가진 기존 사용자가 있는 경우 초기 새로 고침 작업이 실패하고 계속해야 하는 두 가지 옵션을 설명합니다.

  • 새로 고침 작업을 강제로 실행하고 대상 계정의 기존 사용자를 삭제하도록 허용합니다. 원본 계정의 사용자가 대상 계정에 복제됩니다.

    그룹을 강제로 새로 고치려면 새로 고침 명령에 FORCE 매개 변수를 사용하십시오. 예를 들어 장애 조치 그룹을 강제로 새로 고치려면 다음 명령을 실행하십시오.

    ALTER FAILOVER GROUP <fg_name> REFRESH FORCE;
    

    Copy

  • 계정 오브젝트를 이름별로 연결합니다. SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME 함수는 대상 계정과 원본 계정에서 모두 같은 이름을 가진 사용자를 연결합니다. 연결된 대상 계정의 사용자는 삭제되지 않습니다.

    계정 오브젝트를 이름별로 연결하려면 다음 문을 실행하십시오.

    SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('<rg_name>');
    

    Copy

    참고

    이름이 같은 원본 계정에 일치하는 사용자가 없는 대상 계정의 모든 사용자는 삭제됩니다.

• 원본 계정의 사용자와 이름이 일치하는 대상 계정의 사용자가 없는 경우 대상 계정의 초기 새로 고침 작업에서 모든 사용자가 삭제됩니다. 이로 인해 다음과 같은 데이터와 메타데이터가 손실될 수 있습니다.

  • 복제 또는 장애 조치 그룹의 OBJECT_TYPES 목록에 USERS가 포함된 경우:

    • 워크시트가 손실됩니다.

    • 쿼리 기록이 손실됩니다.

  • USERS가 OBJECT_TYPES 목록에 포함되지만 ROLES는 포함되지 않는 경우:

    • 사용자에게 부여된 권한이 손실됩니다.

  • ROLES가 OBJECT_TYPES 목록에 포함된 경우:

    • 오브젝트를 공유하기 위해 부여된 권한이 손실됩니다.

대상 계정에서 사용자나 역할을 삭제하지 않으려면 다음을 수행하십시오.

1. 원본 계정에서 초기 복제 전에 오직 대상 계정에만 존재하는 사용자나 역할을 전부 수동으로 다시 생성합니다.

2. 대상 계정에서 SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME 함수를 사용하여 두 계정에서 모두 동일한 이름을 가진 일치하는 오브젝트를 연결합니다.

Amazon S3¶

구성 프로세스는 이벤트 알림 설정 방법에 따라 다릅니다. 예를 들어 Snowflake 스테이지 위치에 대한 메시지를 게시하기 위해 Amazon SNS(Simple Notification Service) 항목에 의존하는 자동 수집 파이프가 있다고 가정해 보겠습니다.

파이프를 대상 계정에 복제하면 Snowflake가 새로운 Amazon SQS(Simple Queue Service) 큐를 자동으로 생성합니다. 스테이지 위치에 대한 알림을 받으려면 SNS 항목에 대해 대상 계정의 이 SQS 큐를 구독해야 합니다.

• Amazon SQS(Simple Queue Service)와 함께 Amazon S3 Event Notifications를 사용하는 경우 4단계: 이벤트 알림 구성 의 지침을 따르십시오.

  중요

  파이프가 알림을 놓치지 않았는지 확인하려면 새 SQS 큐로 전환한 후 파이프를 새로 고쳐야 합니다.

  SQS에서 SNS로 마이그레이션할 수도 있습니다. 자세한 내용은 Amazon SNS(Simple Notification Service)로 마이그레이션하기 섹션을 참조하십시오.

• Amazon SNS(Simple Notification Service)를 사용하는 경우 Snowflake SQS 큐에서 SNS 항목 구독하기 를 참조하십시오.

• Amazon EventBridge을 사용하는 경우 옵션 3: Snowpipe를 자동화하도록 Amazon EventBridge 설정 섹션을 참조하십시오.

Microsoft Azure Blob 저장소¶

Microsoft Azure Blob 저장소의 스테이지에 있는 파일에서 데이터를 자동으로 로드하는 파이프에는 Event Grid 구독, 저장소 큐, 저장소 큐에 바인딩된 알림 통합이 필요합니다. 대상 계정의 보조 파이프에는 별도의 Event Grid, 저장소 큐, 저장소 큐에 바인딩된 알림 통합이 필요합니다. 원본 계정과 대상 계정 모두의 Event Grid는 동일한 Azure Storage 원본의 엔드포인트로 구성해야 합니다.

구성 세부 정보는 아래 다이어그램을 참조하십시오.

새 Event Grid 구독 및 저장소 큐를 만듭니다. 그런 다음, 대상 계정에서 새 알림 통합을 생성하고 저장소 큐에 Snowflake 액세스 권한을 부여합니다. 자세한 지침은 Azure Event Grid를 사용한 자동화 구성하기 섹션을 참조하십시오.

Google Cloud Storage의 외부 스테이지¶

Google Cloud Storage에 있는 파일에서 데이터를 자동으로 로드하는 파이프에는 Google Pub/Sub 구독과 해당 구독을 참조하는 알림 통합이 필요합니다. 대상 계정에서 복제된 각 파이프에는 Google Pub/Sub 구독과 해당 구독을 참조하는 알림 통합도 필요합니다. 각 원본 및 대상 계정의 Pub/Sub 구독은 Google Cloud Storage 원본에서 알림을 받는 동일한 Pub/Sub 항목을 구독해야 합니다.

구성 세부 정보는 아래 다이어그램을 참조하십시오.

대상 계정에서 Pub/Sub 항목에 대한 새 구독과 새 알림 통합을 만듭니다.

그런 다음, Pub/Sub 구독에 Snowflake 액세스 권한을 부여합니다. 자세한 지침은 GCS Pub/Sub를 사용하여 자동화 구성하기 섹션을 참조하십시오.

Snowsight를 사용하여 복제 모니터링하기¶

조직의 복제 및 장애 조치 그룹 에 대한 복제 진행 상황과 상태를 모니터링하려면 Snowsight 의 Replication 페이지를 사용하십시오.

다음과 같이 새로 고침 작업의 상태와 세부 정보를 확인할 수 있습니다.

• 가장 최근 새로 고침 작업의 현재 상태.

• 복제본 지연 시간(마지막 새로 고침 작업 이후로 경과된 시간).

• 그룹 전체의 복제본 지연 시간 분포.

• 예약된 다음 새로 고침 날짜 및 시간.

각 복제 또는 장애 조치 그룹의 복제 상태를 확인하려면 다음 단계를 완료하십시오.

1. Snowsight 에 로그인하고 Admin » Accounts 로 이동합니다.

2. Replication 을 선택한 다음 Groups 를 선택합니다.

Groups 페이지에는 자신의 역할에 보기 권한이 부여된 모든 그룹의 새로 고침 작업 세부 정보 가 표시됩니다. 타일을 사용하여 뷰를 필터링할 수 있습니다.

• 예를 들어 Status 타일이 실패한 새로 고침 작업이 있음을 나타내는 경우 타일을 선택하여 실패한 작업이 있는 그룹을 조사할 수 있습니다.

• Longest Replication lag 타일의 지연 시간은 마지막 새로 고침 작업 이후의 시간을 나타냅니다. 이는 보조 복제 또는 장애 조치 그룹이 기본 그룹보다 지연 되는 시간입니다. 가장 긴 지연 시간은 가장 오래된 보조 복제 그룹이 마지막으로 새로 고쳐진 이후의 시간입니다.

  예를 들어 각각 10분, 2시간, 12시간의 독립적인 복제 일정이 있는 3개의 장애 조치 그룹(fg_1, fg_2, fg_3)이 있는 경우 가장 긴 지연 시간은 12시간이 될 수 있습니다. 하지만 fg_3 이 최근에 대상 계정에서 새로 고쳐진 경우 지연 시간이 0으로 재설정되고 다른 장애 조치 그룹의 지연 시간이 더 길 수 있습니다.

• Group Lag Distribution 타일에서 개별 막대를 선택하여 결과를 개별 그룹으로 필터링할 수 있습니다.

검색 필드나 드롭다운 메뉴를 사용하여 그룹을 필터링할 수도 있습니다.

• (검색) 상자를 사용하여 복제 또는 장애 조치 그룹 이름으로 검색할 수 있습니다.

• 복제 또는 장애 조치 그룹을 기준으로 결과를 필터링하려면 Type 을 선택하십시오.

• 기본 그룹(To 선택) 또는 보조 그룹(From 선택)을 기준으로 필터링하려면 Replicating 을 선택하십시오.

• 계정 이름을 기준으로 결과를 필터링하려면 (계정) 메뉴를 선택하십시오.

• 새로 고침 작업 상태를 기준으로 결과를 필터링하려면 Status 를 선택하십시오.

  • Refresh Cancelled

  • Refresh Failed

  • Refresh In Progress

  • Refresh Successful

복제 및 장애 조치 그룹에 대한 다음 세부 정보를 볼 수 있습니다.

복제 또는 장애 조치 그룹을 선택하여 각 새로 고침 작업에 대한 세부 정보를 확인할 수 있습니다. 자세한 내용은 Snowsight에서 복제 기록에 대한 섹션 을 참조하십시오.

새로 고침 작업 진행 상황 모니터링하기¶

이 섹션에서는 특정 복제 또는 장애 조치 그룹의 복제 진행 상황 모니터링 방법에 대한 정보를 제공합니다.

SELECT phase_name, start_time, end_time, progress, details
  FROM TABLE(INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_PROGRESS('myfg'));

복제 기록 보기¶

Snowsight 또는 SQL 을 사용하여 복제 기록을 확인할 수 있습니다.

Snowsight를 사용하여 복제 기록 보기¶

그룹의 세부 정보 페이지에서 특정 복제 또는 장애 조치 그룹에 대한 각 새로 고침 작업에 대한 복제 기록과 세부 정보를 확인할 수 있습니다.

1. Snowsight 에 로그인하고 Admin » Accounts 로 이동합니다.

2. Replication 을 선택한 다음 Groups 를 선택합니다.

3. 복제 또는 장애 조치 그룹의 이름을 선택합니다.

그러면 그룹에 대한 다음 정보를 검토할 수 있습니다.

• 그룹 유형(복제 그룹 또는 장애 조치 그룹).

• 복제 일정(예: 10분마다).

• 각 새로 고침 작업의 기간.

• 복제본 지연 시간(마지막 새로 고침 작업 이후의 시간).

• 예약된 다음 새로 고침 작업의 날짜 및 시간.

상태와 기간을 기준으로 페이지의 데이터를 필터링할 수 있습니다.

• 새로 고침 작업 상태를 기준으로 결과를 필터링하려면 Status 를 선택하십시오.

  • Refresh Cancelled

  • Refresh Failed

  • Refresh In Progress

  • Refresh Successful

• 다음에 대한 새로 고침 작업 세부 정보를 표시하려면 Duration 을 선택하십시오.

  • Last hour

  • Last 24 hours

  • Last 7 days

  • All

  All 을 선택하면 지난 14일 동안의 새로 고침 작업이 표시됩니다.

각 새로 고침 작업의 세부 정보에는 다음 열이 포함됩니다.

열	설명
Query ID	새로 고침 작업의 ID를 쿼리합니다.
Status	새로 고침 작업의 상태를 표시합니다. 유효한 값으로 Successful, Failed, In Progress 가 포함됩니다.
Ended	새로 고침 작업이 종료된 날짜와 시간입니다.
Duration	새로 고침 작업 완료에 걸린 시간입니다. 기간은 복제 단계 에 따라 분류되고 색상으로 구분됩니다. 색상으로 구분된 각 세그먼트의 너비는 해당 단계에서 소요된 시간의 해당 부분을 나타냅니다. 아래 이미지는 참고용일 뿐입니다. 새로 고침 작업을 선택 하여 추가 세부 정보를 볼 때 이 그래프가 제공됩니다.
Transferred	복제된 바이트의 수입니다.
Objects	복제된 오브젝트의 수입니다.

행을 선택하면 다음을 포함하여 특정 새로 고침 작업에 대한 추가 세부 정보를 확인할 수 있습니다.

• 각 복제 단계의 기간.

• (실패한 새로 고침 작업에 대한) 오류 메시지.

• 유형 및 번호별로 복제된 데이터베이스 오브젝트의 목록.

• 복제된 데이터베이스 수와 데이터베이스 이름.

SELECT PHASE_NAME, START_TIME, END_TIME, TOTAL_BYTES, OBJECT_COUNT
  FROM TABLE(information_schema.replication_group_refresh_history('myfg'))
  WHERE START_TIME >= current_date - interval '7 days';

SELECT REPLICATION_GROUP_NAME, PHASE_NAME, START_TIME, END_TIME, TOTAL_BYTES, OBJECT_COUNT
  FROM snowflake.account_usage.replication_group_refresh_history
  WHERE START_TIME >= date_trunc('month', current_date());

복제 비용 모니터링하기¶

복제에 대한 크레딧 사용을 모니터링하려면 다음 중 하나를 쿼리하십시오.

• (Account Usage 의) REPLICATION_GROUP_USAGE_HISTORY 뷰.

• REPLICATION_GROUP_USAGE_HISTORY 테이블 함수(Snowflake Information Schema).

SELECT start_time, end_time, replication_group_name, credits_used, bytes_transferred
  FROM table(information_schema.replication_group_usage_history(date_range_start=>dateadd('day', -7, current_date())));

SELECT start_time, 
  end_time, 
  replication_group_name, 
  credits_used, 
  bytes_transferred
FROM snowflake.account_usage.replication_group_usage_history
WHERE start_time >= DATE_TRUNC('month', CURRENT_DATE());

데이터베이스의 복제 비용 모니터링하기¶

복제 또는 장애 조치 그룹에 포함된 개별 데이터베이스의 복제 비용은 데이터베이스에 대해 복사된 바이트 수를 검색하고 이를 사용된 크레딧과 연결하여 계산할 수 있습니다.

예¶

아래 예에서 데이터베이스 mydb 는 장애 조치 그룹 myfg 에 포함되어 있습니다. 데이터베이스 mydb 에는 테이블 mytable 이 있습니다.

Snowsight를 사용하여 복제 또는 장애 조치 그룹 수정하기¶

그룹 이름을 편집하려면 대상 계정에 로그인한 상태여야 합니다. 로그인한 상태가 아니라면 Status 열에 새로 고침 상태 대신 로그인 메시지가 표시됩니다.

원본 계정과 대상 계정 모두 동일한 연결 유형(공용 인터넷)을 사용해야 합니다. 그렇지 않으면 대상 계정에 로그인할 수 없습니다.

1. Snowsight 에 로그인하고 Admin » Accounts 로 이동합니다.

2. Replication 을 선택한 다음 Groups 를 선택합니다.

3. 편집하려는 복제 또는 장애 조치 그룹을 찾습니다. 행의 마지막 열에서 More 메뉴(…)를 선택합니다.

4. Edit 를 선택합니다.

5. 그룹 이름을 변경하려면 다음 요구 사항을 충족하는 Group Name 상자에 새 이름을 입력하십시오.

   • 알파벳 문자로 시작해야 하며 식별자 문자열을 큰따옴표(예: “My object”)로 묶지 않는 한 공백이나 특수 문자를 포함할 수 없습니다. 큰따옴표로 묶인 식별자도 대/소문자를 구분합니다.

     자세한 내용은 식별자 요구 사항 섹션을 참조하십시오.

   • 계정의 장애 조치 그룹 및 복제 그룹에 대한 이름은 고유해야 합니다.

6. Select Objects 를 선택하여 공유 및 계정 오브젝트를 추가하거나 제거합니다.

   참고

   계정 오브젝트는 하나의 복제 또는 장애 조치 그룹에만 추가할 수 있습니다. 계정 오브젝트가 포함된 복제 또는 장애 조치 그룹이 계정에 이미 존재하는 경우 해당 오브젝트를 선택할 수 없습니다.

7. Select Databases 를 선택하여 데이터베이스 오브젝트를 추가하거나 제거합니다.

8. Replication Frequency 를 선택하여 그룹의 복제 일정을 변경합니다.

9. Save Changes 를 선택하여 그룹을 업데이트합니다.

   변경 사항을 그룹에 저장하지 못한 경우 일반적인 오류와 해결 방법은 Snowsight를 사용한 복제 그룹 생성 및 편집 관련 문제 해결하기 섹션을 참조하십시오.

SQL을 사용하여 복제 또는 장애 조치 그룹 수정하기¶

ALTER REPLICATION GROUP 또는 ALTER FAILOVER GROUP 명령을 사용하여 복제 또는 장애 조치 그룹 속성을 수정할 수 있습니다.

SQL을 사용하여 기본 복제 또는 장애 조치 그룹 삭제하기¶

그룹의 모든 복제본(즉, 보조 복제 또는 장애 조치 그룹)이 삭제된 후에만 기본 복제 또는 장애 조치 그룹을 삭제할 수 있습니다. 또는 기본 장애 조치 그룹의 역할을 하도록 보조 장애 조치 그룹을 승격한 다음, 이전의 기본 장애 조치 그룹을 삭제할 수 있습니다.

그룹 소유자만 그룹을 삭제할 수 있음에 유의하십시오.

Snowsight를 사용하여 복제 또는 장애 조치 그룹 삭제하기¶

기본 복제 또는 장애 조치 그룹과 연결된 모든 보조 그룹을 삭제할 수 있습니다.

1. Snowsight 에 로그인하고 Admin » Accounts 로 이동합니다.

2. Replication 을 선택한 다음 Groups 를 선택합니다.

3. 삭제하려는 복제 또는 장애 조치 그룹을 찾습니다. 행의 마지막 열에서 More 메뉴(…)를 선택합니다.

4. Drop 를 선택한 다음 Drop Group 을 선택합니다.

그룹에 데이터베이스를 추가할 수 없음¶

Database '<database_name>' is already configured to replicate to
account '<account_name>' by replication group '<group_name>'.

Cannot directly add previously replicated object '<database_name>' to a
replication group. Please use the provided system functions to convert
this object first.

그룹에 공유를 추가할 수 없음¶

Share '<share_name>' is already configured to replicate to
account '<account_name>' by replication group '<group_name>'.