Azure SQL Managed Instance의 Log Replay Service 개요

적용 대상: Azure SQL Managed Instance

이 문서에서는 데이터베이스를 SQL Server에서 Azure SQL Managed Instance로 마이그레이션하는 데 사용할 수 있는 LRS(Log Replay Service)에 대한 개요를 제공합니다. LRS는 Azure SQL Managed Instance에서 사용할 수 있으며 SQL Server 로그 전달 기술을 기준으로 하여 무료 클라우드 서비스입니다.

LRS는 표준 SQL Server 백업 파일을 복원하므로, 온-프레미스 또는 모든 클라우드에서 호스팅되는 SQL Server에서 Azure SQL Managed Instance로 마이그레이션하는 데 사용할 수 있습니다.

LRS로 마이그레이션을 시작하려면 로그 재생 서비스를 사용하여 데이터베이스 마이그레이션을 검토하세요.

Important

데이터베이스를 중요 비즈니스용 서비스 계층으로 마이그레이션하기 전에 범용 서비스 계층에 적용되지 않는 이러한 제한 사항을 고려합니다.

로그 재생 서비스를 사용하는 경우

Azure Database Migration Service, Azure Data Studio용 Azure SQL 마이그레이션 확장 및 LRS는 모두 동일한 기본 마이그레이션 기술 및 API를 사용합니다. LRS는 또한 온-프레미스 SQL Server 인스턴스와 SQL Managed Instance 배포 간에 복잡한 사용자 지정 마이그레이션 및 하이브리드 아키텍처를 추가로 지원할 수 있습니다.

마이그레이션에 Azure Database Migration Service 또는 Azure SQL 확장을 사용할 수 없는 경우 PowerShell, Azure CLI cmdlet 또는 API에서 직접 LRS를 사용하여 데이터베이스 마이그레이션을 수동으로 빌드하고 SQL Managed Instance에 오케스트레이션할 수 있습니다.

다음과 같은 경우 LRS 사용을 고려합니다.

• 데이터베이스 마이그레이션 프로젝트에 대한 추가 제어가 필요합니다.
• 마이그레이션 중단 시 가동 중지 시간이 거의 허용되지 않습니다.
• Database Migration Service 실행 파일을 사용자 환경에 설치할 수 없습니다.
• Database Migration Service 실행 파일에는 데이터베이스 백업에 대한 파일 액세스 권한이 없습니다.
• Azure SQL 마이그레이션 확장을 사용자 환경에 설치할 수 없거나 데이터베이스 백업에 액세스할 수 없습니다.
• 사용할 수 있는 호스트 운영 체제에 액세스할 수 없거나 관리자 권한이 없습니다.
• 사용자 환경에서 Azure로 네트워크 포트를 열 수 없습니다.
• 환경에 네트워크 대역폭 제한 또는 프록시 차단 문제가 있습니다.
• 백업은 TO URL 옵션을 통해 Azure Blob Storage 계정에 직접 저장됩니다.
• 차등 백업을 사용해야 합니다.

LRS는 표준 SQL Server 백업 파일을 복원하는 방식으로 작동하므로 모든 원본에서 마이그레이션을 지원해야 합니다. 다음 원본이 테스트되었습니다.

• SQL Server 온-프레미스/박스
• Virtual Machines의 SQL Server
• Amazon EC2(Elastic Compute Cloud)
• SQL Server용 Amazon RDS(관계형 데이터베이스 서비스)
• Google Compute Engine
• SQL Server용 클라우드 SQL - GCP(Google Cloud Platform)
• SQL Server용 Alibaba Cloud RDS

목록에 없는 원본에서 마이그레이션하는 동안 예기치 않은 문제가 발생하는 경우 지원 티켓을 열어 도움을 요청하세요.

참고 항목

• Azure Data Studio용 Azure SQL 마이그레이션 확장을 사용하여 SQL Server에서 Azure SQL Managed Instance로 데이터베이스 마이그레이션을 자동화하는 것이 좋습니다. Azure Data Studio용 Azure SQL 마이그레이션 확장에서 시나리오를 완전히 지원하지 않는 경우 LRS를 사용하여 마이그레이션을 오케스트레이션하는 것이 좋습니다.
• LRS는 관리형 인스턴스에서 차등 백업을 복원하는 유일한 방법입니다. 관리형 인스턴스에서 차등 백업을 수동으로 복원하거나 T-SQL을 사용하여 NORECOVERY 모드를 수동으로 설정할 수 없습니다.

LRS 작동 방식

LRS를 사용하여 데이터베이스를 클라우드로 마이그레이션하는 사용자 지정 솔루션을 빌드하려면 이 섹션의 뒷부분에 나오는 다이어그램과 표에 표시된 대로 몇 가지 오케스트레이션 단계가 필요합니다.

마이그레이션은 SQL Server에서 데이터베이스 백업을 만들고 백업 파일을 Azure Blob Storage 계정에 복사하는 것으로 구성됩니다. 전체, 로그 및 차등 백업이 지원됩니다. 그런 후 LRS 클라우드 서비스를 사용하여 백업 파일을 Azure Blob Storage에서 SQL Managed Instance로 복원합니다. Blob Storage 계정은 SQL Server와 SQL Managed Instance 간의 백업 파일에 대한 중간 스토리지로 사용됩니다.

LRS는 전체 백업이 복원된 후 추가된 새로운 차등 또는 로그 백업에 대해 Blob Storage 계정을 모니터링합니다. 그런 다음 LRS는 이러한 새 파일을 자동으로 복원합니다. 서비스를 사용하여 SQL Managed Instance로 복원되는 백업 파일의 진행률을 모니터링하고, 필요한 경우 프로세스를 중지할 수 있습니다.

LRS에는 백업 파일에 대한 특정 명명 규칙이 필요하지 않습니다. Azure Blob Storage 계정에 배치된 모든 파일을 스캔하고 파일 헤더만 읽어 백업 체인을 생성합니다. 데이터베이스는 마이그레이션 프로세스 동안 복원 중 상태가 됩니다. 데이터베이스는 NORECOVERY 모드로 복원되므로 마이그레이션 프로세스가 완료될 때까지 읽기 또는 쓰기 워크로드에 사용할 수 없습니다.

여러 데이터베이스를 마이그레이션하는 경우 다음을 수행해야 합니다.

• 각 데이터베이스에 대한 백업 파일을 플랫 파일 구조의 Blob Storage 계정에 있는 별도의 폴더에 배치합니다. 예를 들어 blobcontainer/database1/files, blobcontainer/database2/files 등의 별도의 데이터베이스 폴더를 사용합니다.
• 중첩 폴더 구조는 지원되지 않으므로 중첩 폴더를 데이터베이스 폴더 내에 사용하지 않습니다. 예를 들어 blobcontainer/database1/subfolder/files와 같은 하위 폴더를 사용하지 마세요.
• 각 데이터베이스에 대해 개별적으로 LRS를 시작합니다.
• Blob Storage 계정에서 별도의 데이터베이스 폴더에 대해 다른 URI 경로를 지정합니다.

백업에 CHECKSUM을 사용하도록 설정하는 것은 필요하지 않지만 권장됩니다. SQL Managed Instance는 CHECKSUM을 사용하도록 설정하지 않고 복원된 백업에 대해 무결성 검사를 수행하기 때문에 CHECKSUM을 사용하지 않고 데이터베이스를 복원하는 데 시간이 더 오래 걸립니다.

자세한 내용은 Log Replay Service를 사용하여 SQL Server에서 SQL Managed Instance로 데이터베이스 마이그레이션을 참조하세요.

주의

CHECKSUM을 사용하면서 SQL Server에서 백업을 수행하는 것이 좋습니다. 이 옵션을 사용하지 않으면 Azure로 손상된 데이터베이스를 복원할 위험이 있습니다.

자동 완성 및 연속 모드 마이그레이션

자동 완성 또는 연속 모드로 LRS를 시작할 수 있습니다.

전체 백업 체인이 미리 생성되어 있고 마이그레이션이 시작된 후 더 이상 파일을 추가할 계획이 없는 경우 자동 완성 모드를 사용합니다. 이 마이그레이션 모드는 데이터 수집이 필요하지 않은 수동 워크로드에 권장됩니다. 모든 백업 파일을 Blob Storage 계정에 업로드하고 자동 완성 모드 마이그레이션을 시작합니다. 지정된 백업 파일의 마지막 부분이 복원되면 마이그레이션이 자동으로 완료됩니다. 마이그레이션된 데이터베이스는 SQL Managed Instance에서 읽기/쓰기 액세스에 사용할 수 있습니다.

마이그레이션이 진행되는 동안 새 백업 파일을 계속 추가하려면 연속 모드를 사용합니다. 데이터 캐치업이 필요한 활성 워크로드에는 이 모드를 사용하는 것이 좋습니다. 현재 사용 가능한 백업 체인을 Blob Storage 계정에 업로드하고, 연속 모드에서 마이그레이션을 시작하고, 필요에 따라 워크로드에서 새 백업 파일을 계속 추가합니다. 시스템은 정기적으로 Azure Blob Storage 폴더를 검사하고, 찾은 새 로그 또는 차등 백업 파일을 복원합니다.

단독형 마이그레이션 준비가 되면 SQL Server 인스턴스에서 워크로드를 중지하고 마지막 백업 파일을 생성한 다음, 업로드합니다. 마지막 로그 테일 백업이 SQL Managed Instance에서 복원된 것으로 표시되는지 확인하여 마지막 백업 파일이 복원되었는지 확인합니다. 그런 다음 수동 컷오버를 시작합니다. 마지막 컷오버 단계를 수행하면 데이터베이스가 온라인 상태가 되고 SQL Managed Instance에서 읽기/쓰기 액세스에 사용할 수 있습니다.

자동 완성을 통해 자동으로 또는 중단을 통해 LRS가 수동으로 중지되면 SQL Managed Instance에서 온라인 상태가 된 데이터베이스에 대한 복원 프로세스를 계속할 수 없습니다. 예를 들어 마이그레이션이 완료된 후에는 온라인 데이터베이스에 대한 추가 차등 백업을 더 이상 복원할 수 없습니다. 마이그레이션이 완료된 후 더 많은 백업 파일을 복원하려면 관리형 인스턴스에서 데이터베이스를 삭제하고 마이그레이션을 처음부터 다시 시작해야 합니다.

마이그레이션 워크플로

일반적인 마이그레이션 워크플로는 아래 이미지에 표시되며 단계는 표에 설명되어 있습니다.

모든 백업 체인 파일을 미리 사용할 수 있는 경우에만 자동 완성 모드를 사용해야 합니다. 이 모드는 데이터 캐치업이 필요하지 않은 수동 워크로드에 권장됩니다.

사전에 전체 백업 체인이 없는 경우와 마이그레이션이 진행된 후에 새 백업 파일을 추가하려는 경우 연속 모드 마이그레이션을 사용합니다. 이 모드는 데이터 캐치업이 필요한 활성 워크로드에 권장됩니다.

작업	세부 정보
1. SQL Server 인스턴스에서 Blob Storage 계정으로 데이터베이스 백업을 복사합니다.	AzCopy 또는 Azure Storage Explorer를 사용하여 SQL Server 인스턴스에서 Blob Storage 컨테이너로 전체, 차등 및 로그 백업을 복사합니다. 임의의 파일 이름을 사용합니다. LRS에는 특정 파일 명명 규칙이 필요하지 않습니다. 여러 데이터베이스를 마이그레이션할 때 각 데이터베이스에 대해 별도의 폴더를 사용합니다.
2. 클라우드에서 LRS 시작.	PowerShell(start-azsqlinstancedatabaselogreplay) 또는 Azure CLI(az_sql_midb_log_replay_start cmdlet)를 사용하여 서비스를 시작할 수 있습니다. 자동 완성 모드 또는 연속 마이그레이션 모드 중에서 선택합니다. Blob Storage 계정의 백업 폴더를 가리키는 각 데이터베이스에 대해 개별적으로 LRS를 시작합니다. 서비스가 시작된 후에는 Blob Storage 컨테이너에서 백업을 가져오고 SQL Managed Instance로의 복원을 시작합니다. LRS를 자동 완성 모드에서 시작하면 지정된 마지막 백업 파일까지 모든 백업을 복원합니다. 모든 백업 파일을 미리 업로드해야 하며 마이그레이션이 진행되는 동안에는 새 백업 파일을 추가할 수 없습니다. 이 모드는 데이터 캐치업이 필요하지 않은 수동 워크로드에 권장됩니다. LRS를 연속 모드에서 시작하면 처음에 업로드된 모든 백업을 복원한 다음, 폴더에 업로드된 새 파일을 감시합니다. 이 서비스는 수동으로 중지될 때까지 LSN(로그 시퀀스 번호) 체인을 기반으로 로그를 지속적으로 적용합니다. 이 모드는 데이터 캐치업이 필요한 활성 워크로드에 권장됩니다.
2.1. 작업 진행 상황 모니터링.	PowerShell(get-azsqlinstancedatabaselogreplay) 또는 Azure CLI(az_sql_midb_log_replay_show cmdlet)를 사용하여 진행 중인 복원 작업의 진행률을 모니터링할 수 있습니다. 실패한 요청에 대한 추가적인 세부 정보를 추적하려면 PowerShell 명령 Get-AzSqlInstanceOperation이나 Azure CLI 명령 az sql mi op show를 사용합니다.
2.2. 필요한 경우 작업 중지(선택 사항).	마이그레이션 프로세스를 중지해야 하는 경우 PowerShell(stop-azsqlinstancedatabaselogreplay) 또는 Azure CLI(az_sql_midb_log_replay_stop)를 사용합니다. 작업을 중지하면 SQL Managed Instance에 복원하는 데이터베이스가 삭제됩니다. 작업을 중지한 후에는 데이터베이스에 대해 LRS를 다시 시작할 수 없습니다. 마이그레이션 프로세스를 처음부터 다시 시작해야 합니다.
3. 준비가 되면 클라우드 중단.	LRS를 자동 완성 모드에서 시작한 경우 지정된 마지막 백업 파일이 복원되면 마이그레이션이 자동으로 완료됩니다. LRS가 연속 모드에서 시작된 경우 애플리케이션 및 워크로드를 중지합니다. 마지막 로그 테일 백업을 가져오고 Azure Blob Storage 배포에 업로드합니다. 관리형 인스턴스에서 마지막 로그 테일 백업이 복원되었는지 확인합니다. PowerShell(complete-azsqlinstancedatabaselogreplay) 또는 Azure CLI az_sql_midb_log_replay_complete를 사용하여 LRS complete 작업을 시작하여 중단을 완료합니다. 이 작업은 LRS를 중지하고 SQL Managed Instance의 읽기/쓰기 워크로드를 위해 데이터베이스를 온라인으로 전환합니다. 애플리케이션 연결 문자열 방향을 SQL Server 인스턴스에서 SQL Managed Instance로 다시 지정합니다. 애플리케이션에서 연결 문자열을 수동으로 변경하거나 자동으로(예: 애플리케이션이 속성 또는 데이터베이스에서 연결 문자열을 읽을 수 있는 경우) 변경하여 이 단계를 직접 오케스트레이션해야 합니다.

Important

중단 후 중요 비즈니스용 서비스 계층이 있는 SQL Managed Instance는 가용성 그룹에 대해 세 개의 보조 복제본을 시드해야 하므로 범용보다 훨씬 더 오래 걸릴 수 있습니다. 이 작업 기간은 데이터 크기에 달렸습니다. 자세한 내용은 관리 작업 기간을 참조하세요.

대규모 데이터베이스 마이그레이션

테라바이트 크기의 대규모 데이터베이스를 마이그레이션하는 경우 다음을 고려하세요.

• 단일 LRS 작업은 최대 30일 동안 실행할 수 있습니다. 이 기간이 만료되면 작업이 자동으로 취소됩니다.
• 장기 실행 작업의 경우 시스템 업데이트는 마이그레이션 작업을 중단하고 연장합니다. 유지 관리 기간을 사용하여 계획된 시스템 업데이트를 예약하는 것이 좋습니다. 예약된 유지 관리 기간을 중심으로 마이그레이션을 계획합니다.
• 시스템 업데이트로 인해 중단된 마이그레이션 작업은 범용 관리되는 인스턴스에 대해 자동으로 일시 중단되고 다시 시작되며 중요 비즈니스용 관리되는 인스턴스에 대해 다시 시작됩니다. 이러한 업데이트는 마이그레이션 기간에 영향을 줍니다.
• 인프라에 충분한 네트워크 대역폭이 있는 경우 Blob Storage 계정으로의 SQL Server 백업 파일 업로드 속도를 높이려면 여러 스레드에서 병렬 처리를 사용하는 것이 좋습니다.

마이그레이션 시작

LRS를 시작하여 마이그레이션을 시작합니다. 자동 완성 또는 연속 모드로 서비스를 시작할 수 있습니다. 자세한 내용은 LRS를 사용하여 마이그레이션을 검토하세요.

• 자동 완성 모드. 자동 완성 모드를 사용하는 경우 지정된 백업 파일의 마지막 부분이 복원되면 마이그레이션이 자동으로 완료됩니다. 이 옵션:

  • 전체 백업 체인을 미리 사용할 수 있어야 하며 Azure Blob Storage 계정에 업로드해야 합니다.
  • 마이그레이션 진행 중에는 새 백업 파일을 추가할 수 없습니다.
  • 마지막 백업 파일의 파일 이름을 지정하려면 start 명령이 필요합니다.

  데이터 캐치업이 필요하지 않은 수동 워크로드에 자동 완성 모드를 사용하는 것이 좋습니다.

• 연속 모드. 연속 모드를 사용하는 경우 서비스는 Azure Blob Storage 폴더를 지속적으로 검색하고 마이그레이션이 진행되는 동안 계속 추가되는 새 백업 파일을 복원합니다.

  수동 중단이 요청된 후에만 마이그레이션이 완료됩니다.

  사전에 전체 백업 체인이 없는 경우와 마이그레이션이 진행된 후에 새 백업 파일을 추가하려는 경우 연속 모드 마이그레이션을 사용해야 합니다.

  데이터 캐치업이 필요한 활성 워크로드에 연속 모드를 사용하는 것이 좋습니다.

최대 30일 이내에 단일 LRS 마이그레이션 작업을 완료하도록 계획합니다. 이 기간이 만료되면 LRS 작업이 자동으로 취소됩니다.

참고 항목

여러 데이터베이스를 마이그레이션하는 경우 각 데이터베이스는 자체 폴더에 있어야 합니다. Azure Blob Storage 컨테이너 및 개별 데이터베이스 폴더의 전체 URI 경로를 가리키는 각 데이터베이스에 대해 별도로 LRS를 시작해야 합니다. 데이터베이스 폴더 내의 중첩 폴더는 지원되지 않습니다.

LRS의 제한 사항

자세한 내용은 LRS를 사용할 때 제한 사항을 검토 합니다 .

다음 단계

• 자세한 내용은 Log Replay Service를 사용하여 SQL Server에서 SQL Managed Instance로 데이터베이스 마이그레이션을 참조하세요.

• 링크 기능을 사용하여 SQL Managed Instance로 데이터베이스 마이그레이션에 대한 자세히 알아보세요.

• SQL Server에서 SQL Managed Instance로 데이터베이스 마이그레이션에 대해 자세히 알아보세요.

• SQL Server와 SQL Managed Instance의 차이점에 대해 자세히 알아봅니다.

• Azure로 마이그레이션된 워크로드의 비용 및 크기 조정 모범 사례에 대해 자세히 알아봅니다.