오류 문제 해결하기
런타임 중에 이전 작업 프로세스에 오류가 발생할 수 있습니다.
- 소스 데이터베이스의 잘못된 비밀번호와 같은 일부 오류는 복구할 수 있으므로 수정할 수 있으며 마이그레이션 작업이 자동으로 재개됩니다.
- 바이너리 로그 위치 손실과 같이 복구할 수 없는 오류도 있습니다. 이 경우 마이그레이션 작업을 처음부터 다시 시작해야 합니다.
오류가 발생하면 이전 작업 상태가 Failed로 변경되고 하위 상태는 실패 전의 마지막 상태를 반영합니다.
오류를 해결하려면 실패한 이전 작업으로 이동하여 오류를 확인하고 오류 메시지에 설명된 단계를 따릅니다.
오류에 관한 자세한 내용을 보려면 이전 작업의 링크를 사용하여 Cloud Monitoring으로 이동하세요. 로그가 특정 이전 작업으로 필터링됩니다.
다음 표에서 문제의 예와 해결 방법을 확인할 수 있습니다.
| 문제 설명 | 문제 원인 | 해결 방법 |
|---|---|---|
| 대상 데이터베이스 설정은 데이터베이스를 프로비저닝하는 데 사용된 Terraform 구성과 다릅니다. 이 문제를 구성 드리프트라고도 합니다. | 기존 대상 데이터베이스로 마이그레이션하면 Database Migration Service는 마이그레이션 작업을 실행하기 위해 대상 데이터베이스의 특정 설정을 수정합니다. | 이전 작업을 승격한 후 Terraform 구성에 사용하는 설정을 다시 적용해야 합니다. Terraform 구성 드리프트를 참고하세요. |
오류 메시지: Error processing table {table_name}: MySQL Error 1118
(42000): Row size too large (>8126). |
VARCHAR 열을 사용하는 테이블에는 InnoDB(MySQL에서 사용되는 기본 스토리지 엔진)에서 허용하는 최대 크기를 초과하는 행이 있을 수 있습니다. |
열을 BLOB 또는 TEXT로 변환하거나
innodb_strict_mode 플래그를 일시적으로 off로 설정하여 마이그레이션 작업을 차단 해제할 수 있습니다.
오류 1118: 행 크기가 너무 큼을 참고하세요. |
전체 덤프 단계에서 다음 오류 메시지와 함께 이전 작업이 실패했습니다.ERROR 1064 (42000) at {line_number}: You have an error in your
SQL syntax; check the manual that corresponds to your MySQL server version for
the right syntax to use near {reserved_word} at {line_number}.
|
이 문제는 MySQL 버전 간에 이전할 때 발생합니다.
소스 MySQL 버전의 항목에 이전하려는 MySQL 버전에서 허용되지 않는 단어가 사용되었을 수 있습니다.
예를 들어 MySQL 5.7에서는 열 이름에 |
오류 메시지에 참조된 소스 데이터베이스 객체의 이름을 바꾸거나 백틱 (``)으로 묶어 구문을 이스케이프합니다. 완료되면 마이그레이션 작업을 다시 시도합니다.
|
오류 메시지: ERROR 1109 (42S02): Unknown table in <schema name here> |
Database Migration Service는 mysql, performance_schema, information_schema, ndbinfo 또는 sys 시스템 스키마를 이전하지 않습니다.
소스 데이터베이스에 이러한 스키마의 테이블을 참조하는 객체가 포함되어 있으면 마이그레이션 작업이 실패할 수 있습니다. |
소스 데이터베이스에서 이전되지 않은 시스템 스키마에 포함된 테이블을 참조하는 객체가 있는지 확인합니다. 오류 1109 (42S02): <여기에 스키마 이름>에 알 수 없는 테이블이 있습니다를 참고하세요. |
오류 메시지: Unknown table 'COLUMN_STATISTICS' in information_schema (1109) |
mysqldump만 있는 수동 데이터베이스 덤프 시나리오와 관련이 있습니다.8 미만 버전의 MySQL 데이터베이스에는 COLUMN_STATISTICS 테이블이 없습니다. 버전 8 이상에서는 |
mysqldump를 사용할 때 --column-statistics=0 플래그를 사용합니다. |
오류 메시지: Specified key was too long; max key length is 767 bytes. |
소스 데이터베이스 인스턴스에는 innodb_large_prefix 변수가 설정되어 있을 수 있습니다. |
대상 인스턴스를 만들 때 ON으로 innodb_large_prefix 플래그를 설정하거나 기존 대상 인스턴스를 플래그로 업데이트합니다. |
오류 메시지: Table definition has changed. |
덤프 프로세스 중에 데이터 정의 언어(DDL)가 변경되었습니다. | 덤프 프로세스 중에 DDL 변경을 방지합니다. |
오류 메시지: Access denied; you need (at least one of) the SUPER privilege(s) for this operation. |
소스 데이터베이스에 super user@localhost (예: root@localhost)를 사용하는 이벤트, 뷰, 함수, 프로시저가 있을 수 있습니다. 이는 Cloud SQL에서는 지원되지 않습니다. | Cloud SQL의 DEFINER 사용에 대한 자세한 정보를 참고하세요. |
오류 메시지: Definer user 'x' does not exist. Please create the user on the replica.
|
복제본에 사용자가 없습니다. | Cloud SQL의 DEFINER 사용에 대한 자세한 정보를 참고하세요. |
오류 메시지: ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost. |
소스 데이터베이스에 복제본에 없는 DEFINER가 있습니다. |
Cloud SQL의 DEFINER 사용에 대한 자세한 정보를 참고하세요. |
오류 메시지: Lost connection to MySQL server during query when dumping table. |
소스 데이터베이스에 연결할 수 없거나 덤프에 너무 큰 패킷이 포함되어 있을 수 있습니다. | 이러한 방법을 시도해 보세요. |
오류 메시지: Got packet bigger than 'max_allowed_packet' bytes when dumping table. |
패킷이 설정에서 허용하는 것보다 큽니다. | max_allowed_packet 옵션으로 수동 덤프를 사용합니다. |
| 초기 데이터 마이그레이션이 성공했지만 복제 중인 데이터가 없습니다. | 충돌하는 복제 플래그가 있을 수 있습니다. | 이러한 플래그 설정을 확인하세요. |
| 초기 데이터 마이그레이션에 성공했지만 얼마 후 데이터 복제가 더 이상 작동하지 않습니다. | 여러 가지 원인이 있을 수 있습니다. | 이러한 방법을 시도해 보세요. |
오류 메시지: mysqld check failed: data disk is full. |
대상 인스턴스의 데이터 디스크가 가득 찼습니다. | 대상 인스턴스의 디스크 크기를 늘립니다. 수동으로 디스크 크기를 늘리거나 스토리지 자동 증가를 사용 설정할 수 있습니다. |
| 소스 데이터베이스 인스턴스에 연결하지 못했습니다. | 소스 데이터베이스 인스턴스와 대상 인스턴스 간에 연결 문제가 있습니다. | 연결 디버깅 도움말의 단계를 따르세요. |
| 관리형 데이터베이스 (Amazon RDS/Aurora)에서 마이그레이션이 시작되지 않습니다. | SUPERUSER 권한이 없는 관리형 소스 데이터베이스에서 마이그레이션하는 경우 마이그레이션 시작 시 잠시 다운타임이 발생합니다. | 이 도움말의 단계를 따르세요. |
| 바이너리 로그가 소스 데이터베이스에서 잘못 구성됨 | 바이너리 로그 정의가 잘못되었습니다. | 연속 MySQL 마이그레이션 작업의 경우 필수 binlog 정의를 따르세요. |
| 덤프 파일을 찾을 수 없습니다. | DMS에서 제공된 덤프 파일을 찾을 수 없습니다. | 이는 이전 작업에서 지정된 위치에서 덤프 파일을 찾을 수 없는 경우 발생할 수 있습니다.
|
| 바이너리 로그 위치가 손실되어 복제를 재개할 수 없음 | 바이너리 로그 위치가 손실되어 마이그레이션 작업을 재개할 수 없습니다. | 이 오류는 복제 프로세스가 장시간 일시중지되어 바이너리 로그 위치가 손실될 때 발생할 수 있습니다. 바이너리 로그 보관 기간에 근접한 기간 동안 마이그레이션 작업을 일시중지하면 안 됩니다. 이전 작업을 다시 시작합니다. |
기존 대상 인스턴스로 이전하면 다음과 같은 오류 메시지가 표시됩니다.
The destination instance contains existing data or user defined
entities (for example databases, tables, or functions). You can only
migrate to empty instances. Clear your destination instance and retry
the migration job.
|
대상 Cloud SQL 인스턴스에 추가 데이터가 포함되어 있습니다. 비어 있는 기존 인스턴스로만 이전할 수 있습니다. 알려진 제한사항을 참고하세요. | 대상 인스턴스를 읽기/쓰기 인스턴스로 승격하고, 추가 데이터를 삭제한 후, 마이그레이션 작업을 다시 시도합니다. 기존 대상 인스턴스에서 추가 데이터 삭제를 참고하세요. |
| 소스 및 대상 데이터베이스 버전이 호환되지 않아 마이그레이션 작업을 실행할 수 없음 | 제공된 소스 데이터베이스 버전이 대상 데이터베이스 버전과 호환되지 않습니다. | 대상 데이터베이스 버전이 소스 대상 버전과 동일하거나 한 단계 상위의 주 버전인지 확인한 후 새 이전 작업을 만듭니다. |
오류 메시지: Unable to connect to source database server.
|
Database Migration Service에서 소스 데이터베이스 서버에 연결할 수 없습니다. | 소스 및 대상 데이터베이스 인스턴스가 서로 통신할 수 있고 마이그레이션 작업의 설정을 정의할 때 표시된 모든 필수 기본 요건을 완료했는지 확인합니다. |
오류 메시지: Timeout waiting for no write traffic on source.
|
SUPERUSER 권한이 없는 관리형 소스 데이터베이스에서 마이그레이션하면 마이그레이션 시작 시 잠시 다운타임이 발생합니다. |
SUPERUSER 권한 없이 RDS MySQL에서 마이그레이션의 단계를 따릅니다. |
오류 메시지: ERROR 1146 (42S02) at line {line_number}: Table '{table_name}' doesn't exist.
|
소스 데이터베이스의 lower_case_table_names 플래그 값과 대상 Cloud SQL 인스턴스의 플래그 값 간에 불일치가 있을 수 있습니다. |
Cloud SQL 인스턴스의 플래그 값을 소스 데이터베이스의 플래그 값과 일치하도록 설정합니다. |
오류 메시지: ERROR 1109 (42S02) at line {line_number}: Unknown table '{table}' in {database}.
|
소스 데이터베이스의 일부 객체(예: 뷰, 함수, 저장 프로시저, 트리거)가 데이터베이스에 더 이상 존재하지 않는 테이블을 참조합니다. | 이러한 객체가 있는지 확인합니다. 참조하는 테이블이 있는 경우 소스 데이터베이스에서 객체를 삭제하거나 객체가 참조하는 테이블을 소스 데이터베이스에 추가합니다. |
오류 메시지: ERROR 1045: Access denied for user '{user_name}'@'{replica_IP}' (using password: YES)". Check if MySQL replication user and password are correct. Not attempting further retries. |
소스 인스턴스에 잘못된 비밀번호를 입력했습니다. 또는 소스 인스턴스에서 SSL 연결을 강제하지만 이전 작업이 SSL 인증을 사용하도록 구성되지 않았습니다. |
소스 인스턴스가 Cloud SQL인 경우 SSL/TLS 필요를 참고하여 TCP 연결에 SSL/TLS가 필요한지 확인합니다. |
| 복제 지연 시간이 지속적으로 높습니다. | 쓰기 부하가 너무 높아 복제본이 처리할 수 없습니다. 복제 지연은 복제본의 MySQL용 Cloud SQL 스레드가 I/O 스레드를 따라잡을 수 없는 경우 발생합니다. 일부 유형의 쿼리 또는 워크로드로 인해 특정 스키마에서 일시적이거나 영구적인 복제 지연이 발생할 수 있습니다. 복제 지연이 발생하는 일반적인 원인은 다음과 같습니다.
|
가능한 솔루션은 다음과 같습니다.
|
오류 메시지: 'Character set '#255' is not a compiled character set and is not specified in the '/usr/share/mysql/charsets/Index.xml' file' on query. |
소스 데이터베이스에서 선택한 Cloud SQL 복제본에서 지원되지 않는 문자 집합 또는 컬러레이션을 사용할 수 있습니다. MySQL 5.7과 호환되는 AWS Aurora 버전 2.x가 한 가지 예입니다. 그러나 이 버전은 MySQL용 Cloud SQL 5.7에서 지원되지 않는 utf8mb4_0900_as_ci 정렬을 지원합니다. |
|
오류 1108: 행 크기가 너무 큼
가변 길이 문자열을 저장하는 열이 있는 테이블에는 기본 InnoDB 최대 행 크기를 초과하는 행이 있을 수 있습니다.해결 방법
소스 테이블 스키마 조정
이 문제는 최대 크기 행 한도를 초과하는 테이블에 INSERT 문을 실행할 때마다 다시 발생할 수 있습니다. 향후 문제를 방지하려면 이전을 다시 시도하기 전에 테이블을 조정하는 것이 가장 좋습니다.
- 다음 쿼리를 실행하여 테이블
ROW_FORMAT를DYNAMIC또는COMPRESSED로 변경합니다.ALTER TABLE TABLE_NAME ROW_FORMAT=FORMAT_NAME;
- TABLE_NAME은 행이 최대 행 크기 제한을 초과하는 테이블의 이름입니다.
- FORMAT_NAME은
DYNAMIC또는COMPRESSED입니다.
ALTER TABLE mytable ROW_FORMAT=DYNAMIC;
- 행 데이터를 BLOB 또는 TEXT로 변환합니다. 이 작업을 실행하는 한 가지 방법은
CONVERT()함수를 사용하는 것입니다.
InnoDB 엄격 모드 사용 중지
소스 테이블 스키마를 조정할 수 없는 경우 InnoDB 유효성 검사를 일시적으로 사용 중지하여 이전 작업을 완료할 수 있습니다. 향후 데이터베이스 쓰기 시도 중에 이 문제가 다시 발생할 수 있으므로 가능하면 테이블 스키마를 조정하는 것이 좋습니다.
마이그레이션 작업을 완료하기 위해 일시적으로 InnoDB 유효성 검사를 사용 중지하려면 다음 단계를 따르세요.
| If... | 그런 다음... |
|---|---|
| 새 대상 인스턴스로 이전하는 경우 |
|
| 기존 대상 인스턴스로 이전하는 경우 |
|
기존 대상 인스턴스에서 추가 데이터 삭제
기존 대상 인스턴스로 이전하면 다음과 같은 오류 메시지가 표시됩니다.
The destination instance contains existing data or user defined
entities (for example databases, tables, or functions). You can only
migrate to empty instances. Clear your destination instance and retry
the migration job.
이 문제는 대상 인스턴스에 추가 데이터가 포함되어 있을 때 발생할 수 있습니다. 비어 있는 기존 인스턴스로만 이전할 수 있습니다. 알려진 제한사항을 참고하세요.
해결 방법
다음 단계를 수행하여 대상 인스턴스에서 추가 데이터를 삭제하고 마이그레이션 작업을 다시 시작합니다.
- 마이그레이션 작업을 중지합니다.
- 이 시점에서 대상 Cloud SQL 인스턴스는
read-only모드입니다. 대상 인스턴스를 승격하여 쓰기 액세스 권한을 얻습니다. - 대상 Cloud SQL 인스턴스에 연결합니다.
- 대상 인스턴스 데이터베이스에서 추가 데이터를 삭제합니다. 대상에는 시스템 구성 데이터만 포함할 수 있습니다. 대상 데이터베이스에는 사용자 데이터 (예: 테이블)가 포함될 수 없습니다. 데이터베이스에서 실행하여 시스템 외 데이터를 찾을 수 있는 다양한 SQL 문이 있습니다. 예를 들면 다음과 같습니다.
SELECT schema_name FROM information_schema.SCHEMATA WHERE schema_name NOT IN ('information_schema', 'sys', 'performance_schema', 'mysql');
- 마이그레이션 작업을 시작합니다.
Terraform 구성 변경
기존 대상 데이터베이스로 마이그레이션하면 Database Migration Service는 마이그레이션 작업을 실행하기 위해 대상 데이터베이스의 특정 설정을 수정합니다. Terraform으로 프로비저닝된 데이터베이스의 경우 이 상호작용으로 인해 실제 대상 데이터베이스 구성이 Terraform 파일에 설정된 구성과 다를 수 있습니다.해결 방법
이전 작업이 실행 중일 때 Terraform 구성을 다시 적용하려고 하지 마세요. 대상 데이터베이스가 승격된 후 필요한 구성을 안전하게 조정할 수 있습니다. Database Migration Service는 대상 Cloud SQL 인스턴스에 다음과 같은 수정사항을 적용합니다.- 백업 구성이 기본값으로 설정됩니다.
- PITR(포인트 인 타임 리커버리)이 기본값으로 재설정됩니다.
오류 1109 (42S02): <여기에 스키마 이름>에 알 수 없는 테이블이 있습니다.
마이그레이션 작업이 다음 메시지(예: ERROR 1109 (42S02) at line X: Unknown table 'GLOBAL_STATUS' in information_schema)와 함께 실패합니다.ERROR 1109 (42S02): Unknown table in <schema name here>
문제 원인
Database Migration Service는 mysql, performance_schema, information_schema, ndbinfo 또는 sys 시스템 스키마를 이전하지 않습니다(
알려진 제한사항 참고).
소스 데이터베이스에 이러한 스키마의 테이블을 참조하는 객체가 포함되어 있으면 마이그레이션 작업이 실패할 수 있습니다.
해결 방법
소스 데이터베이스에서 시스템 스키마의 테이블을 참조하는 객체를 확인합니다. 소스 데이터베이스에서 다음 쿼리를 실행합니다.# Query to check routines or functions definitions. SELECT ROUTINE_SCHEMA, ROUTINE_NAME FROM information_schema.routines WHERE ROUTINE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys') AND ROUTINE_DEFINITION like '%OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE%' # Query to check view definitions. SELECT TABLE_SCHEMA, TABLE_NAME FROM information_schema.views WHERE TABLE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys') AND view_definition like '%OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE%' # Query to check trigger definitions. SELECT TRIGGER_SCHEMA, TRIGGER_NAME FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys') AND event_object_table = 'OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE' # Query to check constraint definitions. SELECT TABLE_SCHEMA, TABLE_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys') AND REFERENCED_TABLE_NAME = 'OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE'
information_schema에 알 수 없는 테이블 'COLUMN_STATISTICS'
mysqldump 유틸리티 버전 8 이상을 실행하여 8 미만의 MySQL 데이터베이스 버전을 내보내면 Unknown table 'COLUMN_STATISTICS' in information_schema (1109) 오류가 발생합니다.
문제 원인
8 미만 버전의 MySQL 데이터베이스에는 COLUMN_STATISTICS 테이블이 없습니다. 버전 8 이상에서는 mysqldump 유틸리티가 기본적으로 이 표를 내보내려고 시도합니다. 열이 없으므로 내보내기가 실패합니다.
해결 방법
mysqldump 명령어에 --column-statistics=0 플래그를 추가하여 내보내기에서 COLUMN_STATISTICS 테이블을 삭제합니다. 자세한 내용은 mysqldump를 사용하여 MySQL 데이터베이스 내보내기를 참고하세요.
지정된 키가 너무 깁니다. 최대 키 길이는 767바이트입니다.
Specified key was too long; max key length is 767 bytes. 오류가 표시됩니다.
문제 원인
소스 데이터베이스에 innodb_large_prefix 변수가 설정되어 있을 수 있습니다. 이렇게 하면 767바이트보다 긴 색인 키 접두사가 허용됩니다. MySQL 5.6의 기본값은 OFF입니다.
해결 방법
대상 데이터베이스를 만들 때 innodb_large_prefix 플래그를 ON로 설정하거나 기존 대상 데이터베이스를 플래그로 업데이트합니다.
테이블 정의가 변경됨
Table definition has changed 오류가 표시됩니다.
문제 원인
덤프 프로세스 중에 DDL이 변경되었습니다.
해결 방법
덤프 프로세스 중에 테이블을 수정하거나 다른 DDL 변경을 수행하지 마세요.스크립트를 사용하여 DDL 작업이 중지되었는지 확인할 수 있습니다.
액세스 거부됨. 이 작업에 대한 SUPER 권한(하나 이상)이 필요합니다.
Access denied; you need (at least one of) the SUPER privilege(s) for this operation 오류가 표시됩니다.
문제 원인
소스 데이터베이스에 super user@localhost (예: root@localhost)를 사용하는 이벤트, 뷰, 함수, 프로시저가 있을 수 있습니다. 이는 Cloud SQL에서는 지원되지 않습니다.
해결 방법
DEFINER 절이 있는 데이터베이스 마이그레이션에 대한 자세한 내용은 이 문서를 참고하세요.
오류 메시지: Definer user 'x' does not exist. Please create the user on the replica.
Definer user 'x' does not exist. Please create the user on the replica. 오류가 표시됩니다.
문제 원인
근본 원인은 DEFINER 절이 있는 소스 데이터베이스의 사용자가 복제본 데이터베이스에 존재하지 않기 때문입니다.
해결 방법
DEFINER 절이 있는 데이터베이스 마이그레이션에 대한 자세한 내용은 이 문서를 참고하세요. 복제본 데이터베이스에 사용자를 만들어야 할 수도 있습니다.
오류 메시지: ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost
ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost 오류가 표시됩니다.
문제 원인
근본 원인은 DEFINER 절이 있는 소스 데이터베이스의 사용자가 복제본 데이터베이스에 존재하지 않는데 해당 사용자가 소스 데이터베이스의 객체 정의에서 상호 참조된다는 점입니다.
해결 방법
DEFINER 절이 있는 데이터베이스 마이그레이션에 대한 자세한 내용은 이 문서를 참고하세요. 복제본 데이터베이스에 하나 이상의 사용자를 만들어야 할 수 있습니다.
테이블을 덤프할 때 쿼리 중에 MySQL 서버와의 연결이 끊어졌습니다.
Lost connection to MySQL server during query when dumping table 오류가 표시됩니다.
문제 원인
- 대상 인스턴스에서 소스 데이터베이스 인스턴스에 연결할 수 없게 되었을 수 있습니다.
- 소스 데이터베이스에는 소스 데이터베이스에서
max_allowed_packet을 더 큰 수로 설정해야 하는 큰 blob 또는 긴 문자열이 있는 테이블이 있을 수 있습니다.
해결 방법
- 소스 데이터베이스 인스턴스가 작동 중이고 연결 가능한지 확인합니다.
- 마이그레이션 작업에서
max-allowed-packet플래그를 구성한 후 마이그레이션 작업을 다시 시작합니다. 또는max_allowed_packet옵션으로 수동 덤프 를 생성하여 데이터를 덤프하고 덤프 파일로 마이그레이션합니다. max_allowed_packet를 늘리려면 소스 데이터베이스의net_read_timeout및net_write_timeout설정을 조정해야 할 가능성이 큽니다 (일반적으로 연결 오류가 중지될 때까지 늘려야 함).
테이블을 덤프할 때 'max_allowed_packets' 바이트보다 큰 패킷이 있습니다.
Got packet bigger than 'max_allowed_packet' bytes when dumping table 오류가 표시됩니다.
문제 원인
패킷이 설정에서 허용하는 것보다 큽니다.
해결 방법
max_allowed_packet 옵션과 함께 수동 덤프를 사용하여 마이그레이션 작업을 만들고 데이터를 덤프한 후 덤프 파일로 마이그레이션합니다.
복제되는 데이터가 없음
초기 데이터 마이그레이션이 성공했지만 복제 중인 데이터가 없습니다.
문제 원인
한 가지 가능한 근본 원인은 소스 데이터베이스에서 복제 플래그를 정의하여 일부 또는 전체 데이터베이스 변경사항이 복제되지 않기 때문일 수 있습니다.
해결 방법
binlog-do-db, binlog-ignore-db, replicate-do-db, replicate-ignore-db와 같은 복제 플래그가 충돌 방식으로 설정되어 있지 않은지 확인합니다.
소스 데이터베이스에서 show master status 명령어를 실행하여 현재 설정을 확인합니다.
초기 데이터 마이그레이션에 성공했지만 얼마 후 데이터 복제가 더 이상 작동하지 않습니다.
초기 데이터 마이그레이션에 성공했지만 얼마 후 데이터 복제가 더 이상 작동하지 않습니다.
문제 원인
이 문제의 근본 원인은 여러 가지가 있을 수 있습니다.
해결 방법
- Cloud Monitoring UI에서 대상 인스턴스의 복제 측정항목을 확인합니다.
- MySQL IO 스레드 또는 SQL 스레드의 오류는 mysql.err 로그 파일의 Cloud Logging에서 확인할 수 있습니다.
- 이 오류는 대상 인스턴스에 연결할 때도 찾을 수 있습니다.
SHOW REPLICA STATUS명령어를 실행하고 출력에서 다음 필드를 확인합니다.- Replica_IO_Running
- Replica_SQL_Running
- Last_IO_Error
- Last_SQL_Error
참고:
SHOW REPLICA STATUS는 MySQL 8.0.22에서 도입된 별칭입니다. 이전 버전 (MySQL 5.7, MySQL 8.0)의 경우 status 명령어의 이전 별칭을 사용합니다. 자세한 내용은 MySQL 문서의 상태 문을 참고하세요.fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file' in Last_IO_Error오류가 발생한 경우 소스 인스턴스의 바이너리 로그 보관 설정이 충분하지 않기 때문일 수 있습니다.error connecting to master 'USER_NAME@SOURCE_HOST:SOURCE_PORT' - retry-time: RETRY_TIME retries: RETRIES오류가 발생한 경우 연결 또는 인증 문제로 인해 대상 인스턴스가 소스에 다시 연결되지 않았기 때문일 수 있습니다.
mysqld 확인 실패: 데이터 디스크가 가득 찼습니다.
mysqld check failed: data disk is full 오류가 표시됩니다.
문제 원인
대상 인스턴스의 데이터 디스크가 가득 찬 것일 수 있습니다.
해결 방법
대상 인스턴스의 디스크 크기를 늘립니다.
소스 데이터베이스 연결 실패
소스 데이터베이스 연결 실패
문제 원인
소스 데이터베이스 인스턴스와 대상 인스턴스 간에 연결 문제가 있습니다.
해결 방법
연결 디버깅 도움말의 단계를 따르세요.
관리형 데이터베이스 (Amazon RDS/Aurora)에서 마이그레이션이 시작되지 않음
이전 작업이 시작되지 않습니다.
문제 원인
SUPERUSER 권한이 없는 관리형 소스 데이터베이스에서 마이그레이션하려면 마이그레이션 시작 시 잠시 다운타임이 필요합니다.
해결 방법
바이너리 로그가 소스 데이터베이스에서 잘못 구성됨
바이너리 로그에 문제가 있음을 나타내는 오류가 표시됩니다.
문제 원인
소스 데이터베이스에서 바이너리 로그 구성이 잘못된 경우 지속적인 MySQL 마이그레이션 작업에서 이러한 오류가 발생할 수 있습니다.
해결 방법
여기에 나온 정의를 따르세요.
제공된 덤프 파일을 읽을 수 없음
덤프 파일에 문제가 있음을 나타내는 오류가 표시됩니다.
문제 원인
DMS에서 제공된 덤프 파일을 찾을 수 없습니다.
해결 방법
- 덤프 경로를 확인하여 올바른 파일이 있는지 확인하거나 경로를 변경합니다.
- 경로를 변경하는 경우
PATCH요청을 사용하여 작업에서 경로를 사용하도록 합니다. - 이전 작업을 다시 시작합니다.
바이너리 로그 위치가 손실되어 복제를 재개할 수 없음
바이너리 로그 위치가 손실되었습니다.
문제 원인
이 오류는 복제 프로세스가 장시간 일시중지되어 바이너리 로그 위치가 손실될 때 발생할 수 있습니다. 바이너리 로그 보관 기간에 근접한 기간 동안 마이그레이션 작업을 일시중지하면 안 됩니다.
해결 방법
이전 작업을 다시 시작합니다.
소스 및 대상 데이터베이스 버전이 호환되지 않아 마이그레이션 작업을 실행할 수 없음
소스 및 대상 데이터베이스 버전이 지원되지 않는 조합입니다.
문제 원인
제공된 소스 데이터베이스 버전이 대상 데이터베이스 버전과 호환되지 않습니다.
해결 방법
대상 데이터베이스 버전이 소스 대상 버전과 동일하거나 한 단계 상위의 주 버전인지 확인한 후 새 이전 작업을 만듭니다.
소스 데이터베이스 서버에 연결할 수 없음
Unable to connect to source database server 오류가 표시됩니다.
문제 원인
Database Migration Service에서 소스 데이터베이스 서버에 연결할 수 없습니다.
해결 방법
소스 및 대상 데이터베이스 인스턴스가 서로 통신할 수 있는지 확인합니다. 그런 다음 이전 작업의 설정을 정의할 때 표시된 필수 기본 요건을 모두 완료했는지 확인합니다.
Cloud SQL 대상 인스턴스 디스크 사용량이 0으로 감소함
이전 중에 디스크 사용량이 갑자기 0으로 떨어집니다.
문제 원인
전체 덤프 데이터를 가져올 때 실패할 수 있습니다. 이 경우 이전 프로세스가 데이터를 다시 로드하려고 시도합니다. 이 프로세스는 먼저 대상 인스턴스의 기존 데이터를 삭제한 후 (디스크 사용량이 0으로 표시되는 이유) 데이터를 다시 로드하려고 시도합니다.
해결 방법
로그 탐색기로 이동하여 리소스 목록에서 대상 인스턴스를 선택합니다.
다음과 유사한 로그 메시지를 찾습니다.
DUMP_STAGE(RETRY): Attempt .../...: import failed: error..."; Clearing database and trying again."
import failed: 텍스트 뒤에 있는 메시지를 찾아 근본 원인을 해결해 보세요.