Backup for GKE를 사용하여 Persistent Disk에서 Hyperdisk로 MySQL 데이터 마이그레이션

Autopilot Standard

이 튜토리얼에서는 GKE용 백업을 사용하여 GKE의 스테이트풀 애플리케이션을 연결된 영구 디스크 볼륨이 있는 N2와 같은 이전 세대 머신 유형에서 연결된 Hyperdisk 볼륨이 있는 N4와 같은 최신 세대 머신 유형으로 이전하는 방법을 보여줍니다. Hyperdisk를 지원하는 머신 유형에 대한 자세한 내용은 Compute Engine 문서를 참고하세요.

이 튜토리얼에서는 이전 작업을 보여주기 위해 Sakila 데이터베이스와 World 데이터베이스를 사용하여 샘플 데이터 세트를 제공합니다. Sakila는 가상의 DVD 대여점을 나타내는 MySQL에서 제공하는 샘플 데이터베이스입니다. World 데이터베이스에는 국가 및 도시에 관한 데이터가 포함되어 있습니다. 이 튜토리얼에서는 별도의 네임스페이스에서 두 개의 서로 다른 데이터 세트를 사용하여 복잡한 멀티 테넌트 환경을 시뮬레이션합니다.

이 튜토리얼은 스토리지를 만들고 할당하며 데이터 보안 및 데이터 액세스를 관리하는 스토리지 전문가와 스토리지 관리자를 대상으로 합니다. Google Cloud콘텐츠에서 참조하는 일반적인 역할 및 예시 태스크에 대해 자세히 알아보려면 일반 GKE 사용자 역할 및 태스크를 참고하세요.

하이퍼디스크로 마이그레이션해야 하는 이유

하이퍼디스크는 Google의 고성능 블록 스토리지로, 영구 디스크에 비해 IOPS와 처리량이 훨씬 높습니다. 이러한 성능 향상은 MySQL 데이터베이스와 같은 I/O 집약적 상태 저장 애플리케이션에 매우 중요합니다. 하지만 Hyperdisk는 N4와 같은 최신 머신 세대에서만 지원됩니다. 하이퍼디스크로 마이그레이션하려면 워크로드를 새 노드 풀 또는 클러스터로 이동해야 합니다.

Backup for GKE를 사용해야 하는 이유

디스크 스냅샷을 사용하여 이전할 수 있지만 Backup for GKE는 선언적이고 자동화된 접근 방식을 제공합니다. 마이그레이션의 주요 기능은 변환 규칙으로, 다음 작업을 할 수 있습니다.

복원 중에 PersistentVolumeClaim (PVC)의 StorageClass을 Persistent Disk에서 Hyperdisk로 동적으로 변경합니다.
배포와 같은 Kubernetes 매니페스트를 업데이트하여 Hyperdisk에 필요한 새 N4 머신 유형을 타겟팅합니다.

이 메서드는 비밀번호와 구성을 포함한 애플리케이션 상태를 백업하고 수정된 인프라 요구사항이 있는 새 환경으로 복원하는 오케스트레이션을 처리하여 수동 오류를 최소화하는 데 도움이 됩니다.

배포 아키텍처

다음 다이어그램은 Backup for GKE를 사용하여 스테이트풀(Stateful) MySQL 워크로드를 N2 머신 유형의 영구 디스크에서 N4 머신 유형의 Hyperdisk로 이전하는 프로세스를 보여줍니다.

원본 클러스터: 두 MySQL 배포가 N2 머신 시리즈 노드 풀의 별도 네임스페이스(namespace-a 및 namespace-b)에 있습니다. 이러한 배포는 데이터 저장에 SSD 영구 디스크를 사용합니다.
백업 전략: 클러스터에서 Backup for GKE 에이전트를 사용 설정하고 네임스페이스, 볼륨 데이터, 보안 비밀을 캡처하는 백업 계획을 만듭니다. 그런 다음 수동 백업을 실행하여 특정 시점 복구 지점을 만듭니다.
변환 및 복원: 변환 규칙을 사용하여 대상 환경에 맞게 리소스를 조정하여 복원 계획을 정의합니다. 이러한 규칙은 다음을 수행합니다.
- premium-rwo (PD)에서 balanced-storage라는 Hyperdisk 스토리지 클래스로 StorageClass를 스왑합니다.
- 복원된 워크로드가 새 N4 노드 풀에 예약되도록 포드 어피니티 규칙을 수정합니다.
타겟 환경: N4 머신 유형으로 새 GKE 클러스터를 프로비저닝합니다. 복원 프로세스는 백업에서 디스크를 하이퍼디스크 볼륨으로 다시 만들고 호환되는 N4 노드에 MySQL 인스턴스를 배포합니다.

Backup for GKE를 사용하여 Persistent Disk에서 Hyperdisk로 MySQL 데이터를 마이그레이션하는 방법을 보여주는 아키텍처 다이어그램 — **그림 1**: Backup for GKE를 사용하여 Persistent Disk에서 Hyperdisk로 MySQL 데이터 마이그레이션

목표

이 튜토리얼에서는 다음 작업을 수행하는 방법을 알아봅니다.

백업을 위해 GKE 스테이트풀 애플리케이션을 준비합니다.
Backup for GKE 부가기능을 사용 설정합니다.
백업 계획을 만들고 소스 클러스터를 백업합니다.
변환 규칙을 사용하여 스토리지를 Hyperdisk로 이전하는 복원 계획을 만듭니다.
새 클러스터로 워크로드를 복원하고 데이터를 확인합니다.

비용

이 문서에서는 비용이 청구될 수 있는 Google Cloud구성요소를 사용합니다.

GKE
Compute Engine (Persistent Disk and Hyperdisk)
Backup for GKE

프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요.

Google Cloud 신규 사용자는 무료 체험판을 사용할 수 있습니다.

시작하기 전에

Google Cloud 계정에 로그인합니다. Google Cloud를 처음 사용하는 경우 계정을 만들고 Google 제품의 실제 성능을 평가해 보세요. 신규 고객에게는 워크로드를 실행, 테스트, 배포하는 데 사용할 수 있는 $300의 무료 크레딧이 제공됩니다.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Compute Engine, GKE, Backup for GKE, and IAM APIs.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the APIs

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Compute Engine, GKE, Backup for GKE, and IAM APIs.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the APIs

프로젝트에 다음 역할이 있는지 확인합니다. roles/container.admin, roles/iam.serviceAccountAdmin, roles/compute.admin, roles/gkebackup.admin, roles/monitoring.viewer
역할 확인
1. Google Cloud 콘솔에서 IAM 페이지로 이동합니다.
  IAM으로 이동
2. 프로젝트를 선택합니다.
3. 주 구성원 열에서 나 또는 내가 속한 그룹을 식별하는 모든 행을 찾습니다. 내가 속한 그룹을 알아보려면 관리자에게 문의하세요.
4. 나를 지정하거나 포함하는 모든 행의 역할 열을 확인하여 역할 목록에 필요한 역할이 포함되어 있는지 확인합니다.
역할 부여
1. Google Cloud 콘솔에서 IAM 페이지로 이동합니다.
  IAM으로 이동
2. 프로젝트를 선택합니다.
3. 액세스 권한 부여를 클릭합니다.
4. 새 주 구성원 필드에 사용자 식별자를 입력합니다. 일반적으로 Google 계정의 이메일 주소입니다.
5. 역할 선택을 클릭한 후 역할을 검색합니다.
6. 역할을 추가로 부여하려면 다른 역할 추가를 클릭하고 각 역할을 추가합니다.
7. 저장을 클릭합니다.

Cloud Shell 설정

Google Cloud 콘솔에서 Cloud Shell을 활성화합니다.

Cloud Shell 활성화

Cloud Shell 세션이 시작되면 명령줄 프롬프트가 표시됩니다. 세션이 초기화되는 데 몇 초 정도 걸릴 수 있습니다.
기본 프로젝트를 설정합니다.
```
  gcloud config set project PROJECT_ID
```
PROJECT_ID를 프로젝트 ID로 바꿉니다.

환경 설정

이 섹션에서는 환경 변수를 준비하고 샘플 저장소를 클론합니다.

프로젝트, 클러스터 이름, 영역의 환경 변수를 설정합니다.

export PROJECT_ID=PROJECT_ID
export KUBERNETES_CLUSTER_PREFIX=backup-gke-migration
export TARGET_CLUSTER_PREFIX=restore-gke-migration
export ZONE=us-central1-a

PROJECT_ID를 Google Cloud프로젝트 ID로 바꿉니다.

샘플 코드 저장소를 클론하고 디렉터리로 이동합니다.

git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
cd kubernetes-engine-samples/databases/backup-migration

소스 GKE 클러스터 만들기

N2 머신 유형을 사용하고 영구 디스크 볼륨이 연결된 노드 풀로 영역 클러스터를 만듭니다.

클러스터를 만듭니다.

gcloud container clusters create ${KUBERNETES_CLUSTER_PREFIX}-cluster \
  --location ${ZONE} \
  --node-locations ${ZONE} \
  --shielded-secure-boot \
  --shielded-integrity-monitoring \
  --machine-type "e2-micro" \
  --num-nodes "1"

소스 워크로드에 n2-standard-4 머신 유형으로 노드 풀을 만듭니다.

gcloud container node-pools create regular-pool \
  --cluster ${KUBERNETES_CLUSTER_PREFIX}-cluster \
  --machine-type n2-standard-4 \
  --zone ${ZONE} \
  --num-nodes 1

소스 클러스터에서 Backup for GKE 부가기능을 사용 설정합니다.

gcloud container clusters update ${KUBERNETES_CLUSTER_PREFIX}-cluster \
  --project=${PROJECT_ID}  \
  --location=${ZONE} \
  --update-addons=BackupRestore=ENABLED

클러스터의 사용자 인증 정보를 가져옵니다.

gcloud container clusters get-credentials ${KUBERNETES_CLUSTER_PREFIX}-cluster --zone ${ZONE}

Backup for GKE 에이전트가 사용 설정되어 있는지 확인합니다.

gcloud container clusters describe ${KUBERNETES_CLUSTER_PREFIX}-cluster \
  --project=${PROJECT_ID}  \
  --location=${ZONE}

출력은 다음과 유사하며 백업 에이전트가 사용 설정되어 있음을 확인합니다.

addonsConfig:
  gkeBackupAgentConfig:
    enabled: true

샘플 데이터로 MySQL 배포

별도의 네임스페이스에 두 개의 MySQL 데이터베이스를 배포하여 프로덕션 환경을 시뮬레이션합니다.

namespace-a 및 namespace-b 네임스페이스를 만듭니다.

kubectl create namespace namespace-a
kubectl create namespace namespace-b

namespace-a 및 namespace-b에 MySQL 워크로드를 배포합니다.

mysql-a-deployment.yaml 파일을 배포합니다.

kubectl apply -f manifests/02-mysql/mysql-a-deployment.yaml -n namespace-a

다음 매니페스트는 regular-pool 노드에 동적으로 프로비저닝된 Persistent Disk SSD 디스크가 있는 namespace-a에 MySQL 포드를 만듭니다. 루트 비밀번호가 migration로 설정됩니다.

apiVersion: v1
kind: Service
metadata:
  name: mysql-a
  labels:
    app: mysql
spec:
  ports:
    - port: 3306
  selector:
    app: mysql
  clusterIP: None
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-a-pv-claim
  labels:
    app: mysql
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 30Gi
  storageClassName: premium-rwo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: existing-mysql-a
  labels:
    app: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - image: mysql:8.0
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: migration
        - name: MYSQL_DATABASE
          value: mysql
        - name: MYSQL_USER
          value: app
        - name: MYSQL_PASSWORD
          value: migration
        ports:
        - containerPort: 3306
          name: mysql-a
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      affinity: 
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: "node.kubernetes.io/instance-type"
                operator: In  
                values:
                - "n2-standard-4"
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-a-pv-claim

mysql-b-deployment.yaml 파일을 배포합니다.

kubectl apply -f manifests/02-mysql/mysql-b-deployment.yaml -n namespace-b

다음 매니페스트는 regular-pool 노드에 동적으로 프로비저닝된 Persistent Disk SSD 디스크가 있는 namespace-b에 MySQL 포드를 만듭니다. 루트 비밀번호가 migration로 설정됩니다.

apiVersion: v1
kind: Service
metadata:
  name: mysql-b
  labels:
    app: mysql
spec:
  ports:
    - port: 3306
  selector:
    app: mysql
  clusterIP: None
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-b-pv-claim
  labels:
    app: mysql
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 30Gi
  storageClassName: premium-rwo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: existing-mysql-b
  labels:
    app: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - image: mysql:8.0
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: migration
        - name: MYSQL_DATABASE
          value: mysql
        - name: MYSQL_USER
          value: app
        - name: MYSQL_PASSWORD
          value: migration
        ports:
        - containerPort: 3306
          name: mysql-b
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      affinity: 
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: "node.kubernetes.io/instance-type"
                operator: In
                values:
                - "n2-standard-4"
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-b-pv-claim

MySQL 클라이언트 포드를 배포하여 샘플 데이터 세트를 업로드합니다.

kubectl apply -f manifests/02-mysql/mysql-client.yaml
kubectl wait pods mysql-client --for condition=Ready --timeout=300s

다음 매니페스트는 MySQL 클라이언트 포드를 배포합니다.

apiVersion: v1
kind: Pod
metadata:
  name: mysql-client
spec:
  containers:
  - name: main
    image: mysql:8.0
    command: ["sleep", "360000"]
    resources:
      requests:
        memory: 1Gi
        cpu: 500m
      limits:
        memory: 1Gi
        cpu: "1"
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: migration

클라이언트 포드에 연결합니다.
```
kubectl exec -it mysql-client -- bash
```

포드 내에서 Sakila 및 World 샘플 데이터 세트를 다운로드합니다.

curl --output dataset.tgz "https://downloads.mysql.com/docs/sakila-db.tar.gz"
tar -xvzf dataset.tgz -C ./

curl --output world-db.tar.gz "https://downloads.mysql.com/docs/world-db.tar.gz"
tar xvzf world-db.tar.gz -C ./

Sakila 데이터 세트를 mysql-a 데이터베이스로 가져옵니다.

mysql -u root -h mysql-a.namespace-a -p
# Enter password: migration

SOURCE /sakila-db/sakila-schema.sql;
SOURCE /sakila-db/sakila-data.sql;

가져온 Sakila 데이터를 확인합니다.

USE sakila;
SELECT table_name, table_rows FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'sakila';

MySQL을 종료합니다.

exit

mysql-b 데이터베이스로 World 데이터 세트를 가져옵니다.

mysql -u root -h mysql-b.namespace-b -p
# Enter password: migration

SOURCE /world-db/world.sql;

가져온 World 데이터를 확인합니다.

USE world;
SELECT table_name, table_rows FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'world';

출력은 다음과 비슷합니다.

+-----------------+------------+
| table_name      | table_rows |
+-----------------+------------+
| city            |       4079 |
| country         |        239 |
| countrylanguage |        984 |
+-----------------+------------+

MySQL을 종료합니다.

exit

클라이언트 포드 셸을 종료합니다.
```
exit
```

GKE 클러스터 백업

보안 비밀과 볼륨을 포함한 전체 클러스터를 백업합니다.

백업 계획을 만듭니다.
```
gcloud beta container backup-restore backup-plans create main-plan \
  --project=${PROJECT_ID} \
  --location=us-central1 \
  --cluster=projects/${PROJECT_ID}/locations/${ZONE}/clusters/${KUBERNETES_CLUSTER_PREFIX}-cluster \
  --selected-namespaces=namespace-a,namespace-b,default \
  --include-secrets \
  --include-volume-data \
  --target-rpo-minutes=1440 \
  --backup-retain-days=7 \
  --backup-delete-lock-days=3 \
  --locked
```
- --selected-namespaces: 시스템 리소스와의 충돌을 방지하기 위해 특정 네임스페이스를 백업합니다.
- --include-volume-data: 영구 디스크 데이터가 백업되도록 지원합니다.
- --target-rpo-minutes: 복구 지점 목표(RPO) 기반 백업 일정을 구성합니다. RPO는 데이터가 손실될 수 있는 최대 허용 시간이며 백업 빈도를 결정합니다. 1440분 (1일)으로 설정하면 백업이 매일 실행되도록 예약됩니다.

백업을 만듭니다.

gcloud beta container backup-restore backups create first-backup \
    --project=${PROJECT_ID} \
    --location=us-central1 \
    --backup-plan=main-plan \
    --wait-for-completion

출력에 Backup state: SUCCEEDED이 표시될 때까지 기다립니다.

백업이 생성되었는지 확인합니다.

gcloud beta container backup-restore backups list \
    --project=${PROJECT_ID} \
    --location=us-central1 \
    --backup-plan=main-plan

Hyperdisk 변환으로 복원

백업을 새 클러스터로 복원합니다. 복원하면 스토리지가 영구 디스크에서 하이퍼디스크로 변환되고 워크로드가 N4 노드로 이동합니다.

N4 노드에 타겟 GKE 클러스터를 만듭니다.

gcloud container clusters create ${TARGET_CLUSTER_PREFIX}-cluster \
  --location ${ZONE} \
  --node-locations ${ZONE} \
  --shielded-secure-boot \
  --shielded-integrity-monitoring \
  --machine-type "e2-micro" \
  --num-nodes "1"

Hyperdisk에 필요한 n4-standard-4 머신 유형으로 노드 풀을 만듭니다.

gcloud container node-pools create hyperdisk-pool \
  --cluster ${TARGET_CLUSTER_PREFIX}-cluster \
  --machine-type n4-standard-4 \
  --zone ${ZONE} \
  --num-nodes 1

타겟 클러스터의 사용자 인증 정보를 가져옵니다.

gcloud container clusters get-credentials ${TARGET_CLUSTER_PREFIX}-cluster --zone ${ZONE}

balanced-storage라는 하이퍼디스크 StorageClass를 적용합니다.

kubectl apply -f manifests/01-storage-class/storage-class-hdb.yaml

다음 매니페스트는 Hyperdisk StorageClass를 정의합니다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: balanced-storage
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: hyperdisk-balanced
  provisioned-throughput-on-create: "250Mi"
  provisioned-iops-on-create: "7000"

manifests/03-transformation-rule/volume.yaml 파일에서 변환 규칙을 검토합니다. 이 파일은 복원 중에 리소스가 수정되는 방식을 정의합니다.

transformationRules:
- description: Change the StorageClass on PVCs from premium-rwo to balanced-storage
  resourceFilter:
    namespaces: ["namespace-a","namespace-b"]
    groupKinds:
    - resourceGroup: ""
      resourceKind: PersistentVolumeClaim
  fieldActions:
  - op: REPLACE
    path: "/spec/storageClassName"
    value: "balanced-storage"
- description: Change node type from n2-standard-4 to n4-standard-4
  resourceFilter:
    namespaces: ["namespace-a","namespace-b"]
    jsonPath: ".metadata[?(@.name == 'existing-mysql')]"
    groupKinds:
    - resourceGroup: apps
      resourceKind: Deployment
  fieldActions:
  - op: REPLACE
    path: "/spec/template/spec/affinity/nodeAffinity/preferredDuringSchedulingIgnoredDuringExecution/0/preference/matchExpressions/0/values/0"
    value: "n4-standard-4"

PVC 변환: storageClassName을 balanced-storage (Hyperdisk)로 변경합니다.
배포 변환: n4-standard-4 노드에 포드를 예약하도록 노드 어피니티를 업데이트합니다.

다음 변환 규칙을 사용하여 복원 계획을 만듭니다.

gcloud beta container backup-restore restore-plans create main-restore \
  --project=${PROJECT_ID} \
  --location=us-central1 \
  --backup-plan=projects/${PROJECT_ID}/locations/us-central1/backupPlans/main-plan \
  --cluster=projects/${PROJECT_ID}/locations/${ZONE}/clusters/${TARGET_CLUSTER_PREFIX}-cluster \
  --namespaced-resource-restore-mode=merge-replace-on-conflict \
  --all-namespaces \
  --cluster-resource-conflict-policy=use-existing-version  \
  --cluster-resource-scope-selected-group-kinds=cluster-resource-scope-all-group-kinds \
  --volume-data-restore-policy=restore-volume-data-from-backup \
  --transformation-rules-file=manifests/03-transformation-rule/volume.yaml

복원을 실행합니다.

gcloud beta container backup-restore restores create first-restore \
   --project=${PROJECT_ID} \
   --location=us-central1 \
   --restore-plan=main-restore \
   --backup=projects/${PROJECT_ID}/locations/us-central1/backupPlans/main-plan/backups/first-backup

이전 확인

애플리케이션이 새 클러스터에서 실행되고 데이터가 손상되지 않았는지 확인합니다.

포드가 실행 중인지 확인합니다.
```
kubectl get pods -A
```

새 클러스터의 MySQL 클라이언트 포드에 연결합니다.

# Verify that the client Pod is running
kubectl apply -f manifests/02-mysql/mysql-client.yaml
kubectl wait pods mysql-client --for condition=Ready --timeout=300s
kubectl exec -it mysql-client -- bash

namespace-a에서 복원된 Sakila 데이터베이스를 확인합니다.

mysql -u root -h mysql-a.namespace-a -p
# Password: migration

USE sakila;
SELECT table_name, table_rows FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'sakila';

namespace-b에서 복원된 World 데이터베이스를 확인합니다.

mysql -u root -h mysql-b.namespace-b -p
# Password: migration

USE world;
SELECT table_name, table_rows FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'world';

삭제

이 튜토리얼에서 사용된 리소스 비용이 Google Cloud 계정에 청구되지 않도록 하려면 리소스가 포함된 프로젝트를 삭제하거나 프로젝트를 유지하고 개별 리소스를 삭제하세요.

GKE 클러스터를 삭제합니다.

gcloud container clusters delete ${KUBERNETES_CLUSTER_PREFIX}-cluster --location ${ZONE} --quiet
gcloud container clusters delete ${TARGET_CLUSTER_PREFIX}-cluster --location ${ZONE} --quiet

백업 및 복원 계획을 삭제합니다.

# Delete the restore plan
gcloud beta container backup-restore restore-plans delete main-restore \
    --project=${PROJECT_ID} \
    --location=us-central1 \
    --quiet

# Delete the Backup
gcloud beta container backup-restore backups delete first-backup \
    --project=${PROJECT_ID} \
    --location=us-central1 \
    --backup-plan=main-plan \
    --quiet

# Delete the backup plan
gcloud beta container backup-restore backup-plans delete main-plan \
    --project=${PROJECT_ID} \
    --location=us-central1 \
    --quiet

다음 단계

Backup for GKE에 대해 자세히 알아보세요.
Hyperdisk 스토리지 풀에 대해 알아봅니다.

Backup for GKE를 사용하여 Persistent Disk에서 Hyperdisk로 MySQL 데이터 마이그레이션 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

하이퍼디스크로 마이그레이션해야 하는 이유

Backup for GKE를 사용해야 하는 이유

배포 아키텍처

목표

비용

시작하기 전에

역할 확인

역할 부여

Cloud Shell 설정

환경 설정

소스 GKE 클러스터 만들기

샘플 데이터로 MySQL 배포

GKE 클러스터 백업

Hyperdisk 변환으로 복원

이전 확인

삭제

다음 단계

Backup for GKE를 사용하여 Persistent Disk에서 Hyperdisk로 MySQL 데이터 마이그레이션