리소스를 새 지역인 Azure SQL 데이터베이스로 이동하다

  • 아티클

적용 대상:Azure SQL Database

이 문서에서는 데이터베이스 또는 탄력적 풀을 새 지역으로 이동하는 방법에 대한 일반적인 워크플로를 설명합니다.

참고 항목

  • 데이터베이스 및 탄력적 풀을 다른 Azure 지역으로 이동하려면 권장되는 Azure Resource Mover를 사용할 수도 있습니다.
  • 이 문서는 Azure 공용 클라우드 내에서 또는 동일한 소버린 클라우드 내에서의 마이그레이션에 적용됩니다.

개요

기존 데이터베이스 또는 풀을 한 지역에서 다른 지역으로 이동하려는 다양한 시나리오가 있습니다. 예를 들어, 비즈니스를 새로운 지역으로 확장하고 있으며 새 고객층에 맞게 최적화하려고 합니다. 또는 규정 준수를 위해 작업을 다른 지역으로 이동해야 합니다. 또는 Azure는 더 나은 근접성을 제공하고 고객 환경을 개선하는 새로운 지역을 출시했습니다.

리소스를 다른 지역으로 이동하는 일반적인 워크플로는 다음 단계로 구성됩니다.

  1. 이동을 위한 사전 요구 사항을 확인합니다.
  2. 범위에서 리소스를 이동할 준비를 합니다.
  3. 준비 프로세스를 모니터링합니다.
  4. 이동 프로세스를 테스트합니다.
  5. 실제 이동을 시작합니다.

데이터베이스를 이동하기 위한 필수 구성 요소 확인

  1. 각 원본 서버에 대한 대상 서버를 만듭니다.
  2. PowerShell을 사용하여 적절한 예외로 방화벽을 구성합니다.
  3. 올바른 로그인을 사용하여 모든 서버를 구성합니다. 구독 관리자 또는 SQL Server 관리자가 아닌 경우에는 관리자와 협력하여 필요한 권한을 할당받습니다. 자세한 내용은 재해 복구 후 Azure SQL Database 보안을 관리하는 방법을 참조하세요.
  4. 데이터베이스가 TDE(투명한 데이터 암호화)로 암호화되고 Azure Key Vault에서 BYOK(Bring Your Own Key) 또는 CMK(고객 관리형 키)를 사용하는 경우, 대상 지역에 올바른 암호화 자료를 프로비저닝해야 합니다.
    • 이 작업을 수행하는 가장 간단한 방법은 기존 키 자격 증명 모음의 암호화 키(원본 서버에서 TDE 보호기로 사용됨)를 대상 서버에 추가한 다음, 한 지역의 서버가 이제 다른 지역의 키 자격 증명으로 연결될 수 있으므로 대상 서버에서 키를 TDE 보호기로 설정하는 것입니다.
    • 대상 서버가 이전 암호화 키(데이터베이스 백업 복원에 필요)에 액세스하도록 보장하는 가장 좋은 방법은 원본 서버에서 Get-AzSqlServerKeyVaultKey cmdlet을 실행하여 사용 가능한 키 목록을 반환하고 해당 키를 대상 서버에 추가하는 것입니다.
    • 대상 서버에서 고객 관리형 TDE를 구성하는 방법에 대한 자세한 내용과 모범 사례는 Azure Key Vault에서 고객 관리형 키를 사용한 Azure SQL 투명한 데이터 암호화를 참조하세요.
    • 키 자격 증명 모음을 새 지역으로 이동하려면 지역 간에 Azure 키 자격 증명 모음 이동을 참조하세요.
  5. 데이터베이스 수준 감사를 사용하도록 설정된 경우 이를 사용하지 않고 대신 서버 수준 감사를 사용하도록 설정합니다. 장애 조치(failover) 후 데이터베이스 수준 감사에는 이동 후 원하지 않거나 가능하지 않은 지역 간 트래픽이 필요합니다.
  6. 서버 수준 감사의 경우 다음을 확인합니다.
    • 기존 감사 로그가 포함된 스토리지 컨테이너, Log Analytics 또는 이벤트 허브가 대상 지역으로 이동됩니다.
    • 감사는 대상 서버에서 구성됩니다. 자세한 내용은 SQL Database 감사 시작을 참조하세요.
  7. 서버에 LTR(장기 보존 정책)이 있는 경우 기존 LTR 백업이 현재 서버와 연결된 상태로 유지됩니다. 대상 서버가 다르기 때문에 서버가 삭제되더라도 원본 서버를 사용하는 것으로 원본 지역의 이전 LTR 백업에 액세스할 수 있습니다.

참고 항목

소버린 지역과 공용 지역 간에 기존 LTR 백업이 있는 데이터베이스를 마이그레이션하려면 LTR 백업을 대상 서버로 이동해야 하므로 현재는 지원되지 않습니다.

리소스 준비

  1. 원본 서버와 대상 서버 간에 장애 조치(failover) 그룹을 만듭니다.
  2. 장애 조치(failover) 그룹으로 이동하려는 데이터베이스를 추가합니다. 추가된 모든 데이터베이스의 복제는 자동으로 시작됩니다. 자세한 내용은 SQL Database에서 장애 조치(failover) 그룹 사용을 참조하세요.

준비 프로세스 모니터링

정기적으로 AzSqlDatabaseFailoverGroup을 호출하여 원본에서 대상 서버로의 데이터베이스의 복제를 모니터링할 수 있습니다. Get-AzSqlDatabaseFailoverGroup의 출력 개체에는 ReplicationState에 대한 속성이 포함되어 있습니다.

  • ReplicationState = 2(CATCH_UP)는 데이터베이스가 동기화되었으며 안전하게 장애 조치할 수 있음을 나타냅니다.
  • ReplicationState = 0(SEEDING)은 데이터베이스가 아직 시드되지 않아 장애 조치(failover) 시도가 실패했음을 나타냅니다.

동기화 테스트

ReplicationState가 2인 경우, 보조 엔드포인트 <fog-name>.secondary.database.windows.net을 사용하여 각 데이터베이스 또는 데이터베이스의 하위 집합에 연결하고 데이터베이스에 대한 쿼리를 수행하여 연결, 적절한 보안 구성 및 데이터 복제를 보장합니다.

이동 시작

  1. 보조 엔드포인트 <fog-name>.secondary.database.windows.net을 사용하여 대상 서버에 연결합니다.
  2. Switch-AzSqlDatabaseFailoverGroup을 사용하여 보조 서버를 전체 동기화를 사용하는 기본으로 전환합니다. 이 작업은 성공적으로 수행되거나 롤백됩니다.
  3. DNS CNAME 진입점이 대상 지역 IP 주소를 가리키는지 확인하기 위해 nslook up <fog-name>.secondary.database.windows.net을 사용하여 명령이 성공적으로 완료되었는지 확인합니다. 스위치 명령이 실패하면 CNAME은 업데이트되지 않습니다.

원본 데이터베이스 제거

이동이 완료되면 불필요한 요금을 방지하기 위해 원본 지역의 리소스를 제거합니다.

  1. Remove-AzSqlDatabaseFailoverGroup을 사용하여 장애 조치(failover) 그룹을 삭제합니다.
  2. 원본 서버의 각 데이터베이스에 대해 Remove-AzSqlDatabase를 사용하여 각 원본 데이터베이스를 삭제합니다. 그러면 지역 복제 링크가 자동으로 종료됩니다.
  3. Remove-AzSqlServer를 사용하여 원본 서버를 삭제합니다.
  4. 키 자격 증명 모음, 감사 스토리지 컨테이너, 이벤트 허브, Microsoft Entra 테넌트 및 기타 종속 리소스를 제거하여 요금 청구를 중지합니다.

풀을 이동하기 위한 필수 구성 요소 확인

  1. 각 원본 서버에 대한 대상 서버를 만듭니다.
  2. PowerShell을 사용하여 적절한 예외로 방화벽을 구성합니다.
  3. 올바른 로그인을 사용하여 서버를 구성합니다. 구독 관리자 또는 서버 관리자가 아닌 경우에는 관리자와 협력하여 필요한 권한을 할당받습니다. 자세한 내용은 재해 복구 후 Azure SQL Database 보안을 관리하는 방법을 참조하세요.
  4. 데이터베이스가 투명한 데이터 암호화로 암호화되고 Azure Key Vault에서 사용자 고유의 암호화 키를 사용하는 경우, 대상 지역에 올바른 암호화 자료를 프로비전해야 합니다.
  5. 각 원본 탄력적 풀에 대한 대상 탄력적 풀을 만들어 동일한 서비스 계층에 동일한 이름과 크기를 가진 풀이 만들어졌는지 확인합니다.
  6. 데이터베이스 수준 감사를 사용하도록 설정된 경우 이를 사용하지 않고 대신 서버 수준 감사를 사용하도록 설정합니다. 장애 조치(failover) 후 데이터베이스 수준 감사에는 이동 후 원하지 않거나 가능하지 않은 지역 간 트래픽이 필요할 수 있습니다.
  7. 서버 수준 감사의 경우 다음을 확인합니다.
    • 기존 감사 로그가 포함된 스토리지 컨테이너, Log Analytics 또는 이벤트 허브가 대상 지역으로 이동됩니다.
    • 감사 구성은 대상 서버에서 구성됩니다. 자세한 내용은 SQL Database 감사를 참조하세요.
  8. 서버에 LTR(장기 보존 정책)이 있는 경우 기존 LTR 백업이 현재 서버와 연결된 상태로 유지됩니다. 대상 서버가 다르기 때문에 서버가 삭제되더라도 원본 서버를 사용하여 원본 지역의 이전 LTR 백업에 액세스할 수 있습니다.

참고 항목

소버린 지역과 공용 지역 간에 기존 LTR 백업이 있는 데이터베이스를 마이그레이션하려면 LTR 백업을 대상 서버로 이동해야 하므로 현재는 지원되지 않습니다.

이동 준비

  1. 원본 서버의 각 탄력적 풀과 대상 서버의 해당하는 탄력적 풀 사이에 별도의 장애 조치(failover) 그룹을 만듭니다.

  2. 풀의 모든 데이터베이스를 장애 조치(failover) 그룹에 추가합니다. 추가된 데이터베이스의 복제는 자동으로 시작됩니다. 자세한 내용은 SQL Database에서 장애 조치(failover) 그룹 사용을 참조하세요.

    참고

    여러 탄력적 풀을 포함하는 장애 조치(failover) 그룹을 만들 수 있지만 각 풀에 대해 별도의 장애 조치(failover) 그룹을 만드는 것이 좋습니다. 이동해야 하는 여러 탄력적 풀에 대량의 데이터베이스가 있는 경우 준비 단계를 병렬로 실행한 다음, 이동 단계를 병렬로 시작할 수 있습니다. 이 프로세스는 동일한 장애 조치(failover) 그룹에 여러 개의 탄력적 풀을 사용하는 것에 비해 확장성이 향상되고 시간이 적게 소요됩니다.

준비 프로세스 모니터링

정기적으로 AzSqlDatabaseFailoverGroup을 호출하여 원본에서 대상으로 데이터베이스의 복제를 모니터링할 수 있습니다. Get-AzSqlDatabaseFailoverGroup의 출력 개체에는 ReplicationState에 대한 속성이 포함되어 있습니다.

  • ReplicationState = 2(CATCH_UP)는 데이터베이스가 동기화되었으며 안전하게 장애 조치할 수 있음을 나타냅니다.
  • ReplicationState = 0(SEEDING)은 데이터베이스가 아직 시드되지 않아 장애 조치(failover) 시도가 실패했음을 나타냅니다.

동기화 테스트

ReplicationState가 2인 경우, 보조 엔드포인트 <fog-name>.secondary.database.windows.net을 사용하여 각 데이터베이스 또는 데이터베이스의 하위 집합에 연결하고 데이터베이스에 대한 쿼리를 수행하여 연결, 적절한 보안 구성 및 데이터 복제를 보장합니다.

이동 시작

  1. 보조 엔드포인트 <fog-name>.secondary.database.windows.net을 사용하여 대상 서버에 연결합니다.
  2. Switch-AzSqlDatabaseFailoverGroup을 사용하여 보조 서버를 전체 동기화를 사용하는 기본으로 전환합니다. 이 작업은 성공적으로 수행되거나 또는 롤백됩니다.
  3. DNS CNAME 진입점이 대상 지역 IP 주소를 가리키는지 확인하기 위해 nslook up <fog-name>.secondary.database.windows.net을 사용하여 명령이 성공적으로 완료되었는지 확인합니다. 스위치 명령이 실패하면 CNAME은 업데이트되지 않습니다.

원본 탄력적 풀 제거

이동이 완료되면 불필요한 요금을 방지하기 위해 원본 지역의 리소스를 제거합니다.

  1. Remove-AzSqlDatabaseFailoverGroup을 사용하여 장애 조치(failover) 그룹을 삭제합니다.
  2. Remove-AzSqlElasticPool을 사용하여 원본 서버에서 각 원본 탄력적 풀을 삭제합니다.
  3. Remove-AzSqlServer를 사용하여 원본 서버를 삭제합니다.
  4. 키 자격 증명 모음, 감사 스토리지 컨테이너, 이벤트 허브, Microsoft Entra 테넌트 및 기타 종속 리소스를 제거하여 요금 청구를 중지합니다.

다음 단계

마이그레이션한 후에 데이터베이스를 관리합니다.