Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

MySQL에서 컷오버 실행

이 가이드에서는 Datastream 및 Dataflow를 사용하여 MySQL 소스 인스턴스에서 Spanner 데이터베이스로 라이브 데이터베이스 마이그레이션의 컷오버를 수행하는 방법을 설명합니다.

시작하기 전에

컷오버를 수행하기 전에 라이브 데이터 마이그레이션의 일부로 다음 작업을 완료했는지 확인합니다.

스키마 마이그레이션: 스키마를 Spanner에 배포합니다. 자세한 내용은 MySQL에서 스키마 마이그레이션을 참조하세요.
백필 마이그레이션: 초기 데이터 마이그레이션을 완료합니다. 백필 마이그레이션 Dataflow 작업을 사용하여 자세한 내용은 백필 마이그레이션 수행을 참조하세요.
활성 CDC 복제: 연속 변경 데이터 캡처 (CDC) 복제가 활성 상태이고 정상인지 확인합니다.
- Datastream 스트림이 소스 MySQL 데이터베이스에서 변경 이벤트를 적극적으로 읽고 Cloud Storage 버킷에 씁니다.
- Cloud Storage 버킷 알림이 객체 생성 이벤트를 Pub/Sub 주제에 게시합니다.
- 스트리밍 Dataflow 작업(Cloud_Datastream_to_Spanner)이 Pub/Sub 구독을 사용하고 1초 미만 또는 무시할 수 있는 복제 지연 시간으로 Spanner에 변경사항을 씁니다. 자세한 내용은 MySQL 데이터 마이그레이션을 참조하세요.
초기 데이터 검증: 데이터 검증 검사를 실행하여 소스 MySQL 인스턴스와 Spanner 대상 간의 데이터 일관성을 확인합니다. 자세한 내용은 데이터 마이그레이션 검증을 참조하세요.
데드 레터 큐 (DLQ) 상태 정리: Cloud Storage의 정방향 복제 심각한 DLQ 디렉터리 (예: gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/)가 완전히 비어 있는지 확인합니다. 심각한 오류가 있는 경우 기본 문제를 해결하고 컷오버를 시작하기 전에 retryDLQ 일괄 작업을 사용하여 실패한 모든 변경 이벤트를 재생합니다. 자세한 내용은 CDC DLQ 오류 모니터링 및 해결을 참조하세요.
역방향 복제 설정 (대체 준비): 비상 대체 경로가 필요한 경우 Spanner에서 소스 MySQL 데이터베이스로 다시 활성 역방향 복제 파이프라인을 설정합니다. 자세한 내용은 MySQL로 대체 구성을 참조하세요.

필요한 역할

컷오버를 수행하는 데 필요한 권한을 얻으려면 관리자에게 프로젝트에 대한 다음 IAM 역할 부여를 요청합니다.
- Cloud Spanner 데이터베이스 사용자 (roles/spanner.databaseUser)
- Dataflow 관리자 (roles/dataflow.admin)
- Datastream 관리자 (roles/datastream.admin)
- 스토리지 관리자 (roles/storage.admin)
- 모니터링 뷰어 (roles/monitoring.viewer)
- Pub/Sub 뷰어 (roles/pubsub.viewer)
- 뷰어 (roles/viewer)

컷오버 수행

다음 섹션에서는 애플리케이션 쓰기를 전환하기 전에 쓰기 파이프라인을 드레이닝하고 모든 소스 변경사항이 Spanner로 복제되는지 확인하는 방법을 설명합니다.

파이프라인 상태 및 DLQ 상태 확인

애플리케이션 쓰기 트래픽을 일시중지하거나 다운타임을 시작하기 전에 정방향 복제 파이프라인의 DLQ에 정체된 변경 이벤트가 없는지 확인합니다.

Google Cloud 콘솔에서 스트리밍 Dataflow 파이프라인의 작업 세부정보 페이지로 이동합니다.
커스텀 측정항목 탭에서 Total permanent errors 커스텀 카운터를 검사합니다.
이 카운터가 0보다 크면 Cloud Storage 심각한 DLQ 디렉터리 (예: gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/)를 확인하고 디렉터리가 비어 있는지 확인합니다.

참고: Total permanent errors 카운터는 누적되며 레코드가 재시도될 때 감소하지 않습니다. DLQ 디렉터리에 오류 파일이 있으면 컷오버를 진행하지 마세요. retryDLQ 일괄 작업을 사용하여 오류를 해결하고 레코드를 재생하는 방법에 대한 자세한 내용은 [CDC DLQ 오류 모니터링 및 해결](/spanner/docs/mysql-live-data-migration#resolve-cdc-dlq-errors)을 참조하세요.

애플리케이션 쓰기 일시중지

애플리케이션에서 모든 데이터베이스 쓰기 트래픽을 일시중지합니다.
소스 MySQL 기본 인스턴스에서 활성 트랜잭션을 완전히 커밋하고 드레이닝하도록 허용합니다.

Datastream 추적 및 일시중지

콘솔 Google Cloud 에서 스트림 의 스트림 세부정보 페이지로 이동합니다.
모니터링 탭에서 데이터 최신 상태 차트(Cloud Monitoring 측정항목 유형: datastream.googleapis.com/stream/freshness)를 검사합니다. 측정항목 값이 0으로 감소할 때까지 기다립니다. 이는 Datastream이 쓰기가 일시중지된 순간까지 모든 소스 데이터베이스 변경사항을 캡처하고 처리했음을 나타냅니다. 자세한 내용은 스트림 모니터링을 참조하세요.
복제 이벤트가 스트림을 통과하지 않는지 확인합니다. 모니터링 탭에서 처리량 차트 (모니터링 측정항목 유형: datastream.googleapis.com/stream/event_count)를 검사하고 이벤트 비율이 0인지 확인합니다.

또는 측정항목 탐색기를 사용하여 프로그래매틱 방식으로 확인하려면 Monitoring Query Language (MQL)를 사용하여 이벤트 수를 쿼리합니다.
```
fetch datastream.googleapis.com/Stream
| metric 'datastream.googleapis.com/stream/event_count'
| filter (resource.stream_id == 'STREAM_ID')
| align rate(1m)
| group_by [], [value_event_count_sum: sum(value.event_count)]
| every 1m
```
STREAM_ID를 스트림의 ID로 바꿉니다.

이 측정항목이 연속된 집계 기간 동안 0을 보고하는지 확인합니다.
Google Cloud 콘솔 또는 API를 사용하여 Datastream 스트림을 일시중지하고 스트림 상태가 to PAUSED로 변경될 때까지 기다립니다.

전송 중인 변경 데이터가 드레이닝될 때까지 기다리기

콘솔 Google Cloud 에서 스트림 의 스트림 세부정보 페이지로 이동합니다.
모니터링 탭에서 시스템 지연 시간 차트(모니터링 측정항목 유형: datastream.googleapis.com/stream/system_latencies)를 검사합니다.
99번째 백분위수 (P99) 지연 시간 값을 기록하고 스트림을 일시중지한 후 P99 시스템 지연 시간의 2배에 30초를 더한 시간 이상 기다립니다. 이 대기 기간은 일시중지 전에 생성된 모든 변경 데이터 파일이 Cloud Storage에 안전하게 기록되고 객체 생성 이벤트가 Pub/Sub에 게시되도록 하는 데 도움이 됩니다.
스트리밍 Dataflow 작업이 모든 대기 중인 변경 이벤트를 사용했는지 확인합니다. 콘솔 Google Cloud 에서 Pub/Sub **구독** 페이지로 이동한 후 CDC 마이그레이션 설정 중에 생성된 구독을 선택합니다.
모니터링 탭에서 승인되지 않은 메시지 수 차트 (모니터링 측정항목 유형: pubsub.googleapis.com/subscription/num_undelivered_messages)를 검사하고 개수가 0인지 확인합니다.

복제가 완료되었는지 확인

스트리밍 Dataflow 파이프라인이 복제된 모든 변경사항을 쓰는 작업을 완료했는지 확인합니다. 스트리밍 작업의 작업 세부정보 페이지에서 커스텀 측정항목 탭을 선택한 후 Replication lag total latency_MAX 사용자 카운터를 검사합니다. 카운터 값이 0에 도달할 때까지 기다립니다.

또는 측정항목 탐색기에서 MQL을 사용하여 사용자 카운터를 쿼리합니다.
```
fetch dataflow_job
| metric 'dataflow.googleapis.com/job/user_counter'
| filter (metric.job_id == 'JOB_ID' && metric.metric_name == 'Replication lag total latency_MAX')
| group_by 1m, [value_p99_latency: percentile(value.user_counter, 99)]
| every 1m
```
JOB_ID를 Dataflow 작업의 ID로 바꿉니다.
대상 Spanner 데이터베이스에서 쓰기 활동이 중지되었는지 확인합니다. 대상 데이터베이스의 데이터베이스 세부정보 페이지에서 모니터링 탭을 선택하고 쓰기 처리량 차트(모니터링 측정항목 유형: spanner.googleapis.com/transaction_stat/total/bytes_written_count)를 검사합니다. 쓰기 처리량이 연속된 1분 집계 기간 동안 0인지 확인합니다.
정방향 복제 DLQ의 최종 검사를 수행합니다. Cloud Storage에서 심각한 DLQ 디렉터리 및 재시도 DLQ 디렉터리 (예: gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/ 및 gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/retry/)를 검사하여 비어 있는지 확인합니다.
스트리밍 Dataflow 작업을 드레이닝합니다.
1. Google Cloud 콘솔에서 스트리밍 작업의 작업 세부정보 페이지로 이동합니다.
2. 작업 중지를 클릭하고 드레이닝을 선택한 후 작업 중지를 클릭합니다.
3. 작업 상태가 Drained로 변경될 때까지 기다립니다. 자세한 내용은 실행 중인 파이프라인 중지를 참조하세요.
드레이닝 후 DLQ 검증 수행: 작업 상태가 Drained로 변경된 후 Cloud Storage에서 심각한 DLQ 디렉터리 및 재시도 DLQ 디렉터리를 마지막으로 검사합니다. 전송 중인 데이터가 드레이닝되는 동안 새 오류 파일이 표시되지 않는지 확인합니다. 파일이 있으면 해결하고 재생합니다. 자세한 내용은 CDC DLQ 오류 모니터링 및 해결을 참조하세요.

애플리케이션 컷오버 수행

애플리케이션 데이터베이스 연결을 Spanner로 전환하고 라이브 읽기 및 쓰기 트래픽을 재개합니다.

Spanner 데이터베이스를 타겟팅하도록 애플리케이션 구성 또는 데이터베이스 연결 문자열을 업데이트합니다.
애플리케이션 서비스를 시작하고 Spanner에 대해 라이브 읽기 및 쓰기 트래픽이 성공적으로 실행되는지 확인합니다.
역방향 복제 파이프라인에서 오류를 모니터링합니다. Spanner 쓰기가 MySQL로 다시 복제되지 않으면 Dataflow는 실패한 레코드를 Cloud Storage의 DLQ 디렉터리 (예: gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/)에 저장합니다. 이 경로를 정기적으로 확인하여 비어 있는지 확인합니다. 실패한 레코드가 표시되면 역방향 복제 오류 모니터링 및 해결을 참조하세요.