데이터베이스 주 버전 인플레이스 업그레이드

MySQL | PostgreSQL | SQL Server

이 페이지에서는 데이터를 마이그레이션하는 대신 Cloud SQL 인스턴스를 인플레이스 업그레이드하여 데이터베이스 주 버전을 업그레이드하는 방법을 설명합니다.

소개

데이터베이스 소프트웨어 제공업체는 새로운 기능, 성능 개선, 보안 개선사항이 포함된 새로운 주 버전을 주기적으로 출시합니다. Cloud SQL은 이러한 주 버전이 출시된 후 새 버전을 채택합니다. Cloud SQL에서 새로운 주 버전에 대한 지원이 제공된 후 인스턴스를 업그레이드하여 데이터베이스를 업데이트된 상태로 유지할 수 있습니다.

인스턴스의 데이터베이스 버전을 인플레이스로 또는 데이터 마이그레이션을 통해 업그레이드할 수 있습니다. 인플레이스 업그레이드는 인스턴스의 주 버전을 업그레이드하기 위한 더 간단한 방법입니다. 데이터를 마이그레이션하거나 애플리케이션 연결 문자열을 변경할 필요가 없습니다. 인플레이스 업그레이드의 경우 업그레이드 후 현재 인스턴스의 이름, IP 주소, 기타 설정을 유지할 수 있습니다. 인플레이스 업그레이드는 데이터 파일을 이동할 필요가 없고 더 빠르게 완료할 수 있습니다. 일부 경우에는 데이터 마이그레이션보다 다운타임이 짧습니다.

SQL 서버용 Cloud SQL 인플레이스 업그레이드 작업은 SQL Server 업그레이드 인플레이스 유틸리티를 사용합니다.

주 버전 업그레이드 계획

대상 주 버전을 선택합니다.

Cloud SQL에서 지원되는 버전 목록을 참조하세요.
각 데이터베이스 주 버전에 제공된 기능을 고려해서 비호환성 문제를 해결합니다.

SQL Server 지원 중단 기능 및 브레이킹 체인지를 참조하세요.

새로운 주 버전에는 애플리케이션 코드, 스키마, 데이터베이스 설정을 수정해야 할 수 있는 호환되지 않는 변경사항이 포함됩니다. 데이터베이스 인스턴스를 업그레이드하려면 먼저 대상 주 버전의 출시 노트를 검토하여 해결이 필요한 비호환성 문제를 확인하세요.

참고: 주 버전을 업그레이드할 때는 SQL Server 버전도 업그레이드할 수 있습니다. 예를 들어 SQL Server 2017 Standard에서 SQL Server 2019 Enterprise로 업그레이드할 수 있습니다. 버전을 업그레이드하려면 SQL 서버용 Cloud SQL 라이선스 가격 책정을 검토하세요.
시험 이전을 통해 업그레이드를 테스트합니다.

프로덕션 데이터베이스를 업그레이드하기 전 테스트 환경에서 엔드 투 엔드 업그레이드 프로세스의 시험 이전을 수행합니다. 인스턴스를 클론하여 업그레이드 프로세스를 테스트할 동일한 데이터 사본을 만들 수 있습니다.

업그레이드가 성공적으로 완료되는지 검증하는 것 외에도 업그레이드된 데이터베이스에서 애플리케이션이 예상한 대로 작동하는지 확인하는 테스트를 실행합니다.

참고: 메이저 버전 업그레이드를 실행하기 전에 디스크 공간이 충분한지 확인하세요. 자동 스토리지 증가를 사용 설정하지 않았으면 업그레이드된 테스트 실행 인스턴스에서 사용되는 디스크 스토리지를 기록합니다. 이렇게 하면 업그레이드하기 전 프로덕션 인스턴스의 스토리지 용량을 늘려야 하는지 여부를 확인할 수 있습니다.
업그레이드 시간을 결정합니다.

업그레이드하려면 일정 기간 동안 인스턴스가 사용 중지되어야 합니다. 데이터베이스 활동이 적은 기간에 업그레이드를 계획합니다.

데이터베이스 주 버전 인플레이스 업그레이드

업그레이드 작업을 시작하면 Cloud SQL이 먼저 인스턴스 구성이 업그레이드와 호환되는지 확인합니다. 구성이 확인된 후에는 Cloud SQL이 인스턴스를 사용 중지하고, 업그레이드 전 백업을 만들고, 업그레이드를 수행하고, 인스턴스를 사용하도록 설정하고, 업그레이드 후 백업을 만듭니다.

콘솔

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
인스턴스의 개요 페이지를 열려면 인스턴스 이름을 클릭합니다.
수정을 클릭합니다.
인스턴스 정보 섹션에서 업그레이드 버튼을 클릭하고 업그레이드 페이지로 이동함을 확인합니다.
데이터베이스 버전 선택 페이지에서 업그레이드할 데이터베이스 버전 목록을 클릭하고 사용 가능한 데이터베이스 주 버전 중 하나를 선택합니다.
계속을 클릭합니다.
인스턴스 ID 상자에 인스턴스 이름을 입력한 후 업그레이드 시작 버튼을 클릭합니다.

작업이 완료되는 데 몇 분 정도 걸립니다.

인스턴스 개요 페이지의 인스턴스 이름 아래에 업그레이드된 데이터베이스 주 버전이 표시되는지 확인합니다.

gcloud

업그레이드를 시작합니다.

gcloud sql instances patch 명령어를 --database-version 플래그와 함께 사용합니다.

명령어를 실행하기 전 다음 변수를 바꿉니다.
- INSTANCE_NAME: 인스턴스 이름.
- DATABASE_VERSION: 현재 버전보다 커야 하는 데이터베이스 주 버전의 열거형입니다. 사용 가능한 데이터베이스 버전 열거형을 참조하세요.
```
gcloud sql instances patch INSTANCE_NAME \
--database-version=DATABASE_VERSION
```
주 버전 업그레이드를 완료하려면 몇 분 정도 걸립니다. 작업이 예상보다 오래 걸릴 경우 메시지가 표시될 수 있습니다. 이 메시지를 그냥 무시하거나 gcloud sql operations wait 명령어를 실행해서 메시지를 닫아도 됩니다.
업그레이드 작업 이름을 가져옵니다.

gcloud sql operations list 명령어를 --instance 플래그와 함께 사용합니다.

명령어를 실행하기 전 INSTANCE_NAME 변수를 인스턴스 이름으로 바꿉니다.
```
gcloud sql operations list --instance=INSTANCE_NAME
```
업그레이드 상태를 모니터링합니다.

gcloud sql operations describe 명령어를 사용합니다.

명령어를 실행하기 전 OPERATION 변수를 이전 단계에서 가져온 업그레이드 작업 이름으로 바꿉니다.
```
gcloud sql operations describe OPERATION
```

REST v1

인플레이스 업그레이드를 시작합니다.

instances:patch 메서드와 함께 PATCH 요청을 사용합니다.

요청 데이터를 사용하기 전에 다음 변수를 바꿉니다.
- project_id: 프로젝트의 ID입니다.
- instance_name: 인스턴스 이름.
HTTP 메서드 및 URL:
```
POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance_name
```
JSON 요청 본문:
```
{
  "databaseVersion": enum DATABASE_VERSION
}
```
DATABASE_VERSION을 데이터베이스 주 버전의 열거형으로 바꿉니다. 현재 버전보다 커야 합니다. 사용 가능한 데이터베이스 버전 열거형을 참조하세요.

curl 또는 PowerShell을 사용하여 요청을 전송합니다. 인스턴스 수정을 참조하세요.
업그레이드 작업 이름을 가져옵니다.

project_id를 프로젝트 ID로 바꿔서 operations.list 메서드와 함께 GET 요청을 사용합니다.

HTTP 메서드 및 URL:
```
GET https://sqladmin.googleapis.com/v1/projects/project-id/operations
```
업그레이드 상태를 모니터링합니다.

다음 변수를 바꾸고 operations.get 메서드와 함께 GET 요청을 사용합니다.
- project_id: 프로젝트의 ID입니다.
- operation_name: 이전 단계에서 가져온 업그레이드 작업 이름입니다.
HTTP 메서드 및 URL:
```
GET https://sqladmin.googleapis.com/v1/projects/project-id/operation/operation_name
```

Terraform

데이터베이스 버전을 업데이트하려면 Terraform 리소스 및 Google Cloud용 Terraform 제공업체 버전 4.34.0 이상을 사용합니다.

resource "google_sql_database_instance" "instance" {
  name             = "sqlserver-instance"
  region           = "us-central1"
  database_version = "SQLSERVER_2019_STANDARD"
  root_password    = "INSERT-PASSWORD-HERE"
  settings {
    tier = "db-custom-2-7680"
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

변경사항 적용

Google Cloud 프로젝트에 Terraform 구성을 적용하려면 다음 섹션의 단계를 완료하세요.

Cloud Shell 준비

Cloud Shell을 실행합니다.
Terraform 구성을 적용할 기본 Google Cloud 프로젝트를 설정합니다.

이 명령어는 프로젝트당 한 번만 실행하면 되며 어떤 디렉터리에서도 실행할 수 있습니다.
```
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
```
Terraform 구성 파일에서 명시적 값을 설정하면 환경 변수가 재정의됩니다.

디렉터리 준비

각 Terraform 구성 파일에는 자체 디렉터리(루트 모듈이라고도 함)가 있어야 합니다.

Cloud Shell에서 디렉터리를 만들고 해당 디렉터리 내에 새 파일을 만드세요. 파일 이름에는 .tf 확장자가 있어야 합니다(예: main.tf). 이 튜토리얼에서는 파일을 main.tf라고 합니다.
```
mkdir DIRECTORY && cd DIRECTORY && touch main.tf
```
튜토리얼을 따라 하는 경우 각 섹션이나 단계에서 샘플 코드를 복사할 수 있습니다.

샘플 코드를 새로 만든 main.tf에 복사합니다.

필요한 경우 GitHub에서 코드를 복사합니다. 이는 Terraform 스니펫이 엔드 투 엔드 솔루션의 일부인 경우에 권장됩니다.
환경에 적용할 샘플 매개변수를 검토하고 수정합니다.
변경사항을 저장합니다.
Terraform을 초기화합니다. 이 작업은 디렉터리당 한 번만 수행하면 됩니다.
```
terraform init
```
원하는 경우 최신 Google 공급업체 버전을 사용하려면 -upgrade 옵션을 포함합니다.
```
terraform init -upgrade
```

변경사항 적용

구성을 검토하고 Terraform에서 만들거나 업데이트할 리소스가 예상과 일치하는지 확인합니다.
```
terraform plan
```
필요에 따라 구성을 수정합니다.
다음 명령어를 실행하고 프롬프트에 yes를 입력하여 Terraform 구성을 적용합니다.
```
terraform apply
```
Terraform에 '적용 완료' 메시지가 표시될 때까지 기다립니다.
결과를 보려면 Google Cloud 프로젝트를 엽니다. Google Cloud 콘솔에서 UI의 리소스로 이동하여 Terraform이 리소스를 만들었거나 업데이트했는지 확인합니다.

변경사항 삭제

변경사항을 삭제하려면 다음 단계를 따르세요.

Terraform 구성 파일에서 삭제 보호를 사용 중지하려면 deletion_protection 인수를 false로 설정합니다.
```
deletion_protection =  "false"
```
다음 명령어를 실행하고 프롬프트에 yes를 입력하여 업데이트된 Terraform 구성을 적용합니다.
```
terraform apply
```

다음 명령어를 실행하고 프롬프트에 yes를 입력하여 이전에 Terraform 구성에 적용된 리소스를 삭제합니다.
```
terraform destroy
```

인플레이스 업그레이드 요청을 실행하면 Cloud SQL이 먼저 업그레이드 전 검사를 수행합니다. Cloud SQL에서 인스턴스 업그레이드가 준비되지 않은 것으로 확인되면 업그레이드 요청이 실패하고 문제 해결 방법을 추천하는 메시지가 표시됩니다. 또한 주 버전 업그레이드 문제 해결을 참조하세요.

자동 업그레이드 백업

주 버전 업그레이드를 수행할 때 Cloud SQL은 업그레이드 백업이라고 부르는 2개의 주문형 백업을 자동으로 만듭니다.

첫 번째 업그레이드 백업은 업그레이드 시작 직전에 수행되는 업그레이드 전 백업입니다. 이 백업을 사용하면 데이터베이스 인스턴스를 이전 버전 상태로 복원할 수 있습니다.
두 번째 업그레이드 백업은 업그레이드된 데이터베이스 인스턴스에서 새로운 쓰기 작업이 허용되는 즉시 수행되는 업그레이드 후 백업입니다.

백업 목록을 보면 업그레이드 백업이 On-demand 유형으로 나열된 것을 알 수 있습니다. 업그레이드 백업은 이렇게 쉽게 식별할 수 있도록 라벨이 지정되어 있습니다. 예를 들어 SQL Server Enterprise 2017에서 SQL Server Enterprise 2019로 업그레이드할 때 업그레이드 전 백업에는 Pre-upgrade backup, SQLSERVER_2017_ENTERPRISE to SQLSERVER_2019_ENTERPRISE. 라벨이 지정되고 업그레이드 후 백업에는 Post-upgrade backup, SQLSERVER_2019_ENTERPRISE from SQLSERVER_2017_ENTERPRISE. 라벨이 지정됩니다.

다른 주문형 백업에서와 같이 백업을 삭제하거나 인스턴스를 삭제할 때까지 업그레이드 백업이 보존됩니다.

데이터베이스 호환성 수준 업그레이드

데이터베이스 호환성 수준에 따라 지원되는 애플리케이션과 관련된 데이터베이스의 작동 방식이 결정됩니다. 데이터베이스 호환성 수준 설정은 이전 SQL Server 버전과의 하위 호환성을 보장하며 Transact-SQL 및 쿼리 최적화 도구의 변경사항과 관련이 있습니다. SQL Server 인스턴스 데이터베이스 버전을 업그레이드할 때는 기존 데이터베이스의 호환성 수준이 보존되므로, 애플리케이션이 최신 SQL Server 버전에서도 계속 작동할 수 있습니다. 호환성 수준을 업그레이드하면 새 기능, 쿼리 처리 향상 기능, 기타 변경사항의 이점을 활용할 수 있습니다.

인스턴스의 데이터베이스 엔진 버전을 업그레이드한 후에는 데이터베이스로 지원되는 애플리케이션이 준비되었을 때 인스턴스에서 각 데이터베이스의 데이터베이스 호환성 수준을 업그레이드합니다. 호환성 수준이 최신으로 설정된 경우 최신 기능 및 향상된 성능으로 데이터베이스가 업그레이드됩니다.

데이터베이스 호환성 수준을 업그레이드하려면 다음 단계를 수행합니다.

데이터베이스의 현재 호환성 수준을 확인합니다.

예를 들어 SQL Server 2017의 경우에는 기본 호환성 수준이 140입니다. 데이터베이스의 현재 호환성 수준을 확인하려면 Transact-SQL에서 다음 명령어를 실행합니다. 이때DATABASE_NAME을

SQL Server 인스턴스의 데이터베이스 이름으로 바꿉니다.
```
USE DATABASE_NAME
GO
SELECT compatibility_level
FROM sys.databases WHERE name = 'DATABASE_NAME'
```
대상 호환성 수준을 결정합니다.

업그레이드한 데이터베이스 버전의 기본 호환성 수준 지정을 확인하여 데이터베이스의 대상 호환성 수준을 결정합니다. 예를 들어 SQL Server 2022의 경우에는 기본 호환성 수준이 160입니다. SQL Server 새 버전의 호환성 수준 비교 표를 참조하세요.
현재 호환성 수준과 대상 호환성 수준 사이의 차이를 평가합니다.

호환성 수준을 업그레이드하기 전 현재 호환성 수준과 대상 호환성 수준 사이의 시스템 동작 차이를 조사합니다. 호환성 수준 간의 전체 차이점 목록을 참조하세요.
워크로드 데이터의 기준을 수집합니다.

호환성 수준을 업그레이드하기 전 나중에 회귀 쿼리를 식별하고 해결할 수 있도록 SQL Server 쿼리 저장소를 사용하여 워크로드 데이터 기준을 수집합니다. 쿼리 저장소를 사용해서 일반 비즈니스 주기에 따라 쿼리 및 계획을 캡처하여 성능 기준을 설정합니다. 안내식 워크플로가 필요하면 SQL Server Management Studio에서 Query Tuning Assistant 기능을 사용합니다.
호환성 수준을 업그레이드합니다.

데이터베이스의 호환성 수준을 변경하려면 Transact-SQL에서 다음 명령어를 실행합니다. 이때 DATABASE_NAME을

SQL Server 인스턴스의 데이터베이스 이름으로 바꾸고 TARGET_COMPATIBILITY_LEVEL은 대상 호환성 수준으로 바꿉니다.
```
ALTER DATABASE DATABASE_NAME
SET COMPATIBILITY_LEVEL = TARGET_COMPATIBILITY_LEVEL;
GO
```
업그레이드된 워크로드 데이터를 수집합니다.

비교 및 회귀 감지를 위해 쿼리 저장소를 사용해서 업그레이드된 워크로드 데이터를 수집합니다.
회귀 쿼리를 해결합니다.

대부분의 경우 업그레이드된 호환성 수준에서는 쿼리 최적화 도구 변경으로 인해 성능이 향상됩니다. 하지만 경우에 따라 일부 쿼리는 성능이 회귀될 수 있습니다. 쿼리 저장소의 회귀 쿼리 기능은 회귀된 쿼리를 식별하고 마지막으로 알려진 정상 쿼리 계획을 강제 적용할 수 있게 해줍니다. SQL Server는 또한 쿼리 회귀가 발생할 때 마지막으로 알려진 정상 계획으로 자동 전환할 수 있는 자동 계획 수정 기능을 제공합니다.

주 버전 업그레이드 완료

기본 인스턴스 업그레이드를 완료한 후에는 업그레이드된 시스템이 예상한 대로 작동하는지 확인하기 위해 수락 테스트를 수행합니다.

주 버전 업그레이드 문제 해결

예를 들어 인스턴스에 새 버전에 대한 잘못된 데이터베이스 플래그가 포함된 경우 등 잘못된 업그레이드 명령어를 시도하면 Cloud SQL에서 오류 메시지가 반환됩니다.

업그레이드 요청이 실패하면 업그레이드 요청의 문법을 확인합니다. 요청의 구조가 유효하다면 다음 추천 조치를 살펴보세요.

업그레이드 로그 보기

업그레이드 요청이 올바른 경우에도 문제가 발생하면 Cloud SQL이 projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fsqlserver.err에 오류 로그를 게시합니다. 각 로그 항목에는 업그레이드 오류가 발생한 인스턴스를 식별할 수 있도록 인스턴스 식별자와 함께 라벨이 포함되어 있습니다. 이러한 업그레이드 오류를 찾아 해결합니다.

오류 로그를 보려면 다음 단계를 따르세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
인스턴스의 개요 페이지를 열려면 인스턴스 이름을 클릭합니다.
인스턴스 개요 페이지의 작업 및 로그 창에서 SQL Server 오류 로그 보기 링크를 클릭합니다.

로그 탐색기 페이지가 열립니다.
다음과 같이 로그를 확인합니다.
- 한 프로젝트의 모든 오류 로그를 나열하려면 로그 이름 로그 필터에서 로그 이름을 선택합니다.
쿼리 필터에 대한 자세한 내용은 고급 쿼리를 참조하세요.
- 단일 인스턴스의 업그레이드 오류 로그를 필터링하려면 모든 필드 검색 상자에 다음 쿼리를 입력합니다. 이때 DATABASE_ID를
프로젝트 ID와 인스턴스 이름으로 바꿉니다. 형식은 project_id:instance_name과 같습니다.
```
resource.type="cloudsql_database"
resource.labels.database_id="DATABASE_ID"
logName : "projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fsqlserver.err"
```
예를 들어 buylots 프로젝트에서 실행되는 인스턴스 이름 shopping-db로 업그레이드 오류 로그를 필터링하려면 다음 쿼리 필터를 사용합니다.
```
 resource.type="cloudsql_database"
 resource.labels.database_id="buylots:shopping-db"
 logName : "projects/buylots/logs/cloudsql.googleapis.com%2Fsqlserver.err"
```

이전 주 버전으로 복원

업그레이드된 데이터베이스 시스템이 예상한 대로 작동하지 않으면 인스턴스를 이전 버전으로 복원해야 할 수 있습니다. 이렇게 하려면 업그레이드 전 버전을 실행하는 새 인스턴스인 Cloud SQL 복구 인스턴스로 업그레이드 전 백업을 복원합니다.

이전 버전으로 복원하려면 다음 단계를 수행합니다.

업그레이드 전 백업을 식별합니다.

자동 업그레이드 백업을 참조하세요.
복구 인스턴스를 만듭니다.

업그레이드 전 백업이 수행될 때 Cloud SQL에서 실행하던 주 버전을 사용하여 새 Cloud SQL 인스턴스를 만듭니다. 원래 인스턴스에서 사용되는 동일한 플래그 및 인스턴스 설정을 지정합니다.
업그레이드 전 백업을 복원합니다.

업그레이드 전 백업을 복구 인스턴스로 복원합니다. 완료되는 데 몇 분 정도 걸릴 수 있습니다.
읽기 복제본을 추가합니다.

읽기 복제본을 사용하는 경우 이를 개별적으로 추가합니다.
애플리케이션을 연결합니다.

데이터베이스 시스템이 복구되었으면 복구 인스턴스 및 읽기 복제본에 대한 세부정보로 애플리케이션을 업데이트합니다. 데이터베이스의 업그레이드 전 버전에서 트래픽 제공을 재개할 수 있습니다.

제한사항

이 섹션에서는 인플레이스(In-Place) 메이저 버전 업그레이드에 대한 제한사항을 설명합니다.

외부 복제본에서는 인플레이스 주 버전 업그레이드를 수행할 수 없습니다.

FAQ

데이터베이스 주 버전을 업그레이드할 때는 다음과 같은 질문을 고려해야 할 수 있습니다.

업그레이드 중에 인스턴스를 사용할 수 없나요?: 예. Cloud SQL이 업그레이드를 수행하는 동안 인스턴스를 사용할 수 없습니다.

업그레이드하는 데 시간이 얼마나 걸리나요?

단일 인스턴스를 업그레이드할 때는 일반적으로 10분 미만이 걸립니다. 인스턴스 구성에서 소량의 vCPU 또는 메모리를 사용하는 경우 업그레이드 시간이 길어질 수 있습니다.

업그레이드 시간은 데이터베이스의 객체 수에 상응하므로 인스턴스에서 데이터베이스 또는 테이블을 너무 많이 호스팅하거나 데이터베이스가 매우 큰 경우 업그레이드에 몇 시간이 걸리거나 타임아웃이 발생할 수도 있습니다. 업그레이드해야 하는 인스턴스가 여러 개인 경우 그에 비례하여 총 업그레이드 시간이 증가합니다.

업그레이드 프로세스에서 각 단계를 모니터링할 수 있나요?: Cloud SQL에서는 업그레이드 작업이 진행 중인지 여부를 모니터링할 수 있지만, 각 업그레이드의 개별 단계는 추적할 수 없습니다.

업그레이드를 시작한 후 취소할 수 있나요?: 아니요. 업그레이드가 시작된 다음에는 이를 취소할 수 없습니다. 업그레이드가 실패하면 Cloud SQL이 인스턴스를 이전 버전으로 자동으로 복구합니다.

업그레이드 도중 내 설정은 어떻게 되나요?

인플레이스 주 버전 업그레이드를 수행하는 경우에는 인스턴스 이름, IP 주소, 명시적으로 구성된 플래그 값, 사용자 데이터와 같은 데이터베이스 설정이 Cloud SQL에서 보존됩니다. 그러나 시스템 변수의 기본값은 변경될 수 있습니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요. 특정 플래그 또는 값이 대상 버전에서 더 이상 지원되지 않는 경우에는 Cloud SQL에서 업그레이드하는 동안 해당 플래그가 자동으로 삭제됩니다.