로그 재생 서비스를 사용하여 SQL Server에서 데이터베이스 마이그레이션 - Azure SQL Managed Instance
적용 대상: 
Azure SQL Managed Instance
이 문서에서는 LRS(로그 재생 서비스)를 사용하여 데이터베이스를 Azure SQL Managed Instance로 마이그레이션하는 방법을 설명합니다. LRS는 SQL Server 로그 전달 기술을 기반으로 Azure SQL Managed Instance에서 사용할 수 있는 무료 클라우드 서비스입니다.
다음 원본이 지원됩니다.
- Virtual Machines의 SQL Server
- Amazon EC2(Elastic Compute Cloud)
- SQL Server용 Amazon RDS(관계형 데이터베이스 서비스)
- Google Compute Engine
- SQL Server용 Cloud SQL - GCP(Google Cloud Platform)
사전 요구 사항
시작하기 전에 SQL Server 인스턴스와 Azure 모두에 대해 다음 요구 사항을 고려합니다. 마이그레이션에 성공하려면 제한 사항 및 모범 사례 섹션을 주의 깊게 검토하세요.
Important
- 데이터베이스를 중요 비즈니스용 서비스 계층으로 마이그레이션하기 전에 범용 서비스 계층에 적용되지 않는 이러한 제한 사항을 고려합니다.
- 마이그레이션 프로세스가 완료될 때까지 LRS를 통해 복원되는 데이터베이스를 사용할 수 없습니다.
- LRS는 마이그레이션하는 동안 데이터베이스에 대한 읽기 전용 액세스를 지원하지 않습니다.
- 마이그레이션이 완료되면 마이그레이션 프로세스가 최종적으로 완료되므로 추가 차등 백업을 사용하여 다시 시작할 수 없습니다.
데이터베이스를 중요 비즈니스용 서비스 계층으로 마이그레이션하기 전에 범용 서비스 계층에 적용되지 않는 이러한 제한 사항을 고려합니다.
SQL Server
SQL Server에 대한 다음 요구 사항을 충족하는지 확인합니다.
- SQL Server 버전 2008~2022.
- SQL Server 데이터베이스는 전체 복구 모델(필수)을 사용하고 있습니다.
- 데이터베이스의 전체 백업(하나 또는 여러 파일).
- 차등 백업(하나 또는 여러 파일).
- 로그 백업(트랜잭션 로그 파일에 대해 분할되지 않음).
- SQL Server 버전 2008~2016의 경우 로컬에서 백업을 수행하고 Azure Blob Storage 계정에 수동으로 업로드합니다.
- SQL Server 2016 이상에서는 Azure Blob Storage 계정으로 직접 백업할 수 있습니다.
CHECKSUM백업을 사용하도록 설정할 필요는 없지만 손상된 데이터베이스를 의도치 않게 마이그레이션하는 것을 방지하고 복원 작업을 더 빠르게 수행하는 것이 좋습니다.
Azure
Azure에 대한 다음 요구 사항을 충족하는지 확인합니다.
- PowerShell Az.SQL 모듈 버전 4.0.0 이상(설치 또는 Azure Cloud Shell을 통해 액세스).
- Azure CLI 버전 2.42.0 이상(설치).
- 프로비전된 Azure Blob Storage 컨테이너.
- Blob Storage 컨테이너 또는 컨테이너에 액세스할 수 있는 관리 ID에 대해 생성된 권한이 있는
ReadListSAS(공유 액세스 서명) 보안 토큰입니다. LRS보다ReadList많은 권한을 부여하면 LRS가 실패합니다. - 플랫 파일 구조(필수)를 사용하여 스토리지 계정의 별도 폴더 내에 개별 데이터베이스에 대한 백업 파일을 배치합니다. 데이터베이스 폴더 내에 폴더를 중첩하는 것은 지원되지 않습니다.
Azure RBAC 권한
제공된 클라이언트를 통해 LRS를 실행하려면 다음 Azure RBAC(역할 기반 액세스 제어) 역할 중 하나가 필요합니다.
- SQL Managed Instance 기여자 역할
- 다음 권한이 있는 역할:
Microsoft.Sql/managedInstances/databases/*
모범 사례
LRS를 사용하는 경우 다음 모범 사례를 고려합니다.
- Data Migration Assistant를 실행하여 데이터베이스를 SQL Managed Instance에 마이그레이션할 준비가 되었는지 확인합니다.
- 단일 파일을 사용하는 대신 전체 및 차등 백업을 여러 파일로 분할합니다.
- 네트워크 전송 속도를 지원하기 위해 백업 압축을 사용하도록 설정합니다.
- 최신 릴리스 cmdlet을 사용하도록 항상 업데이트되므로 Cloud Shell을 사용하여 PowerShell 또는 CLI 스크립트를 실행합니다.
- 마이그레이션이 지연되거나 중단되지 않도록 시스템 업데이트가 마이그레이션 기간 외부의 특정 날짜 및 시간에 예약되도록 유지 관리 기간을 구성합니다.
- 최대 30일 이내에 단일 LRS 마이그레이션 작업을 완료하도록 계획합니다. 이 시간 프레임이 만료되면 LRS 작업이 자동 취소됩니다.
- 손상된 데이터베이스를 의도치 않게 마이그레이션하는 것을 방지하고 더 빠른 데이터베이스 복원을 위해 백업을 수행할 때 사용하도록 설정합니다
CHECKSUM. SQL Managed Instance는 백업에서 기본 무결성 검사를 수행하지 않고CHECKSUM수행하지만 모든 형태의 손상을 catch하는 것은 보장되지 않습니다. 백업을 사용하는CHECKSUM것은 SQL Managed Instance로 복원된 백업이 손상되지 않도록 하는 유일한 방법입니다. 데이터베이스의 복원 시간을 늘리지 않고CHECKSUM백업에 대한 기본 무결성 검사를 합니다. - 중요 비즈니스용 서비스 계층으로 마이그레이션하는 경우 중단 후 데이터베이스 가용성이 장기간 지연되는 반면 데이터베이스는 보조 복제본에 시드됩니다. 가동 중지 시간이 최소화된 특히 큰 데이터베이스의 경우 먼저 범용 서비스 계층으로 마이그레이션한 다음 중요 비즈니스용 서비스 계층으로 업그레이드하거나 Managed Instance 링크를 사용하여 데이터를 마이그레이션하는 것이 좋습니다.
- 수천 대의 데이터베이스 파일을 업로드하여 복원하면 과도한 마이그레이션 시간과 심지어 오류가 발생할 수 있습니다. 데이터베이스를 더 적은 수의 파일로 통합하여 마이그레이션 프로세스를 가속화하고 성공을 보장합니다.
유지 관리 기간 구성
SQL Managed Instance에 대한 시스템 업데이트는 진행 중인 데이터베이스 마이그레이션보다 우선합니다.
마이그레이션은 서비스 계층에 따라 다르게 영향을 미칩니다.
- 범용 서비스 계층에서 보류 중인 모든 LRS 마이그레이션은 업데이트가 적용된 후에만 일시 중단되고 다시 시작됩니다. 이 시스템 동작은 특히 대규모 데이터베이스의 경우 마이그레이션 시간을 연장할 수 있습니다.
- 중요 비즈니스용 서비스 계층에서는 보류 중인 모든 LRS 마이그레이션이 취소되고 업데이트가 적용된 후 자동으로 다시 시작됩니다. 이 시스템 동작은 특히 대규모 데이터베이스의 경우 마이그레이션 시간을 연장할 수 있습니다.
데이터베이스 마이그레이션에 대한 예측 가능한 시간을 달성하려면 특정 날짜 및 시간에 대한 시스템 업데이트를 예약하도록 유지 관리 기간을 구성하고 지정된 유지 관리 기간 기간 외에 마이그레이션 작업을 실행하고 완료하는 것이 좋습니다. 예를 들어 월요일에 시작하는 마이그레이션의 경우 마이그레이션을 완료하는 데 가장 많은 시간을 허용하도록 일요일에 사용자 지정 유지 관리 기간을 구성합니다.
유지 관리 기간을 구성할 필요는 없지만 큰 데이터베이스에는 매우 권장됩니다.
참고 항목
유지 관리 기간은 계획된 업데이트의 예측 가능성을 제어하지만 un계획된 장애조치s 또는 보안 패치 업데이트가 발생하지 않도록 보장하지는 않습니다. un계획된 장애조치 또는 다른 모든 업데이트보다 우선하는 보안 패치는 여전히 마이그레이션을 중단할 수 있습니다.
여러 데이터베이스 마이그레이션
동일한 Azure Blob Storage 컨테이너를 사용하여 여러 데이터베이스를 마이그레이션하는 경우 다른 데이터베이스에 대한 백업 파일을 컨테이너 내의 별도 폴더에 배치해야 합니다. 단일 데이터베이스에 대한 모든 백업 파일은 데이터베이스 폴더 내의 플랫 파일 구조에 배치되어야 하며 폴더는 중첩될 수 없습니다. 데이터베이스 폴더 내에 폴더를 중첩하는 것은 지원되지 않습니다.
다음은 LRS를 사용하여 여러 데이터베이스를 마이그레이션하는 데 필요한 구조인 Azure Blob Storage 컨테이너 내부의 폴더 구조의 예입니다.
-- Place all backup files for database 1 in a separate "database1" folder in a flat-file structure.
-- Don't use nested folders inside the database1 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database1>/<all-database1-backup-files>
-- Place all backup files for database 2 in a separate "database2" folder in a flat-file structure.
-- Don't use nested folders inside the database2 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database2>/<all-database2-backup-files>
-- Place all backup files for database 3 in a separate "database3" folder in a flat-file structure.
-- Don't use nested folders inside the database3 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database3>/<all-database3-backup-files>
스토리지 계정 만들기
Azure Blob Storage 계정을 SQL Server 인스턴스와 SQL Managed Instance 배포 간의 백업 파일을 위한 중간 스토리지로 사용합니다. 스토리지 계정 내에서 새 스토리지 계정 및 BLOB 컨테이너를 만들려면 다음을 수행합니다.
- 스토리지 계정 만들기
- 스토리지 계정 내에 BLOB 컨테이너를 만듭니다.
방화벽 뒤에서 Azure Storage 구성
방화벽 뒤에서 보호되는 Azure Blob Storage 사용은 지원되지만 추가 구성이 필요합니다. Azure Firewall이 설정된 Azure Storage에 대한 읽기/쓰기 액세스를 사용하도록 설정하려면 MI 서브넷 위임 및 Storage 서비스 엔드포인트를 사용하여 SQL 관리형 인스턴스의 서브넷을 스토리지 계정에 대한 가상 네트워크의 방화벽 규칙에 추가해야 합니다. 스토리지 계정 및 관리형 인스턴스는 동일한 지역 또는 두 개의 쌍을 이루는 지역에 있어야 합니다.
Azure Storage가 방화벽 뒤에 있는 경우 SQL 관리형 인스턴스 오류 로그에 다음 메시지가 표시될 수 있습니다.
Audit: Storage access denied user fault. Creating an email notification:
이렇게 하면 SQL Managed Instance에 대한 감사가 스토리지 계정에 감사 로그를 작성하지 못함을 알리는 이메일이 생성됩니다. 이 오류가 표시되거나 이 이메일을 받는 경우 이 섹션의 단계에 따라 방화벽을 구성합니다.
방화벽을 구성하려면 다음 단계를 수행합니다.
Azure Portal에서 관리형 인스턴스로 이동하고 서브넷을 선택하여 서브넷 페이지를 엽니다.
서브넷 페이지에서 서브넷의 이름을 선택하여 서브넷 구성 페이지를 엽니다.
서브넷 위임의 서비스로 서브넷 위임 드롭다운 메뉴에서 Microsoft.Sql/managedInstances를 선택합니다. 권한이 전파되기까지 1시간 정도 기다린 다음, 서비스 엔드포인트의 서비스 드롭다운에서 Microsoft.Storage를 선택합니다.
다음으로, Azure Portal의 스토리지 계정으로 이동하고 보안 + 네트워킹에서 네트워킹을 선택한 다음, 방화벽 및 가상 네트워크 탭을 선택합니다.
스토리지 계정에 대한 방화벽 및 가상 네트워크 탭에서 +기존 가상 네트워크 추가를 선택하여 네트워크 추가 페이지를 엽니다.
드롭다운 메뉴에서 적절한 구독, 가상 네트워크 및 관리형 인스턴스 서브넷을 선택한 다음, 추가를 선택하여 SQL Managed Instance의 가상 네트워크를 스토리지 계정에 추가합니다.
Blob Storage 계정에 인증
SAS 토큰 또는 관리 ID를 사용하여 Azure Blob Storage 계정에 액세스합니다.
경고
동일한 스토리지 계정에서 SAS 토큰과 관리 ID를 동시에 사용할 수 없습니다. SAS 토큰 또는 관리 ID 중 하나를 사용할 수 있지만 둘 다 사용할 수는 없습니다.
LRS에 대한 Blob Storage SAS 인증 토큰 생성
SAS 토큰을 사용하여 Azure Blob Storage 계정에 액세스합니다.
Azure Blob Storage 계정을 SQL Server 인스턴스와 SQL Managed Instance 배포 간의 백업 파일을 위한 중간 스토리지로 사용할 수 있습니다. 읽기 및 나열 권한만 있는 LRS용 SAS 인증 토큰을 생성합니다. 토큰을 사용하면 LRS가 Blob Storage 계정에 액세스할 수 있으며 백업 파일을 사용하여 관리되는 인스턴스로 복원합니다.
다음 단계에 따라 토큰을 생성합니다.
Azure Portal에서 Storage Explorer를 엽니다.
BLOB 컨테이너를 확장합니다.
Blob 컨테이너를 마우스 오른쪽 단추로 클릭하고, 공유 액세스 서명 가져오기를 선택합니다.
토큰 만료 기간을 선택합니다. 마이그레이션하는 동안 토큰이 유효한지 확인합니다.
토큰에 대한 표준 시간대(UTC 또는 현지 시간)를 선택합니다.
중요
토큰 및 관리 인스턴스의 표준 시간대가 일치하지 않을 수 있습니다. 표준 시간대를 고려하여 SAS 토큰에 적절한 유효 기간이 있는지 확인합니다. 표준 시간대 차이를 고려하려면 마이그레이션 기간이 시작되기 훨씬 전에 유효 기간 FROM 값을 설정하고 마이그레이션이 완료될 것으로 예상되는 것보다 훨씬 후로 TO 값을 설정합니다.
읽기 및 나열 권한만을 선택합니다.
중요
다른 권한은 선택하지 마세요. 선택하면 LRS가 시작되지 않습니다. 이 보안 요구 사항은 의도적으로 설계되었습니다.
만들기를 선택합니다.
지정된 유효 기간으로 SAS 인증이 생성됩니다. 다음 스크린샷에 표시된 것처럼 토큰의 URI 버전이 필요합니다.
참고
저장된 액세스 정책을 정의하여 설정된 권한으로 만든 SAS 토큰을 사용하는 것은 현재 지원되지 않습니다. 이 프로시저의 지침에 따라 SAS 토큰에 대한 읽기 및 나열 권한을 수동으로 지정합니다.
SAS 토큰에서 매개 변수 복사
SAS 토큰 또는 관리 ID를 사용하여 Azure Blob Storage 계정에 액세스합니다.
SAS 토큰을 사용하여 LRS를 시작하기 전에 해당 구조를 이해해야 합니다. 생성된 SAS 토큰의 URI는 이 예제와 같이 물음표(?)로 구분된 두 부분으로 구성됩니다.
첫 번째 부분은 https://부터 물음표(?)까지이며, LRS에 입력으로 제공되는 StorageContainerURI 매개 변수에 사용됩니다. 데이터베이스 백업 파일이 저장된 폴더에 대한 LRS 정보를 제공합니다.
물음표(?) 뒤부터 문자열 끝까지 이어지는 두 번째 부분은 StorageContainerSasToken 매개 변수입니다. 이 부분은 지정된 시간 동안 유효한 실제 서명된 인증 토큰입니다. 예제에 표시된 것처럼 이 부분이 반드시 sp=로 시작하는 것은 아닙니다. 시나리오가 다를 수 있습니다.
다음과 같이 매개 변수를 복사합니다.
토큰의 첫 번째 부분(
https://부터 물음표(?)를 포함하지 않고 그 전까지)을 복사합니다. LRS를 시작할 때 PowerShell 또는 Azure CLI에서StorageContainerUri매개 변수로 사용합니다.
토큰의 두 번째 부분(물음표(
?) 뒤부터 문자열의 끝까지)을 복사합니다. LRS를 시작할 때 PowerShell 또는 Azure CLI에서StorageContainerSasToken매개 변수로 사용합니다.
참고
토큰 부분을 복사하는 경우 물음표(?)를 포함하지 마세요.
관리되는 인스턴스 스토리지 액세스 유효성 검사
관리되는 인스턴스가 Blob Storage 계정에 액세스할 수 있는지 확인합니다.
먼저 full_0_0.bak와 같은 데이터베이스 백업을 Azure Blob Storage 컨테이너에 업로드합니다.
그런 다음, 관리되는 인스턴스에 연결하고 샘플 테스트 쿼리를 실행하여 관리되는 인스턴스가 컨테이너의 백업에 액세스할 수 있는지 확인합니다.
SAS 토큰을 사용하여 스토리지 계정에 인증하는 경우 <sastoken>을 SAS 토큰으로 바꾸고 인스턴스에서 다음 쿼리를 실행합니다.
CREATE CREDENTIAL [https://mitutorials.blob.core.windows.net/databases]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE'
, SECRET = '<sastoken>'
RESTORE HEADERONLY
FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak'
Blob Storage 계정에 백업 업로드
Blob 컨테이너가 준비되고 관리되는 인스턴스가 컨테이너에 액세스할 수 있음을 확인하면 Blob Storage 계정에 백업 업로드를 시작할 수 있습니다. 다음 작업 중 하나를 수행할 수 있습니다.
- Blob Storage 계정에 백업을 복사합니다.
- 사용자 환경에서 허용하는 경우(SQL Server 버전 2012 SP1 CU2 및 SQL Server 2014부터 시작) BACKUP TO URL 명령을 사용하여 SQL Server에서 Blob Storage 계정으로 직접 백업을 수행합니다.
Blob Storage 계정에 기존 백업을 복사합니다.
이전 버전의 SQL Server를 사용 중이거나 사용자 환경에서 URL에 대한 직접 백업을 지원하지 않는 경우 평소와 같이 SQL Server 인스턴스에서 백업을 수행한 다음, Blob Storage 계정에 복사합니다.
SQL Server 인스턴스에서 백업 수행
전체 복구 모드로 마이그레이션하려는 데이터베이스에서 로그 백업을 허용하도록 설정합니다.
-- To permit log backups, before the full database backup, modify the database to use the full recovery
USE master
ALTER DATABASE SampleDB
SET RECOVERY FULL
GO
로컬 스토리지에 데이터베이스의 전체, 차등 및 로그 백업을 수동으로 만들려면 다음 샘플 T-SQL 스크립트를 사용합니다. CHECKSUM 는 필요하지 않지만 손상된 데이터베이스 마이그레이션을 방지하고 복원 시간을 단축하는 것이 좋습니다.
다음 예에서는 로컬 디스크에 전체 데이터베이스 백업을 수행합니다.
-- Take full database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO
다음 예에서는 로컬 디스크에 차등 백업을 수행합니다.
-- Take differential database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_diff.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO
다음 예에서는 로컬 디스크에 트랜잭션 로그 백업을 수행합니다.
-- Take transactional log backup to local disk
BACKUP LOG [SampleDB]
TO DISK='C:\BACKUP\SampleDB_log.trn'
WITH COMPRESSION, CHECKSUM
GO
Blob Storage 계정에 백업 복사
백업이 준비되고 LRS를 사용하여 관리되는 인스턴스로 데이터베이스 마이그레이션을 시작하려는 경우 다음 방법을 사용하여 기존 백업을 Blob Storage 계정에 복사할 수 있습니다.
- AzCopy를 다운로드하고 설치합니다.
- Azure Storage Explorer를 다운로드하고 설치합니다.
- Azure Portal에서 Storage Explorer를 사용합니다.
참고
동일한 Azure Blob Storage 컨테이너를 사용하여 여러 데이터베이스를 마이그레이션하려면 개별 데이터베이스의 모든 백업 파일을 컨테이너 내의 별도 폴더에 배치합니다. 각 데이터베이스 폴더에 대해 플랫 파일 구조를 사용합니다. 데이터베이스 폴더 내에 폴더를 중첩하는 것은 지원되지 않습니다.
Blob Storage 계정으로 직접 백업하기
지원되는 SQL Server 버전(SQL Server 2012 SP1 CU2 및 SQL Server 2014부터 시작)을 사용 중이고 회사 및 네트워크 정책에서 허용하는 경우 원시 SQL Server BACKUP TO URL 옵션을 사용하여 SQL Server에서 Blob Storage 계정으로 직접 백업을 수행할 수 있습니다. BACKUP TO URL을 사용할 수 있는 경우 로컬 스토리지에 백업을 수행하고 Blob Storage 계정에 업로드할 필요가 없습니다.
Blob Storage 계정에 네이티브 백업을 직접 수행하는 경우 스토리지 계정에 인증해야 합니다.
다음 명령을 사용하여 SAS 토큰을 SQL Server 인스턴스로 가져오는 자격 증명을 만듭니다.
CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
SECRET = '<SAS_TOKEN>';
SAS 토큰 작업에 대한 자세한 내용은 SQL Server에서 Azure Blob Storage 사용 자습서를 검토하세요.
Blob Storage를 사용하여 SQL Server 인스턴스를 인증하기 위한 자격 증명을 만든 후 BACKUP TO URL 명령을 사용하여 스토리지 계정에 직접 백업을 수행할 수 있습니다. CHECKSUM은 권장되지만 필수는 아닙니다.
다음 예에서는 URL에 전체 데이터베이스 백업을 수행합니다.
-- Take a full database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO
다음 예에서는 URL에 차등 데이터베이스 백업을 수행합니다.
-- Take a differential database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_diff.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO
다음 예에서는 URL에 트랜잭션 로그 백업을 수행합니다.
-- Take a transactional log backup to a URL
BACKUP LOG [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_log.trn'
WITH COMPRESSION, CHECKSUM
Azure에 로그인하고 구독을 선택합니다.
다음 PowerShell cmdlet을 사용하여 Azure에 로그인합니다.
Login-AzAccount
다음 PowerShell cmdlet을 사용하여 관리되는 인스턴스가 있는 구독을 선택합니다.
Select-AzSubscription -SubscriptionId <subscription ID>
마이그레이션 시작
LRS를 시작하여 마이그레이션을 시작합니다. 자동 완성 또는 연속 모드로 서비스를 시작할 수 있습니다.
자동 완성 모드를 사용하는 경우 지정된 백업 파일의 마지막 부분이 복원되면 마이그레이션이 자동으로 완료됩니다. 이 옵션을 사용하려면 전체 백업 체인을 미리 사용할 수 있고 Blob Storage 계정에 업로드해야 합니다. 마이그레이션 진행 중에는 새 백업 파일을 추가할 수 없습니다. 이 옵션을 사용하려면 start 명령으로 마지막 백업 파일의 파일 이름을 지정해야 합니다. 이 모드는 데이터 캐치업이 필요하지 않은 수동 워크로드에 권장됩니다.
연속 모드를 사용하는 경우 서비스는 Azure Blob Storage 폴더를 지속적으로 스캔하고 마이그레이션이 진행되는 동안 추가되는 모든 새 백업 파일을 복원합니다. 마이그레이션은 수동 컷오버가 요청된 후에만 완료됩니다. 사전에 전체 백업 체인이 없는 경우와 마이그레이션이 진행된 후에 새 백업 파일을 추가하려는 경우 연속 모드 마이그레이션을 사용해야 합니다. 이 모드는 데이터 캐치업이 필요한 활성 워크로드에 권장됩니다.
최대 30일 이내에 단일 LRS 마이그레이션 작업을 완료하도록 계획합니다. 이 시간이 만료되면 LRS 작업이 자동 취소됩니다.
참고 항목
여러 데이터베이스를 마이그레이션하는 경우 각 데이터베이스는 자체 폴더에 있어야 합니다. Azure Blob Storage 컨테이너 및 개별 데이터베이스 폴더의 전체 URI 경로를 가리키는 각 데이터베이스에 대해 별도로 LRS를 시작해야 합니다. 데이터베이스 폴더 내의 중첩 폴더는 지원되지 않습니다.
자동 완성 모드로 LRS 시작
전체 백업 체인이 Azure Blob Storage 계정으로 업로드되었는지 확인합니다. 이 옵션은 마이그레이션이 진행되는 동안 새 백업 파일을 추가하는 것을 허용하지 않습니다.
자동 완성 모드로 LRS를 시작하려면 PowerShell 또는 Azure CLI 명령을 사용합니다. -LastBackupName 매개 변수를 사용하여 마지막 백업 파일 이름을 지정합니다. 마지막으로 지정한 백업 파일의 복원이 완료된 후 서비스는 자동으로 컷오버를 시작합니다.
SAS 토큰 또는 관리 ID를 사용하여 스토리지 계정에서 데이터베이스를 복원합니다.
중요
- 자동 완성 모드에서 마이그레이션을 시작하기 전에 전체 백업 체인이 Azure Blob Storage 계정에 업로드되었는지 확인합니다. 이 모드에서는 마이그레이션이 진행되는 동안 새 백업 파일을 추가할 수 없습니다.
- 마지막 백업 파일을 올바르게 지정했으며 그 이후에 더 이상 파일을 업로드하지 않았는지 확인합니다. 시스템에서 마지막으로 지정한 백업 파일을 초과하여 더 많은 백업 파일을 검색하면 마이그레이션이 실패합니다.
다음 PowerShell 예제는 SAS 토큰을 사용하여 자동 완성 모드에서 LRS를 시작합니다.
Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-Collation "SQL_Latin1_General_CP1_CI_AS" `
-StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
-StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D" `
-AutoCompleteRestore `
-LastBackupName "last_backup.bak"
다음 Azure CLI 예제는 SAS 토큰을 사용하여 자동 완성 모드에서 LRS를 시작합니다.
az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb -a --last-bn "backup.bak"
--storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
--storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"
연속 모드에서 LRS 시작
초기 백업 체인을 Azure Blob Storage 계정에 업로드했는지 확인합니다.
중요
연속 모드에서 LRS를 시작한 후에는 수동 컷오버까지 스토리지 계정에 새 로그 및 차등 백업을 추가할 수 있습니다. 수동 컷오버가 시작된 후에는 추가 차등 파일을 추가하거나 복원할 수 없습니다.
다음 PowerShell 예제는 SAS 토큰을 사용하여 연속 모드에서 LRS를 시작합니다.
Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
-StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"
다음 Azure CLI 예제는 연속 모드에서 LRS를 시작합니다.
az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb
--storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
--storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"
마이그레이션 작업 스크립팅
연속 모드에서 LRS를 시작하는 PowerShell 및 Azure CLI 클라이언트는 동기식입니다. 이 모드에서 PowerShell 및 Azure CLI는 작업을 시작하기 전에 API 응답이 성공 또는 실패를 보고할 때까지 기다립니다.
기다리는 동안 명령은 명령 프롬프트에 컨트롤을 반환하지 않습니다. 마이그레이션 환경을 스크립팅하고 있고 나머지 스크립트를 계속하기 위해 제어권을 즉시 돌려주는 LRS 시작 명령이 필요한 경우 -AsJob 스위치를 사용하여 PowerShell을 백그라운드 작업으로 실행할 수 있습니다. 예를 들어:
$lrsjob = Start-AzSqlInstanceDatabaseLogReplay <required parameters> -AsJob
백그라운드 작업을 시작하면 작업이 완료되는 데 시간이 오래 걸리는 경우에도 작업 개체가 즉시 반환됩니다. 작업이 실행되는 동안 중단 없이 세션에서 작업을 계속할 수 있습니다. 백그라운드 작업으로 PowerShell을 실행하는 방법에 대한 자세한 내용은 Powershell Start-Job 설명서를 참조하세요.
마찬가지로, Linux에서 Azure CLI 명령을 백그라운드 프로세스로 시작하려면 LRS 시작 명령 끝에 앰퍼샌드(&)를 사용합니다.
az sql midb log-replay start <required parameters> &
마이그레이션 진행률 모니터
Az.SQL 4.0.0 이상에서는 자세한 진행 보고서를 제공합니다. 샘플 출력은 관리되는 데이터베이스 복원 세부 정보 - 가져오기를 검토하세요.
PowerShell을 통해 진행 중인 마이그레이션 프로세스를 모니터하려면 다음 명령을 사용합니다.
Get-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName"
Azure CLI를 통해 진행 중인 마이그레이션 프로세스를 모니터하려면 다음 명령을 사용합니다.
az sql midb log-replay show -g mygroup --mi myinstance -n mymanageddb
실패한 요청에 대한 추가적인 세부 정보를 추적하려면 PowerShell 명령 Get-AzSqlInstanceOperation이나 Azure CLI 명령 az sql mi op show를 사용합니다.
마이그레이션 중지(선택 사항)
마이그레이션을 중지해야 하는 경우 PowerShell 또는 Azure CLI를 사용합니다. 마이그레이션을 중지하면 관리되는 인스턴스에서 복원 중인 데이터베이스가 삭제되므로 마이그레이션을 다시 시작할 수 없습니다.
PowerShell을 통해 마이그레이션 프로세스를 중지하려면 다음 명령을 사용합니다.
Stop-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName"
Azure CLI를 통해 마이그레이션 프로세스를 중지하려면 다음 명령을 사용합니다.
az sql midb log-replay stop -g mygroup --mi myinstance -n mymanageddb
마이그레이션 완료(연속 모드)
연속 모드에서 LRS를 시작하는 경우 새 백업 파일이 생성되지 않도록 애플리케이션 및 SQL Server 워크로드가 중지되었는지 확인합니다. SQL Server 인스턴스의 마지막 백업이 Azure Blob Storage 계정에 업로드되었는지 확인합니다. 관리되는 인스턴스에서 복원 진행률을 모니터링하고 마지막 로그 테일 백업이 복원되었는지 확인합니다.
관리되는 인스턴스에서 마지막 로그 테일 백업이 복원되면 수동 컷오버를 시작하여 마이그레이션을 완료합니다. 컷오버가 완료되면 데이터베이스는 관리되는 인스턴스에서 읽기 및 쓰기 액세스가 가능해집니다.
PowerShell을 통해 LRS 연속 모드의 마이그레이션 프로세스를 완료하려면 다음 명령을 사용합니다.
Complete-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-LastBackupName "last_backup.bak"
Azure CLI를 통해 LRS 연속 모드의 마이그레이션 프로세스를 완료하려면 다음 명령을 사용합니다.
az sql midb log-replay complete -g mygroup --mi myinstance -n mymanageddb --last-backup-name "backup.bak"
제한 사항
LRS를 사용하여 마이그레이션할 때는 다음과 같은 제한 사항을 고려합니다.
- 마이그레이션 프로세스가 완료될 때까지 LRS를 통해 복원되는 데이터베이스를 사용할 수 없습니다.
- 마이그레이션 프로세스 중에 마이그레이션되는 데이터베이스는 SQL Managed Instance에 대한 읽기 전용 액세스에 사용할 수 없습니다.
- 마이그레이션이 완료되면 마이그레이션 프로세스가 최종적으로 완료되므로 추가 차등 백업을 사용하여 다시 시작할 수 없습니다.
- 데이터베이스
.bak,.log,.diff파일만 LRS에서 지원됩니다. Dacpac 및 bacpac 파일은 지원되지 않습니다. - 특정 날짜 및 시간에 시스템 업데이트를 예약하도록 유지 관리 기간을 구성해야 합니다. 예약된 유지 관리 기간 외에 마이그레이션을 실행하고 완료하도록 계획합니다.
- 다음 없이
CHECKSUM수행되는 데이터베이스 백업:- 는 잠재적으로 손상된 데이터베이스를 마이그레이션할 수 있습니다.
- 사용하도록 설정된 데이터베이스 백업보다 복원하는
CHECKSUM데 시간이 더 오래 걸립니다.
- LRS에서 사용하는 SAS(공유 액세스 서명) 토큰은 전체 Azure Blob Storage 컨테이너에 대해 생성되어야 하며 사용 권한만 있어야
ReadList합니다. 예를 들어 권한List및Write권한을 부여Read하면 추가Write권한으로 인해 LRS가 시작되지 않습니다. - 저장된 액세스 정책 정의를 통해 설정된 권한으로 만든 SAS 토큰을 사용하는 것은 지원되지 않습니다. 이 문서의 지침에 따라 SAS 토큰에 대한 읽기 및 나열 권한을 수동으로 지정합니다.
- 다른 데이터베이스에 대한 백업 파일은 플랫 파일 구조로 Blob Storage 계정의 별도 폴더에 배치해야 합니다. 데이터베이스 폴더 내에 폴더를 중첩하는 것은 지원되지 않습니다.
- 자동 완성 모드를 사용하는 경우 전체 백업 체인을 Blob Storage 계정에서 미리 사용할 수 있어야 합니다. 자동 완성 모드에서는 새 백업 파일을 추가할 수 없습니다. 마이그레이션이 진행되는 동안 새 백업 파일을 추가해야 하는 경우 연속 모드를 사용합니다.
- 개별 데이터베이스 폴더가 포함된 전체 URI 경로를 가리키는 각 데이터베이스에 대해 별도로 LRS를 시작해야 합니다.
- 백업 URI 경로, 컨테이너 이름 또는 폴더 이름은 포함할 수 없거나 예약된 키워드이므로 포함
backupbackups할 수 없습니다. - 동일한 스토리지 컨테이너를 대상으로 여러 Log Replay 복원을 병렬로 시작할 때 모든 복원 작업에 대해 같은 유효한 SAS 토큰이 제공되는지 확인합니다.
- LRS는 단일 관리형 인스턴스당 최대 100개의 동시 복원 프로세스를 지원할 수 있습니다.
- 단일 LRS 작업은 최대 30일 동안 실행될 수 있으며, 그 후에는 자동으로 취소됩니다.
- 방화벽 뒤에서 Azure Storage 계정을 사용할 수 있지만 추가 구성이 필요하며 스토리지 계정과 관리형 인스턴스가 동일한 지역 또는 두 개의 쌍을 이루는 지역에 있어야 합니다. 자세한 내용은 방화벽 구성을 검토하세요.
- 병렬로 복원할 수 있는 최대 데이터베이스 수는 단일 구독당 200개입니다. 경우에 따라 지원 티켓을 열어 이 한도를 늘릴 수 있습니다.
- 수천 대의 데이터베이스 파일을 업로드하여 복원하면 과도한 마이그레이션 시간과 심지어 오류가 발생할 수 있습니다. 데이터베이스를 더 적은 수의 파일로 통합하여 마이그레이션 프로세스를 가속화하고 성공을 보장합니다.
참고 항목
마이그레이션을 수행하고 가동 중지 시간을 최소화하기 위해 훨씬 더 긴 시간 프레임으로 마이그레이션하는 동안 데이터베이스를 읽기 전용으로 액세스해야 하는 경우 권장되는 마이그레이션 솔루션으로 Managed Instance 링크 기능을 사용하는 것이 좋습니다.
중요 비즈니스용 서비스 계층으로 마이그레이션할 때의 제한 사항
중요 비즈니스용 서비스 계층에서 SQL Managed Instance로 마이그레이션할 때 다음 제한 사항을 고려합니다.
- 대용량 데이터베이스를 마이그레이션할 때 데이터베이스가 중요 비즈니스용 서비스 계층의 보조 복제본에 시드되는 동안 중단 후 데이터베이스를 사용할 수 없으므로 상당한 가동 중지 시간이 발생할 수 있습니다. 해결 방법은 긴 단독형 섹션에 나열됩니다.
- un계획된 장애조치, 시스템 업데이트 또는 보안 패치로 인해 마이그레이션이 중단되면 마이그레이션이 처음부터 자동으로 다시 시작되므로 막판에 놀라움 없이 예측 가능한 마이그레이션을 계획하기가 어렵습니다.
Important
이러한 제한 사항은 범용 서비스 계층이 아닌 중요 비즈니스용 서비스 계층으로 마이그레이션할 때만 적용됩니다.
중요 비즈니스용 서비스 계층에서 더 긴 단독형
중요 비즈니스용 서비스 계층의 SQL Managed Instance로 마이그레이션하는 경우 주 복제본에서 데이터베이스를 보조 복제본에 시드하는 동안 데이터베이스를 온라인 상태로 만드는 데 지연이 발생하는 것을 고려합니다. 특히 대규모 데이터베이스의 경우 그렇습니다.
중요 비즈니스용 서비스 계층에서 SQL Managed Instance로 마이그레이션하는 작업은 범용 서비스 계층보다 완료하는 데 더 오래 걸립니다. Azure로 전환이 완료되면 주 복제본에서 세 개의 보조 복제본으로 시드될 때까지 데이터베이스를 사용할 수 없습니다. 데이터베이스 크기에 따라 시간이 오래 걸릴 수 있습니다. 데이터베이스가 클수록 보조 복제본에 대한 시드 시간이 길어질수록 최대 몇 시간까지 걸릴 수 있습니다.
중단이 완료되는 즉시 데이터베이스를 사용할 수 있는 것이 중요한 경우 다음 해결 방법을 고려합니다.
- 먼저 범용 서비스 계층으로 마이그레이션한 다음 후속 유지 관리 기간 동안 중요 비즈니스용 서비스 계층으로 업그레이드합니다. 서비스 계층 업그레이드는 업그레이드 작업의 마지막 단계로 짧은 장애 조치(failover)가 될 때까지 데이터베이스를 온라인 상태로 유지하는 온라인 작업입니다.
- 단독형 후 데이터베이스를 사용할 수 있을 때까지 기다리지 않고도 중요 비즈니스용 인스턴스로 온라인 마이그레이션을 위해 Managed Instance 링크를 사용합니다.
LRS 문제 해결
LRS를 시작한 후 다음 모니터링 cmdlet 중 하나를 사용하여 진행 중인 작업의 상태를 확인합니다.
- PowerShell의 경우:
get-azsqlinstancedatabaselogreplay - Azure CLI의 경우:
az_sql_midb_log_replay_show
실패한 작업에 대한 세부 정보를 다음과 같이 검토합니다.
- PowerShell의 경우: Get-AzSqlInstanceOperation
- Azure CLI의 경우: az sql mi op show
LRS가 시작되지 않고 오류가 발생하는 경우 가장 일반적인 문제를 확인합니다.
- 관리되는 인스턴스의 기존 데이터베이스가 SQL Server 인스턴스에서 마이그레이션하려는 데이터베이스와 동일한 이름을 갖고 있나요? 데이터베이스 중 하나의 이름을 바꿔서 이 충돌을 해결합니다.
- SAS 토큰 읽기 및 나열에만 부여된 권한이 있나요? LRS보다
ReadList많은 권한을 부여하면 LRS가 실패합니다. sv=2020-02-10...와 같은 내용으로 물음표(?) 뒤에 LRS용 SAS 토큰을 복사했습니까?- SAS 토큰 유효 기간이 마이그레이션을 시작하고 완료하는 기간에 해당하나요? SQL Managed Instance 배포 및 SAS 토큰에 사용되는 서로 다른 표준 시간대로 인해 불일치가 발생할 수 있습니다. SAS 토큰을 다시 생성하고 토큰의 유효 기간을 현재 날짜 전과 후로 늘립니다.
- 동일한 스토리지 컨테이너를 대상으로 여러 Log Replay 복원을 병렬로 시작할 때 모든 복원 작업에 대해 같은 유효한 SAS 토큰이 제공되는지 확인합니다.
- 데이터베이스 이름, 리소스 그룹 이름 및 관리 인스턴스 이름의 철자가 정확한가요?
- 자동 완성 모드로 LRS를 시작한 경우 지정된 마지막 백업 파일의 이름이 올바른가요?
- 백업 URI 경로에
backup또는backups키워드(keyword) 포함되나요?backup또는backups는 예약된 키워드(keyword)이므로 해당 키워드를 사용하는 컨테이너 또는 폴더의 이름을 바꿉니다.
다음 단계
- 링크 기능을 사용하여 Azure SQL Managed Instance로 마이그레이션에 대한 자세한 정보.
- SQL Server에서 Azure SQL Managed Instance로의 마이그레이션에 대한 자세한 정보.
- SQL Server와 SQL Managed Instance의 차이점에 대한 자세한 정보.
- Azure로 마이그레이션된 워크로드의 비용 및 크기 조정 모범 사례에 대해 자세히 알아봅니다.