자습서: Azure Portal에서 DMS 물리적 마이그레이션을 사용하여 MySQL에서 Azure Database for MySQL로 마이그레이션(미리 보기)

물리적 백업 파일을 사용하여 Azure 또는 다른 클라우드 서비스의 MySQL 온-프레미스 또는 VM(Virtual Machine) 워크로드를 Azure Database for MySQL로 원활하게 마이그레이션할 수 있습니다. 물리적 백업 파일을 사용하면 가동 중지 시간을 최소화하면서 원본 서버를 대상 유연한 서버 인스턴스로 신속하게 복원할 수 있습니다. 이 자습서에서는 Percona XtraBackup을 사용하여 가동 중지 시간을 최소화하면서 Azure DMS를 사용하여 온-프레미스 또는 VM에서 Azure Database for MySQL로 MySQL 워크로드를 마이그레이션하는 방법을 보여 줍니다.

비고

DMS 물리적 온라인 데이터 마이그레이션 은 현재 공개 미리 보기로 제공됩니다. DMS는 MySQL 버전 5.7 및 8.0으로 마이그레이션하고 하위 버전 MySQL 서버(v5.6 이상)에서 더 높은 버전의 MySQL 서버로 마이그레이션을 지원합니다. 또한 DMS는 지역 간, 리소스 간 그룹 및 구독 간 마이그레이션을 지원합니다.

이 튜토리얼에서는 다음을 배우게 됩니다:

원본 MySQL 서버, 대상 유연한 서버 및 기타 필수 서비스를 만들고 구성합니다.
DMS 인스턴스를 만듭니다.
DMS에서 물리적 마이그레이션을 위한 MySQL 마이그레이션 프로젝트를 만듭니다.
마이그레이션을 실행합니다.
마이그레이션을 모니터링합니다.
마이그레이션 후 활동을 수행합니다.
마이그레이션을 수행하기 위한 모범 사례를 구현합니다.

필수 조건

이 자습서를 완료하려면 다음이 필요합니다.

기존 MySQL 인스턴스(온-프레미스 또는 Azure 또는 다른 클라우드의 VM에 상관없이 원본 서버)를 만들거나 사용합니다.
온라인 마이그레이션을 성공적으로 완료하려면 원본 MySQL 서버에 다음 필수 구성 요소가 있는지 확인합니다.
- 매개 변수 lower_case_table_names를 1로 설정했는지 확인합니다.
- 매개 변수 innodb_file_per_table .로 설정되어 있는지 확인합니다 ON.
- 시스템 테이블스페이스는 ibdata1이어야 합니다.
- 시스템 테이블스페이스 ibdata1 크기는 (MySQL 기본값)보다 크거나 같 12MB 아야 합니다.
- 매개 변수 innodb_page_size (MySQL 기본값)으로 16384 설정되었는지 확인합니다.
- INNODB 스토리지 엔진만 지원됩니다.
- 온라인 마이그레이션을 완료하기 위해 매개 변수 binlog_expire_logs_seconds 사용하여 binlog 보존 기간이 적절하게 설정되었는지 확인합니다.
- 마이그레이션에 사용된 사용자가 원본 서버에서 REPLICATION CLIENT 및 REPLICATION REPLICA 권한을 가지고 있어 bin 로그를 읽고 적용할 수 있는지 확인합니다.
Percona XtraBackup을 사용하여 MySQL 워크로드의 물리적 백업을 수행합니다.

다음은 Percona XtraBackup을 사용하여 전체 백업을 수행하는 단계입니다.
- 온-프레미스 또는 VM 워크로드에 Percona XtraBackup을 설치합니다. MySQL 엔진 버전 v5.7의 경우 Percona XtraBackup 버전 2.4를 설치하고 Percona XtraBackup 2.4 설치를 참조하세요. MySQL 엔진 버전 v8.0의 경우 Percona XtraBackup 버전 8.0을 설치하고 Percona XtraBackup 8.0 설치를 참조하세요.
- Percona XtraBackup 2.4를 사용하여 전체 백업을 수행하는 방법에 대한 지침은 전체 백업을 참조하세요. Percona XtraBackup 8.0으로 전체 백업을 수행하는 방법에 대한 지침은 전체 백업을 참조하세요.
- 전체 백업을 수행하는 동안 다음 명령을 순서대로 실행합니다.
  
  를 {host}{user}{password} 적절한 값으로 바꾸고 {backup_dir_path}두 명령에서 동일한 백업 경로를 사용합니다.
```
xtrabackup --backup --host={host} --user={user} --password={password} --target-dir={backup_dir_path}

xtrabackup --prepare --{backup_dir_path}
```
- Percona XtraBackup을 사용하는 동안 고려 사항:
  - 백업 및 준비 단계를 모두 실행해야 합니다.
  - 백업 및 준비 단계에 오류가 없는지 확인합니다.
  - 백업을 유지하고 Azure 지원에 대한 단계 로그를 준비합니다. 이 로그는 오류가 있는 경우 필요합니다.
  중요합니다
  
  원본 서버에서 가져온 손상된 테이블에 액세스하려고 하면 대상 유연한 서버가 충돌할 수 있습니다. 따라서 Percona XtraBackup 유틸리티를 사용하여 백업을 수행하기 전에 원본 서버에서 "mysqlcheck /Optimize Table" 작업을 수행하는 것이 좋습니다.
유연한 대상 서버를 만듭니다. 단계별 지침은 빠른 시작 Azure Portal을 사용하여 Azure Database for MySQL 인스턴스를 만드는 방법을 참조하세요.
- 대상 유연한 서버에서 큰 행 데이터 전송으로 인한 연결 문제를 방지하기 위해 max_allowed_packet를 1073741824로 설정합니다 (즉, 1GB로 설정).
- 대상 유연한 서버의 sql_mode 서버 매개 변수를 원본 서버 구성과 일치하도록 설정합니다.
- 원본 서버의 TLS version 값과 일치하도록 서버 매개 변수 및 require_secure_transport 서버 매개 변수를 설정합니다.
- 원본 서버에서 사용되는 기본값이 아닌 값과 일치하도록 대상 유연한 서버에서 서버 매개 변수를 구성합니다.
Azure Blob 컨테이너를 만들고 컨테이너에 대한 SAS(공유 액세스 서명) 토큰(Azure Portal 또는 Azure CLI)을 가져옵니다. 사용 권한 드롭다운 목록에서 추가, 만들기 및 쓰기를 부여해야 합니다.

중요합니다

Blob SAS 토큰 및 URL 값을 안전한 위치에 저장합니다. 이는 한 번만 표시되며 창을 닫은 후에는 검색할 수 없습니다.
{backup_dir_path}의 Percona XtraBackup에서 Azure Blob Storage로 전체 백업 파일을 업로드합니다. 다음 단계에 따라 파일을 업로드합니다.
DMS는 xtrabackup_binlog_info 파일에서 전체 백업을 수행하는 경우 캡처된 binlog 위치를 사용하여 최소 가동 중지 시간 마이그레이션을 위해 복제 프로세스를 자동으로 시작합니다.
AZURE Storage 계정은 SAS 토큰을 사용하여 공개적으로 액세스할 수 있어야 합니다. 가상 네트워크 구성이 있는 Azure Storage 계정은 지원되지 않습니다.
실제 마이그레이션 워크플로에서 사용할 앱 등록을 만들고 클라이언트 암호를 사용하여 앱 키를 생성합니다. 이 앱은 SAS 키 만들기 및 서버 업데이트를 위해 스토리지 계정 및 대상 유연한 서버와 함께 사용할 수 있습니다.
다음 역할이 있는 스토리지 계정에 대한 앱 등록을 사용하여 RBAC(역할 기반 액세스 제어) 역할 할당을 할당합니다.
- Blob 컨테이너 파일을 읽기 위한 Storage Blob 데이터 판독기.
대상 MySQL 유연 서버의 애플리케이션 등록에 기여자 역할을 할당합니다.

제한점

마이그레이션을 준비할 때 다음 제한 사항을 고려합니다.

원본 서버 구성이 마이그레이션되지 않았습니다. 마이그레이션을 시작하기 전에 대상 유연한 서버를 적절하게 구성해야 합니다.

암호화된 백업에 대한 마이그레이션은 지원되지 않습니다.
가져오기 작업 중 마이그레이션 취소는 지원되지 않습니다.
온라인 마이그레이션 지원은 binlog 형식으로 ROW 제한됩니다.
Azure Database for MySQL은 혼합 사례 데이터베이스를 지원하지 않습니다.
Azure DMS 문 또는 binlog 복제는 다음 구문을 CREATE TABLE 'b' as SELECT * FROM 'a';지원하지 않습니다. 이 DDL을 복제하면 "START TRANSACTION 문이 있는 CREATE TABLE 이후에 BINLOG INSERT, COMMIT 및 ROLLBACK 문만 허용됩니다." 오류가 발생합니다.
마이그레이션 기간은 백 엔드의 컴퓨팅 유지 관리의 영향을 받으므로 진행률을 다시 설정할 수 있습니다.

DMS를 사용하여 더 빠른 데이터 로드를 위한 모범 사례

DMS는 지역 간, 리소스 간 그룹 및 구독 간 마이그레이션을 지원하므로 대상 유연한 서버에 적합한 지역, 리소스 그룹 및 구독을 선택할 수 있습니다. 대상 유연한 서버를 만들기 전에 DMS를 사용하여 더 빠른 데이터 로드를 보장하려면 다음 구성 참고 자료를 고려하세요.

최적의 마이그레이션 환경을 위해 원본 MySQL 서버 구성에 따라 대상 유연한 서버에 대한 컴퓨팅 크기 및 컴퓨팅 계층 을 선택합니다.
- 마이그레이션하는 동안 대상 유연한 서버를 General-Purpose 또는 중요 비즈니스용 SKU로 설정하는 것이 좋습니다. 마이그레이션이 성공하면 애플리케이션 요구 사항에 맞게 인스턴스를 적절한 크기로 확장할 수 있습니다.
대상 유연한 서버의 MySQL 버전은 원본 MySQL 서버의 버전보다 크거나 같아야 합니다.
특정 영역에 대상 유연한 서버를 배포할 필요가 없는 한 가용성 영역 매개 변수의 값을 기본 설정 없음으로 설정합니다.
가져오기 작업 중에 성능을 향상시키려면 Azure Blob Storage와 대상 유연한 서버를 동일한 지역에 배포하는 것이 좋습니다.

DMS 설정

대상 유연한 서버를 배포하고 구성한 다음, MySQL 서버를 유연한 서버로 마이그레이션하도록 DMS를 설정해야 합니다.

리소스 공급자 등록

Microsoft를 등록하려면. dataMigration 리소스 공급자는 다음 단계를 수행합니다.

첫 번째 DMS 인스턴스를 만들기 전에 Azure Portal에 로그인한 다음 구독을 검색하여 선택합니다.
DMS 인스턴스를 만들려는 구독을 선택한 다음, 리소스 공급자를 선택합니다.
"마이그레이션"을 검색한 다음 , Microsoft.DataMigration에 대해 등록을 선택합니다.

DMS(Database Migration Service) 인스턴스 만들기

Azure Portal에서 + 리소스 만들기를 선택하고 , "Azure Database Migration Service"라는 용어를 검색한 다음, 드롭다운 목록에서 Azure Database Migration Service 를 선택합니다.
Azure Database Migration Service 화면에서 만들기를 선택합니다.
마이그레이션 시나리오 및 Database Migration Service 선택 페이지의 마이그레이션 시나리오에서 원본 서버 형식으로 MySQL을 선택하고 대상 서버 형식으로 Azure Database for MySQL을 선택한 다음 선택을 선택합니다.
마이그레이션 서비스 만들기 페이지의 기본 사항 탭의 프로젝트 세부 정보에서 적절한 구독을 선택한 다음 기존 리소스 그룹을 선택하거나 새 리소스 그룹을 만듭니다.
인스턴스 세부 정보에서 서비스의 이름을 지정하고, 지역을 선택하고, Azure가 서비스 모드로 선택되었는지 확인합니다.
가격 책정 계층 오른쪽에서 계층 구성을 선택합니다.
구성 페이지에서 DMS 인스턴스에 대해 4개의 vCore가 있는 프리미엄 가격 책정 계층을 선택한 다음 적용을 선택합니다.

DMS Premium 4-vCore는 요금이 부과되기 전에 DMS 서비스를 만든 날짜로부터 6개월(183일) 동안 무료입니다. DMS 비용 및 가격 책정 계층에 대한 자세한 내용은 가격 책정 페이지를 참조하세요.

다음으로 원본 MySQL 서버 및 대상 유연한 서버에 대한 DMS 인스턴스 액세스를 제공하는 가상 네트워크(가상 네트워크)를 지정해야 합니다.
마이그레이션 서비스 만들기 페이지에서 다음: 네트워킹을 >>선택합니다.
네트워킹 탭의 목록에서 기존 가상 네트워크를 선택하거나 만들려는 새 가상 네트워크의 이름을 입력한 다음 검토 + 만들기를 선택합니다.

자세한 내용은 Azure Portal을 사용하여 가상 네트워크 만들기를 참조하세요.

원본 MySQL 서버와 대상 유연한 서버 모두에 대한 액세스 권한으로 가상 네트워크를 구성해야 하므로 다음을 수행해야 합니다.
- 원본 MySQL 서버와 대상 MySQL 유연한 서버에 대한 서버 수준 방화벽 규칙을 만들어 Azure Database Migration Service의 가상 네트워크가 원본 및 대상 데이터베이스에 액세스할 수 있도록 합니다.
- 가상 네트워크 NSG(네트워크 보안 그룹) 규칙이 ServiceBus, Storage 및 Azure Monitor에 대한 ServiceTag의 아웃바운드 포트 443을 차단하지 않는지 확인합니다. 가상 네트워크 NSG 트래픽 필터링에 대한 자세한 내용은 네트워크 보안 그룹을 사용하여 네트워크 트래픽 필터링을 참조하세요.
비고

서비스에 태그를 추가하려면 다음: 태그를 선택하여 태그 탭으로 이동합니다. 서비스에 태그를 추가하는 것은 선택 사항입니다.
검토 + 만들기 탭으로 이동하고, 구성을 검토하고, 용어를 보고, 만들기를 선택합니다.

이제 DMS 인스턴스의 배포가 시작됩니다. "배포가 진행 중"이라는 메시지가 몇 분 동안 표시되면 "배포가 완료되었습니다."로 변경됩니다.
리소스로 이동을 선택합니다.
리소스 개요 페이지에서 DMS 인스턴스의 IP 주소를 식별하고, 원본 MySQL 서버에 대한 방화벽 규칙을 만들고, 유연한 서버를 대상으로 하여 DMS 인스턴스의 IP 주소를 허용 목록화합니다.

마이그레이션 프로젝트 만들기

마이그레이션 프로젝트를 만들려면 다음 단계를 수행합니다.

Azure Portal에서 모든 서비스를 선택하고, Azure Database Migration Service를 검색한 다음, Azure Database Migration Services를 선택합니다.
검색 결과에서 만든 DMS 인스턴스를 선택한 다음 + 새 마이그레이션 프로젝트를 선택합니다.
새 마이그레이션 프로젝트 페이지에서 프로젝트의 이름을 지정합니다. 원본 서버 유형 선택 상자에서 MySQL을 선택합니다. 대상 서버 유형 선택 상자에서 Azure Database For MySQL을 선택합니다. 마이그레이션 작업 유형 선택 상자에서 [미리 보기] 실제 온라인 데이터 마이그레이션을 선택합니다. 그런 다음 만들기를 선택하고 작업을 실행합니다.

마이그레이션 작업 유형으로 프로젝트 만들기 전용을 선택하면 마이그레이션 프로젝트만 생성되고, 그런 다음 나중에 실행할 수 있습니다.

마이그레이션 프로젝트 구성

DMS 마이그레이션 프로젝트를 구성하려면 다음 단계를 수행합니다.

원본 선택 화면에서 DMS가 원본 서버에 연결되어 있는 가상 네트워크에 있는지 확인해야 합니다. 여기서 원본 서버 이름, 서버 포트, 사용자 이름 및 암호를 원본 MySQL 서버에 입력한 다음 다음을 선택합니다. 대상 >>선택
대상 선택 화면의 자동화된 서버 선택에서 구독, 위치, 리소스 그룹, Azure Database for MySQL 서버 이름, 사용자 이름, 대상 Azure Database for MySQL 서버의 암호를 선택하고 다음을 선택합니다. 백업 >>선택
백업 선택 화면에서 앱 등록의 애플리케이션 ID, 앱 등록의 클라이언트 암호, 앱 등록의 테넌트 ID, 구독, 스토리지 계정 이름, Blob 컨테이너 이름 및 Percona XtraBackup 파일이 저장된 백업 디렉터리 이름을 입력하고 다음을 선택합니다. 마이그레이션 설정 >>구성

이제 사용자 계정 및 권한 마이그레이션 옵션이 있습니다 . 이 옵션을 선택하면 모든 로그인 마이그레이션이 마이그레이션됩니다. 또한 원본 MySQL 서버에서 대상 유연한 서버로 DDL 문을 복제할 수 있습니다.
마이그레이션 설정 구성 화면에서 마이그레이션 설정을 사용자 지정하려면 확인란을 선택하거나 다음: >> 요약을 선택하여 요약 페이지로 이동합니다.
요약 화면의 작업 이름 텍스트 상자에서 마이그레이션 작업의 이름을 지정합니다. 모든 마이그레이션 관련 세부 정보가 올바른지 확인하고 "마이그레이션 시작"을 선택합니다.
마이그레이션이 시작되면 마이그레이션 작업 창이 나타납니다. 초기 로드 탭에서 상태가 실행 중으로 변경됩니다.

마이그레이션 모니터링

마이그레이션이 진행 중일 때는 마이그레이션 상태를 검토하고, 가져오기 및 남은 예상 시간 같은 상태를 확인할 수 있습니다. 이는 실제 백업 파일 데이터를 대상 MySQL 유연 서버로 가져오는 과정에 대한 정보입니다.

초기 로드 작업이 완료되면 데이터 변경 내용 복제 탭으로 자동으로 이동합니다. 화면이 30초마다 자동으로 새로 고쳐질 때 마이그레이션 진행 상황을 모니터링하거나 새로 고침 단추를 선택할 수 있습니다.
초기 데이터 수집이 완료되면 데이터 변경 내용 복제 탭에서 원본으로부터 초를 모니터링합니다. 0이 되면, 마이그레이션 활동 화면 상단의 컷오버 시작 버튼으로 이동하여 컷오버를 시작하세요. 새로 고침을 선택하여 디스플레이를 업데이트하고 필요한 경우 원본 뒤의 초를 봅니다.
컷오버를 수행하기 전에 컷오버 창에서 1~3단계를 따르세요.
모든 단계를 완료한 후 확인을 선택한 다음 적용을 선택합니다.

마이그레이션 후 작업 수행

마이그레이션이 완료되면 다음 마이그레이션 후 작업을 완료해야 합니다.

대상 데이터베이스에 대한 유효성 검사 및 데이터 통합을 수행하여 언급된 방법 중 하나를 사용하여 마이그레이션 완료를 인증합니다.
- 원본 서버와 대상 유연한 서버 간의 행 수 또는 체크섬 을 비교하여 데이터의 유효성을 검사할 수 있습니다.
- 또한 대상 유연한 서버로 이동하여 설정에서 데이터베이스 페이지를 선택하고 마이그레이션하려는 데이터베이스가 대상으로 성공적으로 마이그레이션되었는지 확인할 수 있습니다.
새 유연한 서버를 가리키도록 연결 문자열을 업데이트합니다.
- DMS 리소스를 정리하기 위해 다음 단계를 수행합니다.
1. Azure Portal에서 모든 서비스를 선택하고, Azure Database Migration Service를 검색한 다음, Azure Database Migration Services를 선택합니다.
2. 검색 결과에서 마이그레이션 서비스 인스턴스를 선택하고 서비스 삭제를 선택합니다.
3. 확인 대화 상자의 TYPE THE DATABASE MIGRATION SERVICE NAME 텍스트 상자에서 인스턴스의 이름을 지정한 다음 삭제를 선택합니다 .
확장성 및 복구를 위해 유연한 서버에 대한 읽기 복제본을 만듭니다.

마이그레이션 모범 사례

마이그레이션을 수행하는 동안 다음 모범 사례를 고려해야 합니다.

검색 및 평가의 일환으로 서버 SKU, CPU 사용량, 스토리지, 데이터베이스 크기 및 확장 사용을 마이그레이션에 도움이 되는 중요한 데이터 중 일부로 고려합니다.
프로덕션용으로 마이그레이션하기 전에 테스트 마이그레이션을 수행합니다.
- 테스트 마이그레이션은 애플리케이션 테스트를 포함하여 데이터베이스 마이그레이션의 모든 측면을 다루는 데 중요합니다. 가장 좋은 방법은 먼저 테스트 목적으로 마이그레이션을 완전히 실행하는 것입니다. 새로 시작된 마이그레이션이 최소한의 지연으로 복제 데이터 변경 단계에 진입한 후, 테스트 워크로드를 실행하기 위해 유연한 서버 대상만 사용합니다. 해당 대상을 사용하여 애플리케이션을 테스트하고 예상된 성능 및 결과를 확인합니다. 더 높은 MySQL 버전으로 마이그레이션하는 경우 애플리케이션 호환성을 테스트합니다.
- 테스트가 완료되면 프로덕션 데이터베이스를 마이그레이션할 수 있습니다. 이 시점에서 프로덕션 마이그레이션의 날짜와 시간을 완료해야 합니다. 이상적으로는 이 시점에 애플리케이션 사용량이 적습니다. 참여해야 하는 모든 이해 관계자들이 작업을 시작할 수 있는 준비 상태가 되어야 합니다. 프로덕션 마이그레이션에는 면밀한 모니터링이 필요합니다. 온라인 마이그레이션의 경우 데이터 손실을 방지하기 위해 중단을 수행하기 전에 복제를 완료해야 합니다.
모든 종속 애플리케이션을 리디렉션하여 새 주 데이터베이스에 액세스하고 원본 서버를 읽기 전용으로 만듭니다. 그런 다음 프로덕션 사용을 위한 애플리케이션을 엽니다.
애플리케이션이 대상 유연한 서버에서 실행을 시작한 후 데이터베이스 성능을 면밀히 모니터링하여 성능 튜닝이 필요한지 여부를 확인합니다.

피드백

이 페이지가 도움이 되었나요?

Last updated on 2025-10-28