Cloud SQL에서 MySQL로 마이그레이션하는 방법에는 여러 가지가 있습니다. 특정 소스의 마이그레이션 전략은 데이터베이스 크기, 예상 다운타임, 마이그레이션을 수행하는 엔지니어의 경험을 포함한 여러 가지 요소에 따라 달라집니다. 가장 일반적인 마이그레이션 전략을 살펴보겠습니다.

크기가 몇 기가바이트에 불과하거나 정적 데이터가 포함된 소규모 데이터베이스를 마이그레이션하는 경우 가장 쉬운 방법은 mysqldump 유틸리티를 사용하여 데이터베이스 덤프를 사용하는 것입니다. SQL 덤프 파일을 사용하여 내보내기 및 가져오기 문서의 안내에 따라 덤프 파일을 Cloud Storage에 업로드하고 Cloud SQL 인스턴스로 가져옵니다.

덤프 파일에는 논리적 SQL 문이 포함되므로 이 방법의 한 가지 이점은 덤프 파일을 Cloud Storage에 로드하기 전에 수정할 수 있다는 점입니다. 하지만 특정 Cloud SQL 제한사항에 따라 데이터 가져오기 및 내보내기 권장사항에 나열된 대로 가져오기를 중단할 수 있는 항목을 덤프 파일에 포함하지 않아야 합니다.

많은 MySQL 인스턴스를 마이그레이션하거나 대규모 마이그레이션을 수행할 때는 Database Migration Service(DMS)를 사용하는 것이 좋습니다. 이 서비스는 MySQL로의 동종 및 이기종 마이그레이션 경로를 포함한 다양한 마이그레이션 경로를 제공하고 마이그레이션 대상으로 SQL Server와 PostgreSQL을 지원하는 서비스입니다.

대부분의 중간 규모 및 대규모 데이터베이스 마이그레이션에는 DMS 사용만으로 충분합니다. DMS가 적절하지 않을 수 있는 상황으로는 데이터베이스가 매우 크거나(예: 크기가 몇 TB인 데이터베이스) 복제 노하우가 있는 MySQL 엔지니어가 기본 MySQL 복제를 사용하는 마이그레이션 프로세스를 보다 세밀하게 제어하는 것을 선호하는 경우가 해당됩니다.

마이그레이션 중에 다운타임 최소화가 가장 중요하며 팀에 숙련된 MySQL 엔지니어가 있으면 기본 바이너리 로그 기반 복제를 사용하여 외부 소스(ES)에서 복제할 수 있습니다. 이 방법에서는 Cloud Storage 가져오기와 같은 방법을 사용하여 데이터베이스의 기준 스냅샷을 가져옵니다.

그런 다음 Cloud SQL 인스턴스에서 이미 사용할 수 있는 미리 만든 저장 프로시저 집합을 사용하여 소스 인스턴스에서 대상 Cloud SQL 인스턴스로 MySQL 복제를 구성합니다. 자세한 안내는 커스텀 가져오기를 사용하여 대규모 외부 데이터베이스에서 복제 설정 문서를 참조하세요.

마이그레이션에 바이너리 로그 기반 복제를 사용할 때의 한 가지 주요 세부정보는 소스 인스턴스의 바이너리 로그를 더 이상 대상 Cloud SQL 인스턴스에서 필요하지 않을 때까지 계속 사용할 수 있다는 점입니다. MySQL 온프레미스 또는 자체 관리형을 실행하는 경우 바이너리 로그 삭제를 제어하도록 expire_logs_days와 같은 매개변수를 구성할 수 있습니다. 하지만 다른 클라우드 공급업체 관리형 서비스에는 바이너리 로그 보관에 대한 고유한 제한사항이 있습니다.

예를 들어 Amazon Relational Database Service(RDS)를 사용하면 mysql.rds_set_configuration라는 저장 프러시저를 사용하여 바이너리 로그 보관을 구성할 수 있습니다. 이렇게 하면 최대 7일 동안 보관할 수 있습니다. 대부분의 경우 RDS에서 Cloud SQL로의 중소 규모 마이그레이션에는 7일이면 충분합니다. 이러한 경우 사용자는 관리형 RDS 복제본을 만드는 과정이 잘 문서화된 프로세스를 활용할 수 있습니다. 그런 다음 복제본을 쓰기 가능하게 만들어 행을 삭제하거나 바이너리 로그로 들어가서 복제를 중단시키는 일종의 '포이즌필' 트랜잭션을 삽입하는 등 복제를 '중단'하기 위한 작업을 수행합니다. 복제본에 바이너리 로그가 계속 필요한 경우에는 RDS 자동화에서 바이너리 로그를 삭제하지 않습니다. 단, RDS가 손상된 복제 스트림을 '종료'하기 전의 전체 한도는 30일인 것으로 보입니다.

또 다른 해결 방법은 mysqlbinlog 클라이언트를 사용하여 바이너리 로그를 다른 중개 MySQL 인스턴스에 다운로드하여 바이너리 로그가 조기에 삭제되지 않도록 하는 것입니다. 예를 들어 RDS에는 바이너리 로그가 다운로드할 수 있도록 충분히 호스트에 남아 있도록 보관 기간을 시간 단위로 설정할 수 있는 mysql.rds_set_configuration이라는 저장 프러시저가 있습니다. 이 경우 MySQL 인스턴스처럼 보이는 'Binlog Server'와 같은 서버에서 바이너리 로그를 저장하고 전달하므로 MySQL 인스턴스를 중개자로 구현하지 않아도 됩니다.

MySQL은 여러 플러그인 가능한 스토리지 엔진을 지원한다는 점에서 가장 많이 사용되고 있는 관계형 데이터베이스 시스템 중에서 고유합니다. 원래 MySQL은 MyISAM이라는 단일 스토리지 엔진을 지원했으며 MySQL 8.0까지는 대부분의 시스템 테이블에서 이 스토리지 엔진을 사용했습니다. 하지만 MyISAM은 트랜잭션을 지원하지 않았으며 갑작스러운 시스템 종료나 데이터베이스 비정상 종료 발생 시 비정상 종료로부터 안전하지 않았습니다.

그 이후로 InnoDB는 비정상 종료로부터 안전한 아키텍처와 트랜잭션 지원 기능으로 인해 사실상 대부분의 MySQL 사용자 테이블의 스토리지 엔진이 되었습니다. 여전히 MySQL 커뮤니티에는 온프레미스와 기타 클라우드 제공업체 모두에서 일반적으로 볼 수 있는 다른 스토리지 엔진이 있으며 다음과 같습니다.

• ARCHIVE - 보관처리 목적으로 고도로 압축된 형식으로 데이터를 저장합니다.
• CSV - 쉼표로 구분된 형식(CSV)으로 데이터를 저장하고 일반 및 느린 쿼리 로그의 테이블 로깅에 사용됩니다.
• MEMORY - 테이블을 메모리에 저장합니다.

Cloud SQL의 경우 복제 및 PITR(point-in-time recovery)과 같은 부가 가치 기능을 지원하기 위해 비정상 종료로부터 안전한 트랜잭션 스토리지 엔진이 필요합니다. 따라서 Cloud SQL로 마이그레이션하는 모든 사용자 테이블은 InnoDB 스토리지 엔진을 사용하거나 마이그레이션 프로세스 중에 InnoDB로 전환되어야 합니다.

이는 외부 소스에서 Cloud SQL로의 기본 MySQL 복제를 수행하는 경우에 특히 중요합니다. Cloud SQL에서는 사용자가 CREATE TABLE과 같은 데이터 정의 언어(DDL) 명령어를 사용하여 Cloud SQL 인스턴스에서 직접 MyISAM 테이블을 만들 수 없지만 현재 MyISAM 테이블을 외부 소스에서 Cloud SQL로 복제할 수 있습니다.

하지만 Cloud SQL에서 가져온 이러한 MyISAM 테이블은 나중에 복제, PITR(point-in-time recovery), 장애 조치와 같은 작업 중에 안정성 및 신뢰성 문제로 이어질 수 있습니다. 이러한 이유로 마이그레이션을 수행하기 전에 모든 MyISAM 사용자 테이블을 InnoDB로 변환하는 것이 좋습니다. 

다음 쿼리는 시스템 이외의 모든 MyISAM 테이블을 나열합니다.

관리형 서비스인 Cloud SQL용 MySQL에서는 사용자 계정에 SUPER 권한을 허용하지 않습니다. 이는 이러한 권한이 있는 루트 사용자에 허용되는 대부분의 MySQL 온프레미스 설치와 다릅니다. 마찬가지로 다른 대부분의 클라우드 제공업체는 관리형 MySQL 환경에서 이 SUPER 권한을 제공하지 않습니다.

어떤 경우든 Cloud SQL 사용자는 FILE 및 SHUTDOWN과 함께 앞서 언급된 SUPER와 같이 서비스를 관리하는 Google 기능에 영향을 미치는 권한을 제외하고 MySQL에서 제공하는 대부분의 권한을 부여하는 ‘root’@’%’라는 기본 MySQL 사용자를 수신합니다. Cloud SQL에서 제공하는 사용 권한에 대한 자세한 내용은 MySQL 사용자에 대한 문서를 참조하세요.

마이그레이션을 준비할 때 소스 인스턴스의 모든 사용자 계정을 검토합니다. 예를 들어 사용자마다 SHOW GRANTS 명령어를 실행하여 현재 권한 집합을 검토하고 Cloud SQL에서 제한된 권한이 있는지 확인합니다. 마찬가지로 Percona의 pt-show-grants 도구도 권한을 나열할 수 있습니다.

Cloud SQL에서 사용자 권한에 대한 제한사항은 DEFINER 속성이 있는 데이터베이스 객체를 마이그레이션할 때 마이그레이션에 영향을 줄 수 있습니다. 이는 저장 프로시저, 트리거, 사용자 정의 함수, 뷰에서 자주 발생합니다. 소스 인스턴스의 데이터베이스 객체에 대한 정의자가 Cloud SQL에서 지원되지 않는 권한이 있는 사용자라면 마이그레이션 중이나 마이그레이션 후에 문제가 발생할 수 있습니다.

예를 들어 Cloud SQL에서 허용되지 않는 전역 변수 변경과 같이 SQL 명령어를 실행할 수 있는 최고 권한이 있는 정의자가 저장 프러시저에 있을 수 있습니다. 이러한 경우 저장 프러시저 코드를 다시 작성하거나 저장 프러시저와 같은 테이블이 아닌 객체를 별도의 마이그레이션 단계로 마이그레이션해야 할 수 있습니다.

이 문서에는 데이터베이스 객체의 정의자 절과 관련된 다른 문제를 자세히 설명하는 DEFINER 절이 있는 메타데이터가 포함된 MySQL 가져오기 및 마이그레이션 작업 섹션이 있습니다.

앞서 언급한 사용자 권한 제한사항으로 인해 사용자는 기본적으로 SET GLOBAL 명령어를 호출하여 데이터베이스 매개변수를 변경할 수 없습니다. 대신 Cloud SQL은 파라미터를 수정하도록 UI 콘솔, GCloud CLI, REST API를 사용하여 수정할 수 있는 사전 정의된 '플래그' 집합을 제공합니다.

지원되는 MySQL용 Cloud SQL 플래그의 전체 목록은 지원되는 플래그 섹션의 공개 문서를 참조하세요. Cloud SQL로 마이그레이션하기 전에 지원되는 플래그 목록과 현재 원본 환경에서 사용되는 플래그를 비교하여 검토합니다. 예를 들어 한 가지 권장사항은 소스 인스턴스와 유사한 CPU 및 메모리 설정으로 테스트 Cloud SQL 인스턴스를 만들고 소스 인스턴스와 Cloud SQL 인스턴스 모두에서 SHOW GLOBAL VARIABLES를 실행하여 차이점을 비교하는 것입니다.

온프레미스 또는 클라우드 제공업체의 설정이 MySQL용 Cloud SQL 설정과 다를 수 있는 일반적인 플래그는 다음과 같습니다.

• 문자 집합 및 콜레이션 설정(예: character_set_server 및 collation_server). 기본값은 설치마다 다를 수 있으며 스토리지 및 성능 차이로 이어질 수 있습니다. 예를 들어 latin1과 utf8을 비교할 수 있습니다.
• 바이너리 로그 설정(예: binlog_format). Cloud SQL은 현재 바이너리 로그에서 행 기반 로깅만 지원합니다.
• 고급 복제 설정. 예를 들어 Cloud SQL은 복제 필터 매개변수(예: replicate-do-table 및 replicate-do-db)를 지원하지 않습니다.
• 고급 InnoDB 설정. Cloud SQL을 사용하면 innodb_buffer_pool_size를 변경하여 InnoDB 버퍼 풀 크기 조정과 같은 대부분의 InnoDB 관련 파라미터를 수정할 수 있습니다. 그러나 Cloud SQL에서 수정할 수 없거나 온프레미스 또는 다른 클라우드 제공업체와 기본값이 다른 더욱 세분화된 InnoDB 설정이 있을 수 있습니다.