MySQL에서 Cloud SQL로 마이그레이션

이 문서에서는 파티션으로 나누지 않은 MySQL 5.7 데이터베이스를 Google Cloud의 완전 관리형 데이터베이스 서비스인 Cloud SQL로 마이그레이션하는 프로세스를 계획하고 실행하는 방법을 설명합니다. 이 문서에서는 대상 독자가 MySQL 데이터베이스를 가지고 있고 일반적으로 MySQL 및 Google Cloud 개념에 익숙하다고 가정합니다.

이 문서에서 설명하는 개념은 다른 버전의 MySQL 및 MySQL의 유명한 오픈소스 포크인 MariaDB에 적용됩니다. 하지만 MySQL 5.7 이외 버전의 경우 프로세스를 약간 수정해야 할 수 있습니다. 데이터베이스 마이그레이션을 계획하는 데 사용할 수 있는 여러 타사 도구 및 Cloud SQL 파트너가 있습니다. 이 문서에서는 기본 MySQL 및 Google Cloud 기능만 설명하고 추가 도구나 파트너는 설명하지 않습니다.

함께 제공되는 가이드에서 이 문서에 설명된 마이그레이션 프로세스 중 하나를 안내합니다.

개요

MySQL 데이터베이스를 다른 환경으로 마이그레이션하려면 2가지 요소를 이동해야 합니다.

  • 데이터베이스의 데이터. 데이터베이스의 스토리지 레이어를 말합니다.
  • 스토리지 레이어에 대한 일관된 읽기 및 쓰기를 처리하는 관리 시스템. 관리 레이어를 말합니다.

문제는 데이터베이스가 작동하려면 이러한 요소가 지속적으로 동기화되어야 한다는 것입니다. 작은 데이터베이스라도 초당 수천 개의 요청을 받을 수 있습니다. 스토리지와 관리 레이어 간의 트랜잭션 지연 또는 네트워크 문제는 데이터베이스, 종속 애플리케이션, 사용자 만족도에 부정적인 영향을 미칩니다.

마이그레이션 방법

MySQL에는 Cloud SQL로 마이그레이션하는 데 도움이 되는 2가지 기능이 있습니다. 이러한 기능은 MySQL 데이터베이스를 마이그레이션하는 데 사용되는 2가지 전략인 내보내기/가져오기 마이그레이션과 외부 복제본 승격 마이그레이션의 기반이 됩니다.

내보내기/가져오기 마이그레이션

내보내기/가져오기 전략에서는 MySQL mysqldump 명령어를 사용하여 원본 데이터베이스 스토리지 레이어의 모든 데이터를 내보냅니다. 그런 다음 이 데이터를 새 데이터베이스 관리 레이어로 직접 가져옵니다. 일반적으로 이 전략은 전체 마이그레이션 중에 모든 데이터를 동기화 상태로 유지하기 위해 데이터베이스에 다운타임이 필요합니다.

외부 복제본 승격 마이그레이션

외부 복제본 승격 마이그레이션 전략에서는 외부 데이터베이스 복제본을 만들고 기존 데이터를 해당 복제본과 동기화합니다. 이 전략은 기존 데이터베이스에 발생하는 다운타임을 최소화할 수 있습니다.

복제본 데이터베이스가 있는 경우 이 문서에서는 두 데이터베이스에 기본복제본이라고 하는 서로 다른 역할이 부여됩니다.

데이터가 동기화된 후에는 데이터베이스 업타임에 미치는 영향을 최소화하면서 관리 레이어를 이동시키기 위해 복제본을 기본 역할로 승격시킵니다.

Cloud SQL에서 외부 복제본을 쉽게 승격시키는 방법은 자동화된 마이그레이션 워크플로를 사용하는 것입니다. 이 프로세스는 이 유형의 마이그레이션에 필요한 여러 단계를 자동화합니다.

MySQL 데이터베이스 마이그레이션 준비

마이그레이션 단계를 수행하기 전에 데이터베이스가 두 옵션 중 하나를 사용하여 마이그레이션할 준비가 되었는지 확인해야 합니다. MySQL은 일부 기본 구성으로 설치되며 애플리케이션의 요구사항에 따라 미세조정하고 맞춤설정할 수 있습니다. 마이그레이션을 시작하기 전에 이 섹션에 설명된 대로 MySQL이 구성되어 있는지 확인하세요. 그러면 마이그레이션 실패 위험을 줄이고 다운타임을 제한하는 데 도움이 됩니다.

논리적 백업 수행

2가지 마이그레이션 방법 중 하나를 사용하여 MySQL 데이터베이스를 변경할 수 있습니다. 데이터베이스의 데이터를 보호하려면 마이그레이션 작업을 수행하기 전에 MySQL mysqldump 명령어를 사용하여 백업으로 유지할 데이터 내보내기를 만들어야 합니다. 이 백업은 2가지 마이그레이션 방법의 시작점으로 사용됩니다.

mysqldump 명령어는 데이터베이스에 있는 모든 데이터의 스냅샷을 만듭니다. 데이터베이스의 크기에 따라 이 프로세스는 1초 미만에서 몇 시간이 걸릴 수 있습니다. 스냅샷을 만든 후 데이터가 변경되면 해당 변경사항이 최종 스냅샷에서 캡처되지 않습니다. 외부 복제본 승격 마이그레이션 프로세스를 사용하는 경우에는 문제가 되지 않습니다. 그러나 내보내기/가져오기 마이그레이션 프로세스의 경우 데이터 불일치 및 데이터 손실이 발생할 수 있습니다.

완전한 백업을 안전한 위치에 저장합니다. Cloud Storage, 로컬 객체 스토리지 시스템, 오프사이트 백업 등에 저장할 수 있습니다.

데이터베이스 성능 측정항목 벤치마크

마이그레이션을 시작하기 전에 기존 애플리케이션 및 데이터베이스의 성능 벤치마크를 모두 수집해야 합니다. 그러면 예상되는 동작 및 현재 성능 측정항목을 이해할 수 있습니다.

보유한 벤치마크가 앱 및 데이터베이스의 사용 사례를 나타내는지 확인하세요. 나중에 벤치마크를 사용하여 마이그레이션된 데이터베이스의 성능을 비교할 때 이전 데이터베이스 배포와 새 데이터베이스 배포 간에 의미 있는 비교를 수행할 수 있어야 합니다.

연결 옵션 결정

네트워크 연결 요구사항은 마이그레이션 전략마다 다릅니다. 사용 가능한 방법을 결정할 때는 공개 IPv4 주소를 사용하여 데이터베이스에 액세스할 수 있는지 여부가 가장 중요합니다.

Cloud SQL 자동 마이그레이션 워크플로를 사용하여 외부 복제본 승격 마이그레이션을 수행할 때는 IPv4 주소를 사용하여 기존 데이터베이스에 공개적으로 액세스할 수 있어야 합니다. 승격 또는 마이그레이션 프로세스가 진행되는 동안 Cloud SQL의 대상 데이터베이스는 계속 네트워크에 연결되어 있어야 합니다. 데이터베이스 크기에 따라 시간이 오래 걸릴 수 있습니다.

대상 데이터베이스의 연결 옵션도 고려해야 합니다. Cloud SQL은 비공개 IP 주소를 사용할 수 있습니다. 또한 공개 IP 연결을 사용하도록 구성할 수도 있습니다.

루트 비밀번호 결정

마이그레이션하는 동안에는 권한이 필요한 여러 MySQL 명령어와 작업을 실행합니다. 따라서 MySQL root 사용자 또는 SUPERGRANT 권한이 있는 계정에 대한 액세스 권한이 있어야 합니다. 이러한 권한 있는 계정 중 하나의 사용자 이름과 비밀번호를 모를 경우 데이터베이스 관리자에게 문의하거나 MySQL 비밀번호 재설정 절차를 따라야 합니다.

테스트 마이그레이션을 수행하고 런북 만들기

프로덕션 마이그레이션을 수행하기 전에 테스트 마이그레이션을 수행해야 합니다. 그러면 마이그레이션 단계를 확인하고 선택한 마이그레이션 방법에 대한 확신을 얻고 마이그레이션에 필요한 시간을 예측할 수 있습니다. 여기서 얻은 교훈을 바탕으로 마이그레이션을 지원하는 런북을 생성할 수 있습니다. 런북을 작업 문서로 사용하여 마이그레이션 조정, 문제해결, 실행을 지원하세요.

이 문서는 데이터베이스 마이그레이션 런북 작성을 위한 입문서가 될 수 있습니다.

데이터베이스 마이그레이션을 위해 애플리케이션 준비

마지막 준비 단계는 마이그레이션을 위해 애플리케이션을 준비하는 것입니다. 애플리케이션과 데이터베이스를 연결하는 모든 방법에 대한 설명은 이 문서에서 다루지 않습니다. 그러나 IP 주소 및 도메인 이름 시스템(DNS) 연결이 애플리케이션에 어떤 영향을 주는지 이해해야 합니다.

데이터베이스에 액세스할 때는 공개 또는 내부 DNS를 사용하는 것이 일반적인 방법입니다. DNS를 사용하면 애플리케이션 코드를 업데이트하지 않아도 대상 데이터베이스의 기본 IP 주소가 변경될 수 있습니다. 애플리케이션이 DNS 레코드를 사용하여 데이터베이스에 연결하는 경우 일반적으로 마이그레이션 시 이러한 DNS 레코드의 TTL(수명) 값을 낮추는 것이 좋습니다.

DNS TTL 값은 초 단위로 측정되며 클라이언트 또는 호스트에 저장된 DNS 레코드의 유효성을 나타냅니다. 이 시간을 DNS 캐시 기간이라고도 합니다. 기본 DNS TTL 값은 각 DNS 제공업체마다 다릅니다. 예를 들어 Cloud DNS는 기본적으로 TTL을 5분(300초)으로 설정합니다. 데이터베이스 DNS 항목은 거의 변경되지 않으므로 DNS 관리자가 이를 훨씬 높게 설정했을 수 있습니다.

데이터베이스를 마이그레이션할 때 DNS TTL이 높으면 클라이언트에 캐시된 DNS 값이 있을 경우 데이터베이스 다운타임이 연장될 수 있습니다. TTL 값을 낮추면 클라이언트가 업데이트된 레코드를 더 자주 확인합니다. 이 동작은 데이터베이스 다운타임을 최소화하는 데 도움이 됩니다.

데이터베이스의 DNS 레코드를 변경하려면 이 수치를 구성 가능한 가장 낮은 값으로 설정해야 합니다. SaaS 기반의 DNS 제공업체일 경우 비용이 증가할 수 있습니다. 이를 변경하기 전에 제공업체나 관리자에게 확인하세요.

내보내기/가져오기 마이그레이션

내보내기/가져오기 마이그레이션 전략은 MySQL mysqldump 명령어를 사용하여 원본 환경 데이터베이스에서 논리적 스냅샷을 내보냅니다. 그런 다음 스냅샷을 대상 환경 데이터베이스로 가져옵니다.

이 방법은 간단하다는 장점이 있지만 마이그레이션 중에 데이터베이스 다운타임이 발생한다는 큰 단점이 있습니다. 대규모 데이터베이스에서는 트랜잭션이 계속 발생하므로 관리자가 일반적으로 다음을 수행합니다.

  1. 원본 데이터베이스가 새 데이터를 쓰는 권한을 비활성화합니다.
  2. 원본 데이터베이스에서 스냅샷을 만듭니다.
  3. 대상 데이터베이스로 스냅샷을 가져옵니다.
  4. 새 데이터베이스를 가리키도록 애플리케이션 구성을 업데이트합니다.
  5. 새 데이터베이스에서 성능을 확인합니다.

다음 다이어그램은 이 시퀀스를 보여줍니다.

온프레미스 MySQL 데이터베이스에서 파일 내보내기로, Cloud Storage로, Cloud SQL에서 실행되는 MySQL로 마이그레이션하는 순서

이 순서는 원본 데이터베이스에 대한 쓰기를 중지한 시간과 새 데이터베이스에 대한 쓰기를 시작한 시간 사이에 데이터가 변경되지 않도록 합니다. 데이터 크기에 따라 이 프로세스로 인해 애플리케이션의 다운타임이 길어질 수 있습니다. 이는 여러 비즈니스 및 애플리케이션에서 허용되지 않는 경우가 많습니다.

내보내기/가져오기 마이그레이션 전략을 사용할 경우 데이터베이스가 외부에서 Cloud SQL에 연결할 필요가 없습니다. 하지만 Cloud SQL에서 액세스 가능한 위치에 mysqldump 파일을 내보낼 수 있어야 합니다. mysqldump 파일의 크기에 따라 이러한 데이터 가져오기/내보내기 프로세스는 오랜 시간이 걸릴 수 있으며, 모든 데이터 행과 모든 트랜잭션 정보가 올바르게 복사되도록 하려면 복잡한 파일 복사 및 인증 기법이 필요할 수 있습니다.

또한 조직의 데이터 분류 규칙은 mysqldump 파일을 다른 위치에 저장하는 기능에 영향을 줄 수 있습니다. 데이터 저장 방법을 선택하기 전에 이 규칙을 참조하세요.

내보내기/가져오기 마이그레이션 단계별 안내

다음 섹션에서는 전체 시퀀스의 각 단계에 대한 세부정보를 제공합니다.

쓰기 사용 중지

관리자가 쓰기 작업을 방지하도록 데이터베이스를 구성합니다. 이를 데이터베이스 잠금 또는 동결이라고도 합니다. 이 작업이 완료되면 데이터베이스로 전송되는 모든 쓰기 트랜잭션이 실패합니다. 그러나 데이터베이스나 복제본에 대한 읽기 트랜잭션은 계속 정상적으로 작동합니다. 후속 단계로 이동하기 전에 몇 가지 테스트 쿼리를 실행하여 이 동작을 확인해야 합니다.

데이터베이스를 잠그면 어떤 애플리케이션이 영향을 받을 수 있는지 이해해야 합니다. 더 큰 시스템 장애를 방지하기 위해 데이터베이스를 사용하는 사용자, 고객, 관리자, 기타 부서에 알려야 할 수도 있습니다.

데이터 내보내기

데이터베이스가 잠긴 후에는 전체 데이터 내보내기를 생성하기 위해 이전 데이터베이스에서 mysqldump 명령어를 실행합니다. 내보내기 프로세스가 완료되면 새 데이터베이스가 액세스할 수 있는 위치로 이 파일을 이동해야 합니다.

프로덕션 데이터베이스가 포함된 드라이브와 별도의 실제 드라이브에 백업 파일을 보내야 합니다. 이렇게 분리하면 디스크 I/O 경합이 줄어들고 백업 속도가 빨라질 수 있습니다. 기본 드라이브에서 쓰기 부하를 제거하면 프로덕션 데이터베이스 작업에 대한 영향이 줄어듭니다. 이렇게 분리하면 프로덕션 데이터베이스가 포함된 디스크의 공간이 부족할 가능성이 줄어듭니다.

또한 mysqldump 명령어의 출력을 압축하면 백업에 필요한 총 쓰기 수를 줄이는 데 도움이 될 수 있습니다. 압축 시 필요한 CPU 리소스가 증가할 수 있으므로 이로 인해 데이터베이스 관리 레이어의 성능에 어떤 영향이 있을지 확인하세요.

자세한 내용은 Cloud SQL로 가져올 데이터 내보내기를 참조하세요.

데이터 가져오기

새 데이터베이스는 이전 데이터베이스에서 덤프 파일을 가져와야 합니다. 가져오기 프로세스는 데이터베이스 테이블과 이전 데이터베이스의 모든 행을 다시 만듭니다. 시스템 리소스가 비슷하다고 가정할 때 가져오기에 필요한 시간은 내보내기에 걸리는 시간과 비슷합니다. 마이그레이션 중에 시스템 리소스를 업그레이드하는 경우 가져오기 프로세스가 내보내기보다 빠를 수 있습니다.

자세한 내용은 Cloud SQL로 데이터 가져오기를 참조하세요.

데이터를 가져온 후에는 원본 데이터베이스 테스트에서 얻은 벤치마크 성능 정보를 검토해야 합니다. 그런 다음 새 데이터베이스에 대한 읽기 기반 프로덕션 쿼리를 실행하여 새 데이터베이스가 애플리케이션의 성능 요구사항을 충족하는지 확인할 수 있습니다.

애플리케이션 업데이트

새 데이터베이스 사용을 시작할 준비가 되면 새 데이터베이스를 지원하도록 애플리케이션을 업데이트해야 합니다. 이 작업을 수행하는 몇 가지 방법이 있습니다.

  • 애플리케이션의 소스 코드에 직접 정의된 데이터베이스 엔드포인트 또는 IP 주소가 있는 경우 코드를 업데이트하고 데이터베이스에 액세스해야 하는 모든 애플리케이션에 이 업데이트를 배포합니다.
  • 애플리케이션이 데이터베이스에 액세스하는 DNS 레코드를 가리키는 경우 새로운 데이터베이스 엔드포인트 주소를 반영하도록 DNS 제공업체를 통해 DNS 레코드를 업데이트합니다.
  • 애플리케이션이 데이터베이스에 액세스하는 부하 분산기를 가리키는 경우 부하 분산기에 새 데이터베이스 엔드포인트를 등록합니다.

Cloud SQL을 사용하도록 애플리케이션을 컷오버하는 경우 버퍼 풀을 준비하는 것이 좋습니다. 그러면 데이터베이스가 데이터를 메모리에 저장하기 전에 애플리케이션에서 발생할 수 있는 쿼리 지연 시간을 최소화할 수 있습니다. 원본 프로덕션 데이터베이스의 MySQL 느린 쿼리 로그를 사용하여 새 인스턴스에 캐시를 채울 모든 SELECT 문을 실행하는 스크립트를 만들 수 있습니다. 쓰기를 사용 설정하기 직전에 이 작업을 수행해야 합니다.

버퍼 풀을 준비하는 데 도움이 되는 여러 타사 도구 및 파트너가 있습니다.

쓰기 사용 설정

업데이트된 애플리케이션 코드가 새 데이터베이스와 통신할 수 있는지 확인한 후에는 새 데이터베이스에 대한 읽기 전용 잠금을 제거해야 합니다. 이 단계 후에 애플리케이션을 통해 데이터베이스의 올바른 기능을 확인할 수 있습니다. 또한 데이터베이스 성능이 여전히 애플리케이션의 요구사항을 충족하는지 확인하기 위해 벤치마크 테스트를 한 번 더 수행해야 합니다.

확인을 마치고 두 데이터베이스의 모든 데이터가 일관성이 있다고 판단되면 몇 가지 정리 작업을 완료할 수 있습니다.

  • 사용자에게 다운타임이 끝났음을 알립니다.
  • 상태 페이지를 업데이트하고 애플리케이션에서 상태 메시지를 제거합니다.
  • 수정된 DNS TTL을 원래 값으로 되돌립니다.

내보내기/가져오기 마이그레이션의 가져오기 시간을 최적화할 때 권장되는 방법

mysqldump 파일의 가져오기 속도를 최적화하는 방법은 여러 가지가 있습니다. 이렇게 하면 서버가 읽기 전용 상태로 있어야 하는 총 시간이 감소합니다.

  • 스키마 최적화. 외래 키를 피하도록 데이터를 구조화합니다. 가능하면 데이터를 기본 키 순서로 내보냅니다.
  • 리소스 최적화. 가능하면 전체 데이터세트를 지원하기에 충분한 RAM으로 새 데이터베이스를 시작합니다. 또한 데이터베이스 스토리지에 SSD를 사용하면 데이터 처리량이 크게 증가할 수 있습니다. SSD는 초당 입출력 작업(IOPS) 수가 기계식 디스크보다 더 많습니다. 또한 Google Cloud SSD는 디스크 크기가 증가할수록 IOPS가 증가합니다. 즉, IOPS를 더 늘리려면 비용을 늘리고 초과 프로비저닝된 대규모 디스크 공간에 투자하는 것이 좋습니다.
  • 모니터링 최적화. 이전 데이터베이스나 새 데이터베이스의 문제를 감지할 수 있는 강력한 모니터링 솔루션을 갖추면 마이그레이션에 매우 유용할 수 있습니다. 예를 들어 Cloud MonitoringMySQL 플러그인을 사용할 수 있습니다. 모니터링을 통해 문제를 조기에 감지하고 정상적인 데이터베이스 동작을 식별하고 새 데이터베이스를 이전 데이터베이스 기준과 비교할 수 있습니다.

대규모 데이터베이스 내보내기 및 가져오기

mysqldump 프로세스는 10GB보다 작은 데이터베이스에서 빠르게 작동합니다. 10GB보다 큰 데이터베이스를 가져오려면 최종 컷오버 중에 발생하는 데이터베이스 다운타임을 최소화하는 고급 전략을 사용해야 합니다.

하위 섹션에서 스키마 및 데이터 내보내기

한 가지 전략은 보조 키 없이 데이터베이스 스키마와 데이터를 여러 섹션으로 내보내는 것입니다. 그러면 마이그레이션 종료 시 ALTER TABLE 문을 사용하여 보조 키를 추가할 수 있습니다. 이 방법을 사용하여 키 관계에 따라 여러 테이블 세트를 여러 파일로 내보냅니다. 그러면 Compute Engine 인스턴스에서 MySQL 가져오기 프로세스를 병렬로 실행할 수 있습니다. 병렬 가져오기를 위해 데이터를 내보내는 한 가지 방법은 내보내기 파일 자체를 수동으로 편집하는 것입니다. 그러나 이 방법은 시간이 오래 걸리고 오류가 발생하기 쉽습니다.

타임스탬프 활용

타임스탬프 열을 사용하는 테이블이 있을 경우 WHERE 절을 지정할 수 있게 해주는 mysqldump 명령어 기능을 사용할 수 있습니다. 그러면 여러 번의 가져오기를 통해 타임스탬프 데이터를 Cloud SQL에 로드할 수 있습니다.

최종 마이그레이션 컷오버가 준비되면 이 기법을 사용하여 마지막 내보내기 이후 변경된 원본 데이터베이스의 행만 내보낼 수 있습니다. 타임스탬프 테이블이 없고 타임스탬프 열을 원본 데이터베이스의 테이블로 도입하는 데 익숙하다면 각 원본 테이블에 MySQL 트리거를 추가하여 행이 변경될 때마다 타임스탬프를 설정할 수 있습니다.

이 방법의 문제는 삭제된 행을 추적한다는 것입니다. 타임스탬프 열은 INSERT 또는 UPDATE 문을 통해 변경된 행만 추적합니다. 삭제된 행은 테이블에서 제거됩니다. 따라서 애플리케이션 및 데이터베이스가 소프트 삭제 메커니즘을 사용하도록 빌드된 경우에만 타임스탬프를 사용하여 초기 마이그레이션 이후 삭제된 행을 찾을 수 있습니다. 이 기법에서는 DELETE 문을 실행하는 대신 is_deleted 열을 true로 설정하여 행이 삭제되었음을 표시합니다. 또는 각각의 실제 테이블에서 삭제된 행을 추적하는 테이블과 삭제된 행을 삭제 추적 테이블에 삽입하는 일치 on_delete 트리거를 만들 수 있습니다. 마이그레이션의 마지막 단계에서 Cloud SQL 인스턴스에서 해당 행을 제거하는 데 필요한 DELETE 문을 만들 수 있습니다.

내보내기 파일 검증

내보내기 파일을 수동으로 수정하거나 여러 테이블을 내보낼 때마다 데이터가 정확하게 내보내졌는지 확인해야 합니다.

내보내기 파일 비교

내보낸 데이터를 검증하는 한 가지 방법은 유휴 테스트 데이터베이스를 구현하는 것입니다. 최신 프로덕션 백업을 새로운 독립형 데이터베이스 인스턴스로 복원하여 유휴 테스트 데이터베이스를 만들 수 있습니다. 그런 다음 mysqldump 파일을 새로운 유휴 테스트 데이터베이스로 복원합니다. 다음으로, 다단계 mysqldump 프로시저를 테스트한 후 이를 또 다른 유휴 테스트 데이터베이스로 동시에 복원할 수 있습니다. 그러면 데이터베이스의 동일한 복사본 두 개가 제공됩니다. 그런 다음 두 유휴 테스트 데이터베이스에 mysqldump 명령어를 실행하고 diff 명령어 또는 파일 비교 도구를 사용하여 모든 세 항목을 비교하여 데이터를 확인할 수 있습니다.

다음 다이어그램은 이러한 시퀀스와 프로세스 중에 생성된 아티팩트를 보여줍니다.

내보내기 파일 검증 순서 및 아티팩트

외부 복제본 승격

MySQL 데이터베이스를 마이그레이션하는 두 번째 방법은 외부 복제본 승격을 사용하는 것입니다. 이 전략에서는 복제본 데이터베이스를 만들고 기존 데이터베이스를 기본 데이터베이스로 설정합니다. 두 데이터베이스가 동기화될 때까지 기다린 다음 MySQL 복제본 데이터베이스를 기본 데이터베이스로 승격시킵니다. 이 프로세스는 데이터베이스 마이그레이션과 관련된 데이터베이스 다운타임을 최소화합니다.

기본 요건

외부 복제본 승격 마이그레이션 방법을 사용하려면 복제본 사용자 생성 및 GTID 복제본 사용 설정이라는 2가지 기본 요건이 충족되어야 합니다.

복제본 사용자 설정

이 문서의 예시에 사용된 5.7 버전을 포함한 특정 버전의 MySQL은 복제에 사용되는 모든 사용자 계정의 사용자 이름과 비밀번호를 기본 데이터베이스 로그에 일반 텍스트로 저장합니다. root 사용자 계정을 사용하여 복제를 수행하는 경우 root 비밀번호가 일반 텍스트 로그에 저장됩니다. 따라서 복제에 root 사용자를 사용하면 보안 위험이 발생합니다.

데이터베이스의 다른 측면이 손상될 가능성을 제한하려면 복제를 수행하는 데 사용할 완전히 별도의 계정을 만들어야 합니다. 새 계정에는 복제 프로세스에 필요한 권한만 있어야 합니다. 또한 이 계정은 기본 데이터베이스의 IP 주소에서만 복제할 수 있도록 제한되어야 합니다.

GTID 구성

외부 복제본 승격 마이그레이션을 수행하려면 원본 데이터베이스에 GTID 복제본이 사용 설정되어 있어야 합니다. 원본 데이터베이스에 복제를 구성하지 않은 경우 GTID 복제가 사용 설정되지 않았을 수 있습니다.

글로벌 트랜잭션 식별자(GTID)는 기본 데이터베이스 서버에서 커밋된 각 트랜잭션과 연결된 고유한 식별자입니다. 이 식별자는 복제본과 기본 데이터베이스 간의 복제 프로세스를 구축하는 데 사용됩니다.

MySQL용 Cloud SQL의 새 인스턴스는 기본적으로 GTID 복제를 사용합니다. 이 기능은 사용 중지할 수 없으므로 특정 SQL 문 및 작업이 허용되지 않습니다. 자세한 내용은 Cloud SQL과 표준 MySQL의 기능 차이GTID 복제에 대한 MySQL 제한사항을 참조하세요.

외부 복제본 승격 마이그레이션 개요

내보내기/가져오기 마이그레이션보다 외부 복제본 승격 마이그레이션이 훨씬 쉬울 수 있습니다. 앞에서 설명한 모든 기본 요건을 완료한 경우 Cloud SQL로 이 프로세스를 자동화할 수 있습니다. 자동 마이그레이션 워크플로에는 여전히 내보내기/가져오기 프로세스가 필요하지만 자동화 중에 일부 수동 단계가 추상화됩니다.

자동 마이그레이션 워크플로는 다음 시나리오를 지원합니다.

  • 온프레미스에서 Cloud SQL로 마이그레이션
  • 다른 클라우드 제공업체에서 Cloud SQL로 마이그레이션
  • 한 Google Cloud 프로젝트에서 다른 Google Cloud 프로젝트로 마이그레이션

자동 마이그레이션 워크플로에서는 다음을 수행합니다.

  1. 데이터 소스에 대한 세부정보를 제공합니다.
  2. Cloud SQL 읽기 복제본을 만듭니다.
  3. 읽기 복제본을 소스와 동기화합니다.
  4. Cloud SQL 읽기 복제본을 기본 인스턴스로 승격시킵니다.

데이터 소스에 대한 세부정보 제공

Cloud SQL로 자동 마이그레이션 워크플로를 실행할 때는 데이터 소스의 참조 이름을 제공하세요. 이 이름은 마이그레이션에서 데이터를 참조하는 데 사용되며 소스의 실제 이름과 일치하지 않아도 됩니다.

또한 원본 데이터베이스의 공개 IP 주소와 포트를 제공합니다. Cloud SQL 데이터베이스가 IPv4 주소를 사용하여 원본 데이터베이스에 직접 연결되어 있는지 확인해야 합니다. 또한 원본 데이터베이스를 보호하는 방화벽 또는 보안 어플라이언스가 새 Cloud SQL 데이터베이스 IP 주소에서 들어오는 연결을 허용하도록 구성되어 있는지 확인해야 합니다.

또한 자동 마이그레이션 워크플로에 MySQL 복제본 사용자 인증 정보 및 마이그레이션하려는 MySQL 버전을 제공해야 합니다. 이는 서버에 인증하고 다음 단계에서 보안 전송을 지원하는 데 필요합니다. 필요에 따라 SSL/TLS 옵션을 구성할 수도 있습니다.

Cloud SQL 읽기 복제본 만들기

자동 마이그레이션 워크플로를 실행할 때는 Google Cloud에서 새 Cloud SQL 인스턴스를 만드는 방법에 대한 옵션을 설정합니다. 이를 위해 몇 단계를 거쳐야 합니다.

  • 데이터베이스 인스턴스 ID 설정
  • Google Cloud 리전 및 영역 선택
  • 인스턴스 유형 선택
  • 디스크 스토리지 유형 선택
  • 총 저장용량 선택. 자동 스토리지 증가를 사용 설정하는 것이 좋습니다. 이 옵션을 사용하면 필요에 따라 데이터베이스가 확장될 수 있으며, 데이터베이스에 디스크 공간이 부족해질 위험이 줄어듭니다.

마지막으로 Cloud Storage에 저장한 스냅샷에 대한 링크를 제공합니다. Cloud SQL 인스턴스와 동일한 프로젝트에 있는 Cloud Storage 버킷에 최신 내보내기 파일이 있는지 확인하세요.

소스와 읽기 복제본 동기화

마이그레이션 프로세스를 시작하면 새 Cloud SQL VM이 시작되고 소스에서 복제하기 시작합니다. 동기화가 완료되면 데이터베이스의 데이터를 비교하여 복제가 완료되었는지 확인할 수 있습니다. 또한 애플리케이션 요구사항과 원본 데이터베이스의 이전에 측정된 기준 성능에 따라 Cloud SQL 데이터베이스의 성능을 테스트하기 위해 벤치마킹을 시작할 수 있습니다.

읽기 복제본을 기본 인스턴스로 승격

데이터가 복제되면 이전 데이터베이스를 읽기 전용 모드로 설정합니다. 이렇게 하면 데이터베이스에 대한 쓰기가 방지되고 승격 프로세스 중에 데이터가 변경되지 않습니다. 그런 다음 앞에서 설명한 대로 Cloud SQL에서 새 엔드포인트를 지원하도록 애플리케이션 코드 또는 DNS 항목을 업데이트합니다.

원본 데이터베이스가 읽기 전용 모드이고 애플리케이션이 새 Cloud SQL 엔드포인트 주소로 업데이트된 경우 Cloud SQL의 새 데이터베이스 인스턴스로 이동하여 복제본을 기본 서버로 승격시킬 수 있습니다. 이 프로모션 프로세스는 새로 승격된 Cloud SQL 기본 데이터베이스에 대한 쓰기를 자동으로 다시 사용 설정합니다.

복제본을 기본 서버로 승격시킨 후 데이터베이스 크기에 관계없이 데이터베이스에 몇 분의 다운타임이 발생할 수 있습니다. 이는 Cloud SQL에서 데이터베이스 승격과 관련된 모든 작업 및 구성 작업을 수행하기 위해 필요한 시간입니다.

승격이 완료되면 기본 데이터베이스가 Cloud SQL에서 실행되고 마이그레이션이 완료됩니다. 이때 애플리케이션 요구사항 및 원본 데이터베이스 기준 성능에 따른 일련의 성능 테스트를 한 번 더 실행하면 좋습니다. 새로운 Cloud SQL 성능 벤치마크 세트가 있으면 다른 데이터베이스 최적화를 계획할 수 있습니다.

마이그레이션 후 최적화

마이그레이션이 완료되면 마이그레이션 방법에 관계없이 다음과 같은 방법으로 Cloud SQL 데이터베이스를 최적화할 수 있습니다.

  • VM의 크기를 적절하게 조절합니다. VM의 크기를 적절히 조절. 모니터링 데이터를 분석하여 데이터베이스에 다른 크기의 VM을 선택해야 하는지 확인할 수 있습니다. 더 작은 인스턴스를 사용하여 비용을 절감할 수 있습니다. 반대로, 리소스가 더 많은 더 큰 VM에서는 데이터베이스 성능이 향상될 수 있습니다.
  • 색인 추가. 데이터베이스가 추가 색인 또는 다른 최적화로 이점을 얻을 수 있다면 마이그레이션을 완료한 후에 이를 추가할 수 있습니다.
  • 추가 트랜잭션 로깅 사용 설정. 서버 로깅 수준을 살펴보면 바이너리 로깅 또는 다른 고급 로깅 옵션을 사용 설정할 경우의 이점을 확인할 수 있습니다.
  • 외부 복제본 승격 마이그레이션 방법의 경우 바이너리 로깅을 다시 사용 설정하고 자동 백업을 활용합니다. (복제본 승격 마이그레이션 후에는 바이너리 로깅이 사용 중지되므로 Cloud SQL 자동 백업이 사용 중지됩니다.)

다음 단계