1세대 인스턴스를 2세대로 업그레이드

이 페이지에서는 1세대 MySQL 인스턴스를 2세대로 업그레이드하는 방법을 설명합니다.

소개

Cloud SQL 2세대는 1세대보다 훨씬 많은 이점을 제공합니다. Cloud SQL에서는 요건을 충족하는 인스턴스에 1세대에서 2세대 인스턴스로 인플레이스(In-Place) 업그레이드를 지원합니다. 1세대 인스턴스가 요건을 충족하면 콘솔 인스턴스 목록 페이지 또는 인스턴스 세부정보 페이지의 인스턴스 이름 옆에 업그레이드 버튼이 표시됩니다.

업그레이드 절차는 인스턴스 및 애플리케이션에 미치는 영향을 최소화하도록 설계되었습니다. 예를 들어 업그레이드 시 Cutover(단순 이전)가 발생하는 시점을 제어할 수 있고 인스턴스의 IPv4 주소가 보존되어 애플리케이션을 즉시 변경할 필요가 없습니다. 하지만 Cloud SQL 2세대 인스턴스에서 지원되는 기능과 1세대에서 지원되는 기능이 다르므로 인스턴스 또는 애플리케이션을 일부 변경해야 할 수도 있습니다.

시작하기 전에

인스턴스 업그레이드를 진행하기 전에 전체 절차를 숙지하고 업그레이드가 인스턴스 및 애플리케이션에 미치는 영향을 이해해야 합니다.

사전 구성 요구사항

2세대로 업그레이드하기 전에 수행해야 할 단계는 현재 인스턴스 구성과 클라이언트 연결 방법에 따라 다릅니다.

1세대 인스턴스가 다음과 같은 경우 필요한 조치 추가 정보
MySQL 5.5를 사용해 구성 MySQL 5.5와 5.6의 차이점 목록을 검토하고 필요한 조치를 취합니다. 업그레이드 후에는 인스턴스가 MySQL 5.6을 사용합니다. MySQL 5.6으로 업그레이드에 영향을 미치는 변경사항을 참조하세요.
MEMORY 스토리지 엔진을 사용하는 테이블 포함 업그레이드 프로세스를 시작하기 전에 MEMORY 스토리지 엔진을 사용하는 모든 테이블을 삭제합니다. 애플리케이션에 이러한 테이블에 있는 데이터가 필요한 경우 InnoDB 스토리지 엔진을 사용하는 새 테이블로 데이터를 이동시켜야 합니다.

다음 SQL 명령어를 사용하면 이러한 테이블을 찾을 수 있습니다.


SELECT table_schema, table_name, table_type
   FROM information_schema.tables
   WHERE engine = 'MEMORY' AND
   table_schema NOT IN
   ('mysql','information_schema','performance_schema');

Cloud SQL에서 사전 업그레이드 구성을 확인하는 중에 이러한 테이블이 강조표시됩니다.

PERFORMANCE_SCHEMA 스토리지 엔진을 사용하지 않는 performance_schema 데이터베이스의 테이블 포함 업그레이드 프로세스를 시작하기 전에 PERFORMANCE_SCHEMA 스토리지 엔진을 사용하지 않는 performance_schema 데이터베이스의 모든 테이블을 삭제합니다.

다음 SQL 명령어를 사용하면 이러한 테이블을 찾을 수 있습니다.


SELECT table_name
   FROM information_schema.tables
   WHERE table_schema='performance_schema'
   AND engine != 'performance_schema';

Cloud SQL에서 사전 업그레이드 구성을 확인하는 중에 이러한 테이블이 강조표시됩니다.

slow_query_log 또는 general_log 테이블의 데이터 포함 해당 테이블을 자릅니다.

이 테이블의 데이터는 2세대 인스턴스로 가져오지 않습니다. 또한 이 테이블의 데이터가 많은 경우 전환 과정에서 (몇 시간에 이르는) 긴 다운타임이 발생할 수 있습니다.

Cloud SQL에서는 log_output 플래그를 FILE로 설정해 로그 출력을 Google Cloud Platform Console 로그 뷰어로 전송하는 것이 좋습니다. 자세히 알아보기

애플리케이션이 다음과 같은 경우 숙지사항 추가 정보
IPv6을 사용해 연결되고 인스턴스에 할당된 IPv4 주소가 없음 몇 분간의 추가 애플리케이션 다운타임과 추가 애플리케이션 업데이트 중 하나를 선택해야 합니다.

전환 과정에서 몇 분간의 다운타임을 허용할 수 있는 경우 새 공개(기본) IPv4 주소를 사용할 수 있게 되는 업그레이드 이후 시점까지 애플리케이션 업데이트를 기다리면 됩니다.

애플리케이션 다운타임을 최소화해야 하는 경우에는(Cutover(단순 이전) 중에는 항상 다운타임이 발생함) IPv4 주소를 1세대 인스턴스에 추가하고 업그레이드를 시작하기 전에 이 주소를 사용하도록 애플리케이션을 업데이트하면 됩니다. 이 IPv4 주소가 업그레이드된 2세대 인스턴스에서도 유지되며, 이전된 1세대 IP 주소로 표시됩니다. 하지만 이전된 IP 주소는 이후에 지원이 중단되므로 새(공개) IPv4 주소를 사용하도록 애플리케이션을 다시 업데이트해야 합니다.

GTID 측면에서 안전하지 않은 코드 포함 지원되지 않는 문을 삭제하도록 애플리케이션을 업데이트해야 합니다. 업그레이드 후 필요에 따라 변경할 수도 있지만, 업그레이드 후에는 바이너리 로깅을 사용 중지하는 방법으로만 변경이 가능합니다. 최상의 결과를 위해서는 업그레이드 전에 변경하는 것이 좋습니다.
Apps Script를 사용하며 원래의 jdbc 경로(jdbc:google:rdbms//)를 사용해 연결 지원되는 연결 경로를 사용하도록 애플리케이션을 업데이트해야 합니다. JDBC를 참조하세요.

사전 구성 권장사항

다음은 필수적인 조치는 아니지만 수행하면 업그레이드 절차를 간소화하거나 단축하는 데 도움이 됩니다.

1세대 인스턴스가 다음과 같은 경우 고려사항 추가 정보
프로덕션 애플리케이션 지원 인스턴스의 복제본을 만들어 복제본에서 업그레이드 절차를 수행하고, 업그레이드된 복제본을 사용해 애플리케이션 테스트도 수행합니다.

복제본에서 업그레이드 절차를 테스트하면 프로덕션 환경에서 업그레이드를 시도하기 전에 인스턴스 및 애플리케이션에 필요한 변경사항(있는 경우)을 파악할 수 있습니다.

인스턴스 복제에 대한 자세한 내용은 인스턴스 복제를 참조하세요.

자동 백업 또는 바이너리 로깅이 사용 설정되지 않음 두 설정을 모두 사용 설정합니다. 업그레이드 절차 중에도 이 단계를 수행할 수 있습니다. 이 업데이트의 경우 인스턴스를 다시 시작해야 합니다.

2세대 구성 및 관리

2세대 인스턴스의 관리 요구사항은 1세대 인스턴스와 다릅니다. 1세대와 2세대의 차이점 목록을 검토하고 이러한 차이점이 Cloud SQL 관리 업무에 미치는 영향을 이해해야 합니다.

2세대 인스턴스는 스토리지 자동 증가, 구성 가능한 유지보수 기간, 요청 시 백업 등의 추가 구성 옵션을 제공합니다. 자세한 내용은 2세대 인스턴스 설정을 참조하세요.

저장소 요구사항 및 가격 책정

2세대 인스턴스에서는 시스템 사용을 위해 저장소를 더 많이 예약합니다. 인스턴스를 2세대로 업그레이드하면 사용되는 저장소의 양이 약 0.75GB 증가합니다.

2세대 저장소 가격은 사용량이 아닌 저장용량에 따라 책정됩니다. 자세한 내용은 저장소 및 네트워킹 가격 책정을 참조하세요.

머신 유형

2세대 머신 유형은 1세대 인스턴스 등급과 다르며 가격 책정 방식도 다릅니다. 1세대 인스턴스는 아래 표와 같이 2세대 인스턴스로 업그레이드됩니다. 업그레이드된 인스턴스는 리소스를 적어도 1세대에 제공되는 만큼은 2세대에 제공합니다. 업그레이드 후 필요하다면 2세대 인스턴스의 머신 유형을 변경할 수 있습니다.

표시된 1세대 가격은 '상시 사용 설정' 패키지 가격입니다.

1세대 등급 2세대 머신 유형
D0(CPU 0.125개, RAM 128MB)
최대 연결 수: 250개
$10.80/월
db-f1-micro(공유 CPU 1개, RAM 0.60GB)
최대 연결 수: 250개
$10.35/월
D1(CPU 0.25개, RAM 512MB)
최대 연결 수: 250개
$43.80/월
db-g1-small(공유 CPU 1개, RAM 1.70GB)
최대 연결 수: 1,000개
$28.25/월
D2(CPU 0.5개, RAM 1GB)
최대 연결 수: 250개
$87.90/월
db-n1-standard-1(CPU 1개, RAM 3.75GB)
최대 연결 수: 4,000개
$104.00/월(장애 조치용 복제본 포함)
D4(CPU 1개, RAM 2GB)
최대 연결 수: 500개
$132.00/월
db-n1-standard-1(CPU 1개, RAM 3.75GB)
최대 연결 수: 4,000개
$104.00/월(장애 조치용 복제본 포함)
D8(CPU 2개, RAM 4GB)
최대 연결 수: 1,000개
$263.40/월
db-n1-standard-2(CPU 2개, RAM 7.50GB)
최대 연결 수: 4,000개
$210.00/월(장애 조치용 복제본 포함)
D16(CPU 4개, RAM 8GB)
최대 연결 수: 2,000개
$527.10/월
db-n1-standard-4(CPU 4개, RAM 15GB)
최대 연결 수: 4,000개
$448.00/월(장애 조치용 복제본 포함)
D32(CPU 8개, RAM 16GB)
최대 연결 수: 4,000개
$1,053.90/월
db-n1-standard-8(CPU 8개, RAM 30GB)
최대 연결 수: 4,000개
$996.00/월(장애 조치용 복제본 포함)

샘플 구성 가격을 포함한 2세대 가격에 대한 자세한 내용은 가격 책정 페이지를 참조하세요.

ON_DEMAND 활성화 정책

2세대 인스턴스는 ON_DEMAND 활성화 정책을 지원하지 않습니다. 인스턴스를 수동으로 중지할 수 있지만 다시 시작할 때까지 수신되는 연결 요청에 응답하지 않습니다. 자세히 알아보기

MySQL 시스템 변수 및 옵션

2세대 인스턴스에서는 일부 MySQL 시스템 변수 및 옵션의 기본값이 다릅니다. 인스턴스의 MySQL 변수가 2세대에서 지원되지 않는 값으로 설정된 경우 업그레이드 절차 중에 값이 변경됩니다. 이 변수는 구성이 불가능합니다.

다음 표에는 영향을 받는 변수와 업그레이드 후 변경되는 값이 나와 있습니다.

시스템 변수 2세대 값
default_time_zone UTC에서 오프셋으로 형식이 변경됨
expire_logs_days 0
innodb_log_file_size 512MB
max_connections 머신 유형 표 참조
sync_binlog 사용 설정됨

다운타임

아래 설명과 같이 업그레이드하는 동안 애플리케이션에는 다운타임이 발생합니다.

  1. 1세대 인스턴스에 바이너리 로깅이 사용 설정되지 않은 경우 업그레이드를 수행하는 데 필요한 바이너리 로깅의 사용 설정을 위해 인스턴스가 다시 시작됩니다.
  2. 업그레이드 중 인스턴스와 2세대 복제본 간의 안전한 복제를 지원하기 위한 SSL/TLS 인증서를 설치하기 위해 1세대 인스턴스가 다시 시작됩니다.
  3. 전환 절차를 시작하고 2세대 인스턴스가 기본 인스턴스로 작동하기 시작할 때 1세대 인스턴스에서는 요청에 대한 응답이 중단되고 2세대 인스턴스는 아직 온라인 상태가 되지 않은 기간이 존재합니다.

    전환에 필요한 시간은 인스턴스와 복제본 간의 복제 지연 정도에 많은 영향을 받습니다. 그렇기 때문에 전환에 앞서 쓰기 작업을 줄이거나 중지해야 합니다.

App Engine 표준 환경에서 연결하는 애플리케이션에 관한 고려사항

서비스 계정

1세대 인스턴스에서는 앱의 프로젝트를 승인하여 App Engine 애플리케이션에서 인스턴스에 대한 액세스를 제어할 수 있습니다. 이 같은 승인은 인스턴스 단위로 이루어집니다.

2세대 인스턴스의 경우 서비스 계정을 사용해 App Engine 애플리케이션의 액세스를 승인하여 특정 프로젝트의 모든 Cloud SQL 인스턴스에 대한 액세스를 승인합니다.

승인된 App Engine 프로젝트의 인스턴스를 1세대에서 2세대로 업그레이드할 경우 Cloud SQL은 업그레이드 전에 승인된 App Engine 프로젝트와 동일한 액세스 권한을 제공하는 특별한 서비스 계정을 만듭니다. 이 서비스 계정은 전체 프로젝트가 아닌 특정 인스턴스에 대한 액세스만 승인하기 때문에 IAM 서비스 계정 페이지에 표시되지 않으며 이를 업데이트하거나 삭제할 수 없습니다.

연결 지연 시간

일반적으로 2세대 인스턴스에서는 1세대 인스턴스에 비해 연결 지연 시간이 줄어듭니다. 그러나 App Engine 표준 환경에서 연결하는 애플리케이션의 경우 지연 시간이 약 0.3ms 증가합니다.

사전 정의된 MySQL 사용자 계정의 변경사항

App Engine에서 연결할 때 사용되는 사전 정의된 MySQL 사용자 계정의 호스트 이름이 root@localhost에서 root@cloudsqlproxy~%로 변경됩니다.

localhost를 호스트로 사용하는 다른 MySQL 사용자가 있다면 이 사용자 역시 유사한 방식으로 변경됩니다. 이전 절차 중에 호스트 이름이 자동으로 MySQL grantuser 테이블에서 업데이트되며 보통은 이 같은 변경사항이 반영되도록 App Engine 앱을 업데이트할 필요가 없습니다.

하지만 사용하는 앱이나 기타 도구가 MySQL에서 사용자 테이블과 권한 부여를 직접 수정하는 경우에는 업그레이드가 완료된 후 cloudsqlproxy~%를 호스트로 사용하도록 업데이트해야 합니다. 업그레이드하는 동안에는 사용자 테이블이나 권한 부여를 수정하면 안 됩니다.

이러한 변경사항은 해당 계정을 사용한 연결의 성능에 영향을 미치지 않습니다.

rdbms 연결 라이브러리

애플리케이션에서 지원 중단된 rdbms 연결 라이브러리를 사용하는 경우 지원되는 연결 방법을 사용할 수 있도록 업데이트해야 합니다. 업그레이드된 2세대 인스턴스에서는 rdbms 라이브러리가 작동하지 않습니다.

업그레이드 수행

준비 단계가 완료되면 업그레이드를 진행할 수 있습니다.

  1. Google Cloud Platform Console의 Cloud SQL 인스턴스 페이지로 이동합니다.
    Cloud SQL 인스턴스 페이지로 이동
  2. 업그레이드할 인스턴스를 찾고 이름 옆에 있는 업그레이드 버튼을 클릭합니다.
  3. 2세대로 업그레이드 패널에서 구성 확인을 클릭합니다.
  4. 업그레이드가 시작되기 전에 인스턴스를 업데이트해야 하는 경우 변경사항 실행을 클릭하고 제공되는 안내를 따릅니다.
  5. 업그레이드 절차를 시작하려면 계속을 클릭합니다.

    원본 인스턴스가 활성화된 상태에서 데이터가 복제본에 복제됩니다. 참고: 원본 인스턴스 및 복제본이 둘 다 존재하는 동안에는 두 인스턴스 모두에 대한 요금이 부과됩니다. 추가 비용을 최소화하려면 이 단계를 완료하는 즉시 새 인스턴스로 전환하세요.

  6. 권장 선택사항: 1세대 인스턴스의 복제본을 만듭니다.

    복제본이 있으면 업그레이드에 문제가 있을 때 현재 상태로 롤백할 수 있습니다.

  7. 권장 선택사항: 복제본을 만든 후 애플리케이션을 종료합니다.

    전환 중에는 인스턴스에 액세스할 수 없습니다. 애플리케이션에서 트랜잭션을 열어두는 경우 특히 알고 있어야 할 사항입니다.

  8. 복제본을 만든 후 전환을 클릭합니다.

    그러면 복제본이 승격되어 데이터를 제공하게 됩니다. 인스턴스에서 새로운 연결의 허용이 중지되고 5-10분간 다운타임이 발생합니다. 작업 창에 전환이 장애 조치 작업으로 표시됩니다.

  9. 전환이 완료되면 마침을 클릭하여 업그레이드 프로세스를 완료하고 업그레이드 이후 단계를 진행합니다.

업그레이드 확인 및 완료

다음 체크리스트는 업그레이드 절차가 완료된 후 모든 기능이 정상적으로 작동하는지 확인하고 2세대 인스턴스가 올바르게 구성되었는지 확인하는 데 도움이 됩니다.

업그레이드를 롤백해야 하는 경우 업그레이드 롤백을 참조하세요.

  • 클라이언트 및 애플리케이션이 올바르게 연결되어 작동하는지 확인하세요.

    2세대 인스턴스에서는 GTID를 사용합니다. 이 변경사항을 올바르게 처리하기 위해 애플리케이션을 업데이트해야 하는 경우 바이너리 로깅을 일시적으로 사용 중지하면 GTID 확인도 사용 중지됩니다. 바이너리 로깅을 사용 중지하면 복제 및 특정 시점 복구도 사용 중지되므로 GTID 안전을 유지하기 위해 애플리케이션을 업데이트하고 최대한 빨리 바이너리 로깅을 다시 사용 설정해야 합니다.

  • 필요하다면 고가용성 인스턴스를 구성하세요.

    인스턴스에서 프로덕션 데이터를 제공하는 경우 데이터의 내구성과 가용성을 위해 이 단계가 강력히 권장됩니다.

  • 필요한 읽기 복제본을 다시 생성하세요.

    복제본을 다시 만들 때는 복제본의 이전 이름을 재사용할 수 없습니다. 다른 이름을 선택해야 합니다.

  • 애플리케이션에서 업그레이드 전에 만든 IPv6 또는 IPv4 주소를 사용해 연결하는 경우 업그레이드 중에 할당된 새 공개(기본) 주소를 사용하도록 애플리케이션을 업데이트하세요.

    업그레이드 전에 만든 IPv4 주소가 이전된 1세대 IP 주소로 표시됩니다. 이전된 IP 주소는 이후 지원이 중단될 예정입니다.

  • 다른 연결 경로를 업데이트하세요.

    대부분의 경우 업그레이드 전에 사용했던 연결 경로를 그대로 사용할 수 있지만 새로운 옵션도 몇 가지 제공됩니다.

  • 애플리케이션에서 다음과 같이 1세대 인스턴스 연결 이름을 사용해 연결하는 경우,

    <project_id>:<instance_id>

    다음과 같이 2세대 인스턴스 연결 이름을 사용하도록 업데이트합니다.

    <project_id>:<region>:<instance_id>

  • 데이터베이스에 MyISAM 테이블(시스템 테이블 제외)이 있다면 InnoDB 저장소 엔진을 사용하도록 변환하는 것이 좋습니다.

    기존 MyISAM 테이블을 계속 사용할 수는 있습니다. 하지만 데이터의 내구성을 높이려면 변환하는 것이 좋습니다. 자세한 내용은 MyISAM에서 InnoDB로 테이블 변환을 참조하세요.

업그레이드 롤백

업그레이드한 2세대 인스턴스에 문제가 발생하는 경우 업그레이드 절차를 시작하기 전의 1세대 인스턴스와 상태가 동일한 새 인스턴스를 만들면 됩니다.

  1. 업그레이드 절차 중에 복제본을 만든 경우 복제본을 가리키도록 애플리케이션을 업데이트합니다.
  2. 그 밖의 경우에는 다음 단계를 완료하세요.

    1. 원래 인스턴스와 동일한 등급의 새 1세대 인스턴스를 만듭니다.
    2. 업그레이드한 인스턴스의 백업 페이지를 열고 업그레이드 절차가 시작될 때 실행된 백업을 찾습니다.
    3. 방금 만든 새 1세대 인스턴스로 백업을 복원합니다.

      자세한 내용은 다른 인스턴스로 복원하기를 참조하세요.

다음 단계

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

MySQL용 Cloud SQL