Google ใช้เทคโนโลยี AI เพื่อแปลเนื้อหาเป็นภาษาที่คุณต้องการ การแปลโดย AI อาจมีข้อผิดพลาด

ติดตั้งใช้งานและจัดการ AlloyDB Omni ใน Kubernetes (GKE หรือคลัสเตอร์ของคุณเอง)

1. บทนำ

ใน Codelab นี้ คุณจะได้เรียนรู้วิธีติดตั้งโอเปอเรเตอร์ AlloyDB Omni Kubernetes (ผู้จัดระเบียบคอนเทนเนอร์) ในคลัสเตอร์ Google Kubernetes Engine (GKE) Autopilot หรือคลัสเตอร์ Kubernetes ของคุณเอง และจัดการเวิร์กโฟลว์วงจรฐานข้อมูลแบบครบวงจรและเส้นทางของผู้ใช้ที่สำคัญ (CUJ)

AlloyDB Omni เป็น AlloyDB รุ่นที่ดาวน์โหลดได้ซึ่งออกแบบมาให้ทำงานได้ทุกที่ ตั้งแต่สภาพแวดล้อมภายในองค์กรไปจนถึง Google Cloud หรือการประมวลผลที่ต้นทาง เมื่อใช้ Container Orchestrator แล้ว AlloyDB Omni จะทำให้ความพร้อมใช้งานสูง, เฟลโอเวอร์อัตโนมัติ, การซ่อมแซมตัวเอง, การบำรุงรักษาแบบต่อเนื่องโดยมีช่วงเวลาที่ระบบหยุดทำงานน้อยที่สุด, การรวมการเชื่อมต่อ, การสำรองข้อมูลอัตโนมัติ และการกู้คืนช่วงเวลาเป็นไปโดยอัตโนมัติ

AlloyDB for PostgreSQL กับ AlloyDB Omni: AlloyDB for PostgreSQL เป็นบริการฐานข้อมูลที่มีการจัดการครบวงจรใน Google Cloud AlloyDB Omni จะรวมเครื่องมือฐานข้อมูล AlloyDB เดียวกันไว้ในคอนเทนเนอร์ที่ดาวน์โหลดได้ ซึ่งคุณสามารถเรียกใช้และดำเนินการเองได้ ไม่ว่าจะเป็นภายในองค์กร, ในระบบคลาวด์สาธารณะอื่นๆ (เช่น Amazon EKS หรือ Azure AKS), ใน OpenShift หรือในเวิร์กสเตชันของนักพัฒนาซอฟต์แวร์ เพื่อให้เป็นไปตามข้อกำหนดด้านถิ่นที่อยู่ของข้อมูล ระบบคลาวด์แบบไฮบริด หรือการพัฒนาในเครื่อง ในการติดตั้งใช้งานจริง โดยทั่วไปคุณจะเรียกใช้โอเปอเรเตอร์ AlloyDB Omni Kubernetes ในคลัสเตอร์ Kubernetes ของคุณเอง (เส้นทางที่ 2) เส้นทางที่ 1 ใช้ GKE Autopilot เป็นแซนด์บ็อกซ์ Kubernetes ที่สะดวกและไม่ต้องตั้งค่าในเครื่องเท่านั้น หากคุณยังไม่มีคลัสเตอร์

เลือกเส้นทางสภาพแวดล้อม

คุณสามารถทำ Codelab นี้ให้เสร็จสมบูรณ์ได้โดยใช้เส้นทางใดเส้นทางหนึ่งต่อไปนี้

เส้นทางที่ 1: มีบัญชี Google Cloud (GKE Autopilot) - จัดสรรคลัสเตอร์ GKE Autopilot ที่มีการจัดการครบวงจรโดยใช้ Google Cloud Shell หรือคอนโซล Google Cloud
เส้นทางที่ 2: ไม่มีบัญชี Google Cloud (นำคลัสเตอร์ Kubernetes ของคุณมาเอง) - ใช้คลัสเตอร์ Kubernetes ที่มีอยู่ (v1.21 ขึ้นไป) โดยกำหนดค่า kubectl และ helm ในเวิร์กสเตชันของคุณ ไม่จำเป็นต้องมีบัญชี Google Cloud หรือ gcloud CLI

ข้อกำหนดเบื้องต้น

มีความคุ้นเคยพื้นฐานกับแนวคิด Kubernetes (kubectl, Helm, Custom Resource Definitions)
สำหรับเส้นทางที่ 1 (Google Cloud / GKE Autopilot):
- โปรเจ็กต์ Google Cloud ที่เปิดใช้การเรียกเก็บเงิน
- สิทธิ์เข้าถึง Google Cloud Shell หรือเวิร์กสเตชันที่กำหนดค่าด้วย gcloud, kubectl และ helm
สำหรับเส้นทางที่ 2 (นำคลัสเตอร์ Kubernetes ของคุณมาเอง):
- คลัสเตอร์ Kubernetes ที่ใช้เวอร์ชัน 1.21 ขึ้นไปพร้อม StorageClass เริ่มต้นสำหรับการจัดสรร PersistentVolume แบบไดนามิก
- โหนด Worker ที่ใช้ Linux kernel 4.18 ขึ้นไปโดยเปิดใช้ cgroup v2 (x86-64/AMD64) และ vCPU อย่างน้อย 8 ตัวและ RAM ที่จัดสรรได้ 24 GiB ทั่วทั้งคลัสเตอร์
- เวิร์กสเตชันที่กำหนดค่าด้วย kubectl และ helm ที่เชื่อมต่อกับคลัสเตอร์ของคุณ

สิ่งที่คุณจะได้เรียนรู้

วิธีจัดสรรคลัสเตอร์ GKE Autopilot (เส้นทางที่ 1) หรือตรวจสอบคลัสเตอร์ Kubernetes ที่มีอยู่ (เส้นทางที่ 2)
วิธีติดตั้ง cert-manager และโอเปอเรเตอร์ AlloyDB Omni Kubernetes ผ่าน Helm
วิธีติดตั้งใช้งาน AlloyDB Omni DBCluster แบบอินสแตนซ์เดียว
วิธีปรับขนาดเป็นความพร้อมใช้งานสูง (HA) ด้วยสแตนด์บายแบบซิงโครนัสและเปิดใช้ความสามารถสแตนด์บายแบบอ่านอย่างเดียว
วิธีกำหนดค่าการสำรองข้อมูลอัตโนมัติตามกำหนดเวลาไปยังพื้นที่เก็บข้อมูลที่เก็บในเครื่อง (และ Google Cloud Storage ในเส้นทางที่ 1 (ไม่บังคับ))
วิธีสำรองข้อมูลตามต้องการและยืนยันการกู้คืนข้อมูลกลับสู่สถานะก่อนหน้า
วิธีดำเนินการกู้คืนช่วงเวลา (PITR) ไปยังคลัสเตอร์ฐานข้อมูลที่โคลนใหม่
วิธีติดตั้งใช้งานพูลการเชื่อมต่อ PgBouncer สำหรับการปรับขนาดการเชื่อมต่อไคลเอ็นต์
วิธีติดตั้งใช้งาน pgAdmin4 เพื่อจัดการและค้นหาฐานข้อมูลแบบเป็นภาพ
วิธีดำเนินการบำรุงรักษาโดยมีช่วงพักน้อย (LDTM) สำหรับการปรับขนาดทรัพยากร CPU และหน่วยความจำ

สิ่งที่ต้องมี

เส้นทางที่ 1: Google Cloud Shell ที่มียูทิลิตี gcloud, kubectl และ helm ติดตั้งไว้ล่วงหน้า
เส้นทางที่ 2: เทอร์มินัลที่มี kubectl และ helm เชื่อมต่อกับคลัสเตอร์ Kubernetes
ดูเอกสารอ้างอิงได้ในคู่มือการติดตั้งใช้งาน AlloyDB Omni อย่างเป็นทางการ

2. การตั้งค่าและข้อกำหนด

เลือกเส้นทางที่ 1 หากคุณใช้บัญชี Google Cloud เพื่อสร้างคลัสเตอร์ GKE Autopilot หรือเลือกเส้นทางที่ 2 หากคุณใช้คลัสเตอร์ Kubernetes ของตนเองโดยไม่มีบัญชี Google Cloud

เส้นทางที่ 1: การตั้งค่าโปรเจ็กต์ที่อยู่ในระบบคลาวด์ของ Google (GKE Autopilot)

เลือกหรือสร้างโปรเจ็กต์ที่อยู่ในระบบคลาวด์ในคอนโซล Google Cloud
ตรวจสอบว่าโปรเจ็กต์เปิดใช้การเรียกเก็บเงินแล้ว ดูวิธียืนยันสถานะการเรียกเก็บเงิน
เปิด Google Cloud Shell โดยคลิกไอคอนเปิดใช้งาน Cloud Shell ที่มุมขวาบนของคอนโซล Google Cloud หรือไปที่ shell.cloud.google.com Cloud Shell จะจัดสรรสภาพแวดล้อมการประมวลผลที่โหลดด้วย gcloud, kubectl และ helm
ตั้งค่ารหัสโปรเจ็กต์เป็นตัวแปรสภาพแวดล้อมและกำหนดค่า gcloud ดังนี้

export PROJECT_ID="<YOUR_PROJECT_ID>"
export REGION="us-central1"
export CLUSTER_NAME="omni-autopilot-cluster"

gcloud config set project ${PROJECT_ID}
gcloud config set compute/region ${REGION}

เปิดใช้ Google Cloud API ที่จำเป็นสำหรับ GKE และ Cloud Storage โดยทำดังนี้

gcloud services enable container.googleapis.com \
    storage.googleapis.com \
    cloudresourcemanager.googleapis.com

เส้นทางที่ 2: การตั้งค่าคลัสเตอร์ของคุณเอง (ไม่มีบัญชี Google Cloud)

หากไม่มีบัญชี Google Cloud และใช้คลัสเตอร์ Kubernetes ของคุณเอง ให้ตรวจสอบข้อกำหนดเบื้องต้นต่อไปนี้จากเทอร์มินัลก่อนดำเนินการต่อ

ตรวจสอบว่า kubectl และ helm เข้าถึงคลัสเตอร์ได้ และโหนดของคุณอยู่ในสถานะ Ready โดยทำดังนี้

kubectl get nodes
helm version

ตรวจสอบว่าคลัสเตอร์มี StorageClass เริ่มต้นที่ทำเครื่องหมายเป็น (default) ไฟล์ Manifest DBCluster และ BackupPlan จะจัดสรร PersistentVolumeClaims แบบไดนามิกโดยใช้ StorageClass เริ่มต้นของคลัสเตอร์

kubectl get storageclass

หากไม่มี StorageClass ที่ทำเครื่องหมายเป็น (default) ให้กำหนด 1 รายการเป็นค่าเริ่มต้นก่อนดำเนินการต่อ โดยทำดังนี้

kubectl patch storageclass <YOUR_STORAGE_CLASS_NAME> \
  -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

ตรวจสอบว่าโหนด Worker เป็นไปตามข้อกำหนดด้านฮาร์ดแวร์และระบบปฏิบัติการของผู้ให้บริการ ดังนี้
- ระบบปฏิบัติการและเคอร์เนล: เคอร์เนล Linux 4.18 ขึ้นไปที่เปิดใช้ cgroup v2 ในโหนด x86-64/AMD64
- ความจุของคลัสเตอร์: vCPU อย่างน้อย 8 ตัวและหน่วยความจำที่จัดสรรได้ 24 GiB ในโหนด Worker เพื่อเรียกใช้อินสแตนซ์ฐานข้อมูล HA (ปรับขนาดเป็น vCPU 2 ตัวและ 8 GiB ในขั้นตอนที่ 12), อินสแตนซ์ที่โคลน PITR, PgBouncer และ pgAdmin4 พร้อมกัน
- การเข้าถึงเครือข่าย: การเข้าถึงอินเทอร์เน็ตขาออกเพื่อดึงอิมเมจคอนเทนเนอร์จาก gcr.io/alloydb-omni, quay.io/jetstack และ docker.io

3. จัดสรรหรือเชื่อมต่อกับคลัสเตอร์ Kubernetes

หากคุณเลือกเส้นทางที่ 1 (บัญชี Google Cloud) GKE Autopilot จะมอบโหมด Kubernetes ที่มีการจัดการครบวงจรแบบไม่ต้องดำเนินการเอง โดย Google จะจัดการโครงสร้างพื้นฐานของคลัสเตอร์ การจัดสรรโหนด และการปรับขนาดอัตโนมัติ คุณสร้างคลัสเตอร์ GKE Autopilot ได้โดยใช้ Google Cloud CLI หรือคอนโซล Google Cloud

ตัวเลือก ก: สร้างคลัสเตอร์ GKE Autopilot ผ่าน CLI (เส้นทางที่ 1)

เรียกใช้คำสั่ง gcloud ต่อไปนี้ใน Cloud Shell

gcloud container clusters create-auto ${CLUSTER_NAME} \
    --region=${REGION} \
    --project=${PROJECT_ID}

ตัวเลือก ข: สร้างคลัสเตอร์ GKE Autopilot ผ่านคอนโซล (เส้นทางที่ 1)

เปิด Kubernetes Engine ในคอนโซล Google Cloud
คลิกคลัสเตอร์ในแผงการนำทางด้านซ้าย
คลิกสร้าง
ในส่วน GKE Autopilot ให้คลิกกำหนดค่า
ระบุชื่อคลัสเตอร์ (เช่น omni-autopilot-cluster) และเลือกภูมิภาคที่ต้องการ (us-central1)
คลิกสร้าง

ยืนยันการเชื่อมต่อคลัสเตอร์ (เส้นทางที่ 1 และเส้นทางที่ 2)

หากคุณสร้างคลัสเตอร์ GKE Autopilot ในเส้นทางที่ 1 ให้กำหนดค่าข้อมูลเข้าสู่ระบบ kubectl ดังนี้

gcloud container clusters get-credentials ${CLUSTER_NAME} --region=${REGION} --project=${PROJECT_ID}

สำหรับทั้งเส้นทางที่ 1 และเส้นทางที่ 2 ให้ตรวจสอบการเชื่อมต่อกับคลัสเตอร์ Kubernetes โดยทำดังนี้

kubectl get nodes

4. ติดตั้งข้อกำหนดเบื้องต้นของโอเปอเรเตอร์และโอเปอเรเตอร์

โอเปอเรเตอร์ AlloyDB Omni Kubernetes ต้องใช้ cert-manager เพื่อจัดการใบรับรอง TLS ของเว็บฮุคการรับเข้า

1. ติดตั้ง cert-manager

ติดตั้ง cert-manager โดยใช้ Helm Chart อย่างเป็นทางการ ดังนี้

helm install \
  cert-manager oci://quay.io/jetstack/charts/cert-manager \
  --version v1.21.2 \
  --namespace cert-manager \
  --create-namespace \
  --set crds.enabled=true \
  --set global.leaderElection.namespace=cert-manager

ตรวจสอบว่าพ็อด cert-manager ทำงานอยู่ โดยทำดังนี้

kubectl wait --namespace cert-manager \
  --for=condition=ready pod \
  --selector=app.kubernetes.io/instance=cert-manager \
  --timeout=120s

2. ติดตั้ง AlloyDB Omni Operator

ติดตั้งใช้งานโอเปอเรเตอร์ AlloyDB Omni Kubernetes ในเนมสเปซ alloydb-omni-system โดยใช้ Helm ดังนี้

helm install alloydbomni-operator oci://gcr.io/alloydb-omni/alloydbomni-operator \
  --version 1.8.2 \
  --create-namespace \
  --namespace alloydb-omni-system \
  $(helm install --help | grep -q -- '--rollback-on-failure' && echo '--rollback-on-failure' || echo '--atomic') \
  --timeout 5m

ตรวจสอบว่าพ็อดโอเปอเรเตอร์ทำงานได้ตามปกติและกำลังทำงานอยู่ โดยใช้คำสั่งต่อไปนี้

kubectl get pods -n alloydb-omni-system

5. สร้างคลัสเตอร์ฐานข้อมูลอินสแตนซ์เดียว

ในขั้นตอนนี้ คุณจะสร้างเนมสเปซแอปพลิเคชันเฉพาะและติดตั้งใช้งาน AlloyDB Omni DBCluster อินสแตนซ์เดียว

1. สร้างเนมสเปซและข้อมูลลับของข้อมูลเข้าสู่ระบบของผู้ดูแลระบบ

สร้างเนมสเปซ omni-demo สำหรับเวิร์กโหลดฐานข้อมูล

kubectl create namespace omni-demo

สร้าง Kubernetes Secret ที่จัดเก็บรหัสผ่านสำหรับผู้ใช้ที่เป็นผู้ดูแลระบบฐานข้อมูล postgres เริ่มต้น โดยทำดังนี้

kubectl apply -n omni-demo -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: db-pw-adbo
type: Opaque
data:
  adbo: "Q2hhbmdlTWUxMjM=" # Base64 for "ChangeMe123"
EOF

2. ติดตั้งใช้งาน DBCluster อินสแตนซ์เดียว

สร้างไฟล์ Manifest ของ DBCluster แบบอินสแตนซ์เดียวโดยทำดังนี้

kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: adbo
spec:
  databaseVersion: "18.3.0"
  primarySpec:
    adminUser:
      passwordRef:
        name: db-pw-adbo
    resources:
      cpu: 1
      memory: 4Gi
      disks:
      - name: DataDisk
        size: 10Gi
EOF

3. ตรวจสอบความพร้อมของคลัสเตอร์

ตรวจสอบสถานะคลัสเตอร์จนกว่า DBCLUSTERPHASE จะถึง DBClusterReady การจัดสรรครั้งแรกอาจใช้เวลาหลายนาที โดยโอเปอเรเตอร์ต้องสร้าง Persistent Volume และดึงอิมเมจฐานข้อมูล และใน GKE Autopilot อาจต้องจัดสรรโหนดใหม่ก่อน

kubectl get dbcluster -n omni-demo -w

กด Ctrl+C เพื่อออกจากโหมดดูเมื่อ DBCLUSTERPHASE ถึง DBClusterReady

ตัวอย่างเอาต์พุต

NAME   PRIMARYENDPOINT   PRIMARYPHASE   DBCLUSTERPHASE   HAREADYSTATUS   HAREADYREASON
adbo   10.128.0.45       Ready          DBClusterReady

จดที่อยู่ IP PRIMARYENDPOINT ซึ่งเป็น ClusterIP ของบริการ Kubernetes แบบอ่าน-เขียน al-adbo-rw-ilb AlloyDB Omni จะคอยฟังพอร์ต PostgreSQL เริ่มต้น 5432

ตรวจสอบทรัพยากรที่โอเปอเรเตอร์ปรับยอดจากไฟล์ Manifest DBCluster รายการเดียว ซึ่งได้แก่ พ็อดฐานข้อมูล, DataDisk PersistentVolumeClaim และ al-adbo-rw-ilb Service

kubectl get pods,svc,pvc -n omni-demo

6. อัปเกรดเป็นความพร้อมใช้งานสูง (HA) และเปิดใช้สแตนด์บายแบบอ่านอย่างเดียว

AlloyDB Omni มีความพร้อมใช้งานสูง (HA) ในตัวพร้อมการจำลองสตรีมมิง การตรวจสอบประสิทธิภาพการทำงานอัตโนมัติ เฟลโอเวอร์อัตโนมัติ และการแสดงผลตัวจำลองแบบอ่านอย่างเดียว

1. เปิดใช้ความสามารถ HA และ Read Replica

อัปเดตข้อกำหนด DBCluster เพื่อกำหนดค่าอินสแตนซ์สแตนด์บาย 1 รายการและเปิดใช้การกำหนดเส้นทางสแตนด์บายแบบอ่านอย่างเดียว

kubectl patch dbcluster adbo -n omni-demo --type=merge -p '{
  "spec": {
    "availability": {
      "numberOfStandbys": 1,
      "enableStandbyAsReadReplica": true
    }
  }
}'

2. ยืนยันการรักษาเสถียรภาพของ HA

รอให้อินสแตนซ์สแตนด์บายจัดสรรและเข้าถึงการจำลองการสตรีมที่สมบูรณ์ (HAREADYSTATUS ถึง True และ HAREADYREASON ถึง Ready) จากนั้นกด Ctrl+C เพื่อออกจากโหมดดู:

kubectl get dbcluster adbo -n omni-demo -w

ตรวจสอบเงื่อนไขสถานะ HAReady ดังนี้

kubectl get dbcluster.alloydbomni.dbadmin.goog adbo -n omni-demo -o jsonpath='{.status.conditions[?(@.type == "HAReady")]}'

ตรวจสอบว่าได้เผยแพร่ทั้งปลายทางแบบอ่าน-เขียนและแบบอ่านอย่างเดียวแล้ว โดยทำดังนี้

kubectl describe dbcluster adbo -n omni-demo | grep -A 8 "Endpoints:"

ตัวอย่างเอาต์พุต

Endpoints:
  Name: Read-Write
  Value: 10.128.0.45:5432
  Name: Read-Only
  Value: 10.128.0.46:5432

ปลายทางการอ่าน-เขียน (บริการ al-adbo-rw-ilb) จะกำหนดเส้นทางไปยังฐานข้อมูลหลัก ส่วนปลายทางการอ่านอย่างเดียว (บริการ al-adbo-ro-ilb) จะกระจายคำค้นหาการอ่านไปยังอินสแตนซ์สแตนด์บาย

7. กำหนดค่า BackupPlans อัตโนมัติ (ในเครื่องและ GCS)

AlloyDB Omni มีการสำรองข้อมูลทางกายภาพและการเก็บถาวร WAL ผ่านทรัพยากรที่กำหนดเอง BackupPlan คุณสามารถกำหนดค่าการเก็บรักษาข้อมูลสำรอง, กำหนดการ Cron อัตโนมัติ และเป้าหมายการสำรองข้อมูล (Persistent Volume ในเครื่องหรือ Google Cloud Storage)

1. สร้าง BackupPlan ในเครื่อง

สร้าง BackupPlan ที่เขียนข้อมูลสำรองลงในพื้นที่เก็บข้อมูล Kubernetes ในเครื่องที่เชื่อมต่อกับอินสแตนซ์ฐานข้อมูล โดยทำดังนี้

kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: BackupPlan
metadata:
  name: backupplan-local
spec:
  dbclusterRef: adbo
  backupSchedules:
    full: "0 2 * * *" # Daily at 02:00 UTC
    incremental: "0 */4 * * *" # Every 4 hours
  backupRetainDays: 7
EOF

ตรวจสอบว่า BackupPlan ในเครื่องพร้อมแล้ว โดยทำดังนี้

kubectl get backupplan backupplan-local -n omni-demo

รอจนกว่าจะมีการกำหนดเวลารายงาน PHASE ของ Ready และ NEXTBACKUPTIME

2. สร้าง BackupPlan ของ GCS (เส้นทางที่ 1: Google Cloud เท่านั้น - ไม่บังคับ)

หากต้องการจัดเก็บข้อมูลสำรองไว้ภายนอกในที่เก็บข้อมูล Google Cloud Storage ให้สร้างที่เก็บข้อมูล GCS, กำหนดค่าคีย์ลับของบัญชีบริการ และใช้ BackupPlan ในระบบคลาวด์

สร้าง Bucket ของ Cloud Storage โดยทำดังนี้

export BUCKET_NAME="${PROJECT_ID}-omni-backups"
gcloud storage buckets create gs://${BUCKET_NAME} --location=${REGION}

สร้างบัญชีบริการที่มีสิทธิ์ผู้ดูแลระบบออบเจ็กต์พื้นที่เก็บข้อมูล และสร้างคีย์สำหรับบัญชีบริการดังกล่าว โดยทำดังนี้

ข้อควรระวัง: โอเปอเรเตอร์ AlloyDB Omni จะอ่านข้อมูลเข้าสู่ระบบ Cloud Storage จากคีย์บัญชีบริการที่คุณจัดเก็บไว้ใน Kubernetes Secret เอกสารประกอบของผู้ให้บริการไม่ครอบคลุมวิธีอื่นๆ ในการตรวจสอบสิทธิ์ เช่น การรวมศูนย์ Workload Identity สำหรับ GKE หากองค์กรบังคับใช้นโยบายองค์กร iam.disableServiceAccountKeyCreation คำสั่ง keys create จะดำเนินการไม่สำเร็จ ในกรณีนี้ ให้ข้ามขั้นตอนที่เหลือของสร้าง GCS BackupPlan ขั้นตอนที่เหลือของ Codelab นี้จะใช้แผนสำรองข้อมูลในเครื่อง

คีย์บัญชีบริการเป็นข้อมูลเข้าสู่ระบบที่มีอายุการใช้งานยาวนาน ขั้นตอนถัดไปจะลบสำเนาในเครื่อง และขั้นตอนการล้างข้อมูลจะลบบัญชีบริการและคีย์ของบัญชีบริการ ดูข้อมูลเพิ่มเติมได้ที่หัวข้อสร้างแผนที่จัดเก็บข้อมูลสำรองใน Cloud Storage

export SA_NAME="omni-backup-sa"
gcloud iam service-accounts create ${SA_NAME} --display-name="AlloyDB Omni Backup SA"

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="serviceAccount:${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \
  --role="roles/storage.objectAdmin"

gcloud iam service-accounts keys create /tmp/gcs-key.json \
  --iam-account="${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"

สร้างข้อมูลลับในเนมสเปซ Kubernetes โดยทำดังนี้

kubectl create secret generic gcs-backup-secret \
  --from-file=key.json=/tmp/gcs-key.json \
  -n omni-demo
rm /tmp/gcs-key.json

ใช้ไฟล์ Manifest ของ GCS BackupPlan ช่อง key คือโฟลเดอร์ในที่เก็บข้อมูลที่โอเปอเรเตอร์เขียนข้อมูลสำรองไว้ โดยต้องขึ้นต้นด้วย /

kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: BackupPlan
metadata:
  name: backupplan-gcs
spec:
  dbclusterRef: adbo
  backupSchedules:
    full: "0 1 * * *"
    incremental: "0 */6 * * *"
  backupRetainDays: 14
  backupLocation:
    type: GCS
    gcsOptions:
      bucket: ${BUCKET_NAME}
      key: /omni-backups/adbo
      secretRef:
        name: gcs-backup-secret
        namespace: omni-demo
EOF

ตรวจสอบสถานะ BackupPlan ของ GCS โดยทำดังนี้

kubectl get backupplan backupplan-gcs -n omni-demo

รอจนกว่าจะมีการกำหนดเวลารายงาน PHASE ของ Ready และ NEXTBACKUPTIME

8. แทรกข้อมูล ทริกเกอร์การสำรองข้อมูล และทดสอบการกู้คืน

ในขั้นตอนนี้ คุณจะป้อนข้อมูลเริ่มต้นลงในฐานข้อมูลหลัก ทริกเกอร์การสำรองข้อมูลด้วยตนเองตามต้องการ เพิ่มข้อมูลที่ตามมา และกู้คืนจากข้อมูลสำรองเพื่อพิสูจน์การย้อนกลับข้อมูล

1. ป้อนข้อมูลเริ่มต้น

เรียกใช้พ็อดไคลเอ็นต์ PostgreSQL ชั่วคราวเพื่อเชื่อมต่อกับฐานข้อมูลผ่านบริการอ่าน-เขียน al-adbo-rw-ilb ในฐานะผู้ใช้ postgres

kubectl run pg-client --rm -i --tty --image=postgres:16 --restart=Never -n omni-demo -- \
  psql -h al-adbo-rw-ilb -U postgres -d postgres -c "
    CREATE TABLE customers (id SERIAL PRIMARY KEY, name TEXT, created_at TIMESTAMPTZ DEFAULT pg_catalog.now());
    INSERT INTO customers (name) VALUES ('Alpha Co'), ('Beta LLC');
    SELECT * FROM customers;
  "

เมื่อระบบขอรหัสผ่าน ให้ป้อน ChangeMe123 ซึ่งเป็นรหัสผ่านที่คุณเข้ารหัส Base64 ใน db-pw-adbo Secret ในขั้นตอนที่ 5

2. ทริกเกอร์การสำรองข้อมูลตามคำขอ

สร้างทรัพยากรที่กำหนดเอง Backup ด้วยตนเองซึ่งอ้างอิง BackupPlan ในเครื่อง โดยทำดังนี้

kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Backup
metadata:
  name: initial-customer-backup
spec:
  dbclusterRef: adbo
  backupPlanRef: backupplan-local
  manual: true
EOF

ติดตามความคืบหน้าของการสำรองข้อมูลโดยทำดังนี้

kubectl get backup initial-customer-backup -n omni-demo -w

รอจนกว่า PHASE จะเปลี่ยนเป็น Succeeded

3. เปลี่ยนแปลงข้อมูล (เพิ่มระเบียนใหม่)

แทรกระเบียนเพิ่มเติมหลังจากข้อมูลสำรอง ดังนี้

kubectl run pg-client --rm -i --tty --image=postgres:16 --restart=Never -n omni-demo \
  --env="PGPASSWORD=ChangeMe123" -- \
  psql -h al-adbo-rw-ilb -U postgres -d postgres -c "
    INSERT INTO customers (name) VALUES ('Gamma Inc'), ('Delta Corp');
    SELECT * FROM customers;
  "

ตอนนี้ฐานข้อมูลมี 4 แถว

4. กู้คืนจากข้อมูลสำรอง

เรียกใช้การกู้คืนกลับไปยังสถานะที่บันทึกไว้ใน initial-customer-backup โดยทำดังนี้

kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Restore
metadata:
  name: restore-to-initial
spec:
  sourceDBCluster: adbo
  backup: initial-customer-backup
EOF

ตรวจสอบการดำเนินการกู้คืนโดยทำดังนี้

kubectl get restore restore-to-initial -n omni-demo -w

รอจนกว่า PHASE จะถึง ProvisionSucceeded และตรวจสอบว่า DBCluster กลับไปที่ DBClusterReady:

kubectl get dbcluster adbo -n omni-demo -w

5. ยืนยันสถานะข้อมูลที่กู้คืน

ค้นหาตาราง customers เพื่อยืนยันว่ามีเฉพาะระเบียนก่อนการสำรองข้อมูลเท่านั้น

kubectl run pg-client --rm -i --tty --image=postgres:16 --restart=Never -n omni-demo \
  --env="PGPASSWORD=ChangeMe123" -- \
  psql -h al-adbo-rw-ilb -U postgres -d postgres -c "
    SELECT * FROM customers;
  "

เอาต์พุตยืนยันว่ามีเพียง 2 แถว (Alpha Co และ Beta LLC) ซึ่งเป็นการยืนยันว่าฐานข้อมูลได้รับการกู้คืนไปยังสถานะการสำรองข้อมูลที่แน่นอน

9. การกู้คืนช่วงเวลา (PITR) ไปยังฐานข้อมูลที่โคลน

การกู้คืนช่วงเวลา (PITR) ช่วยให้สามารถกู้คืนฐานข้อมูลไปยังวินาทีใดก็ได้ภายในกรอบเวลาการกู้คืนโดยใช้ข้อมูลสำรองพื้นฐานและบันทึกสตรีม WAL ซึ่งจะจัดสรรข้อมูลที่กู้คืนไปยังคลัสเตอร์ฐานข้อมูลที่โคลนใหม่

เนื่องจากโอเปอเรเตอร์จะเก็บถาวร Write-Ahead Log (WAL) อย่างต่อเนื่อง PITR จึงช่วยให้คุณกู้คืนจากข้อผิดพลาดที่เกิดจากมนุษย์หรือแอปพลิเคชันโดยไม่ตั้งใจได้ เช่น DELETE หรือ DROP TABLE โดยไม่ตั้งใจเมื่อเวลา 14:15:00 น. โดยการโคลนฐานข้อมูลไปยังวินาทีที่แน่นอนก่อนที่จะเกิดข้อผิดพลาด (14:14:59 น.) โดยไม่ต้องแตะคลัสเตอร์เดิม

1. บันทึกการประทับเวลาปัจจุบันและเปลี่ยนแปลงข้อมูล

ดึงข้อมูลการประทับเวลา UTC ปัจจุบัน

export PITR_TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
echo "PITR Target Timestamp: ${PITR_TIMESTAMP}"

แทรกระเบียนทดสอบที่แสดงถึงการแก้ไขที่ไม่ต้องการหลังจากการประทับเวลานี้

kubectl run pg-client --rm -i --tty --image=postgres:16 --restart=Never -n omni-demo \
  --env="PGPASSWORD=ChangeMe123" -- \
  psql -h al-adbo-rw-ilb -U postgres -d postgres -c "
    INSERT INTO customers (name) VALUES ('Unwanted Record Post-Timestamp');
    SELECT * FROM customers;
  "

2. ทำการกู้คืน ณ จุดเวลาที่ต้องการ

ใช้ทรัพยากรที่กำหนดเอง Restore เพื่อกำหนดค่า pointInTime และ clonedDBClusterConfig ดังนี้

kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Restore
metadata:
  name: restore-pitr-clone
spec:
  sourceDBCluster: adbo
  pointInTime: "${PITR_TIMESTAMP}"
  clonedDBClusterConfig:
    dbclusterName: adbo-cloned
EOF

ตรวจสอบการดำเนินการกู้คืนจนกว่า PHASE จะถึง ProvisionSucceeded:

kubectl get restore restore-pitr-clone -n omni-demo -w

3. ยืนยันฐานข้อมูลที่โคลน

เมื่อการกู้คืนเสร็จสมบูรณ์ ให้รอจนกว่า DBCluster ที่โคลนใหม่จะถึง DBClusterReady (กด Ctrl+C เพื่อออกจากโหมดดู)

kubectl get dbcluster adbo-cloned -n omni-demo -w

ค้นหาฐานข้อมูลที่โคลน adbo-cloned ผ่านบริการอ่าน-เขียน al-adbo-cloned-rw-ilb:

kubectl run pg-client --rm -i --tty --image=postgres:16 --restart=Never -n omni-demo \
  --env="PGPASSWORD=ChangeMe123" -- \
  psql -h al-adbo-cloned-rw-ilb -U postgres -d postgres -c "
    SELECT * FROM customers;
  "

โปรดทราบว่า Unwanted Record Post-Timestamp ไม่ปรากฏในคลัสเตอร์ที่โคลน ซึ่งแสดงให้เห็นถึงการกู้คืนที่แม่นยำไปยังจุดเป้าหมายที่แน่นอนในเวลาที่กำหนด

10. ติดตั้งใช้งานพูลการเชื่อมต่อ PgBouncer

การรวมการเชื่อมต่อจะช่วยลดภาระการใช้หน่วยความจำของฐานข้อมูลและเวลาในการตอบสนองของการเชื่อมต่อ โอเปอเรเตอร์จะจัดการอินสแตนซ์ PgBouncer โดยตรงผ่านทรัพยากรที่กำหนดเอง PgBouncer

PostgreSQL จะแยกกระบวนการของระบบปฏิบัติการที่แยกต่างหากสำหรับการเชื่อมต่อไคลเอ็นต์แต่ละรายการ ดังนั้นการเชื่อมต่อพร้อมกันหลายร้อยรายการจากเว็บเซอร์วิส, Microservice หรือ AI Agent อาจทำให้หน่วยความจำฐานข้อมูลหมดลงได้ PgBouncer จะอยู่หน้าฐานข้อมูลและมัลติเพล็กซ์การเชื่อมต่อไคลเอ็นต์ที่มีอายุสั้นจำนวนมาก (สูงสุด max_client_conn รายการ) ไปยังพูลขนาดเล็กของการเชื่อมต่อเซิร์ฟเวอร์ PostgreSQL ที่มีอายุยาว (default_pool_size รายการต่อคู่ผู้ใช้/ฐานข้อมูล โดยจำกัดไว้ที่ max_db_connections รายการ)

1. ติดตั้งใช้งาน PgBouncer

ติดตั้งใช้งานพูลเลอร์ PgBouncer แบบ 2 Replica ที่ลิงก์กับคลัสเตอร์ adbo:

kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: PgBouncer
metadata:
  name: omni-pgbouncer
spec:
  dbclusterRef: adbo
  allowSuperUserAccess: true
  replicaCount: 2
  parameters:
    pool_mode: transaction
    default_pool_size: "20"
    max_client_conn: "500"
    max_db_connections: "100"
  podSpec:
    resources:
      cpu: 1
      memory: 1Gi
    image: "gcr.io/alloydb-omni/operator/g-pgbouncer:1.4.0"
  serviceOptions:
    type: ClusterIP
EOF

2. ยืนยันสถานะ PgBouncer

ดูสถานะ PgBouncer จนกว่า PHASE จะเป็น Ready:

kubectl get pgbouncer omni-pgbouncer -n omni-demo -w

ตรวจสอบพ็อดและบริการ PgBouncer ที่ทำงานอยู่โดยทำดังนี้

kubectl get pods -n omni-demo
kubectl get svc al-omni-pgbouncer-pgb-svc -n omni-demo

3. เชื่อมต่อผ่าน PgBouncer

เชื่อมต่อไคลเอ็นต์ผ่านบริการ PgBouncer ในพอร์ต 6432:

kubectl run pg-client --rm -i --tty --image=postgres:16 --restart=Never -n omni-demo \
  --env="PGPASSWORD=ChangeMe123" -- \
  psql -h al-omni-pgbouncer-pgb-svc -p 6432 -U postgres -d postgres -c "
    SELECT pg_catalog.version();
    SELECT * FROM customers;
  "

PgBouncer จะส่งพร็อกซีการค้นหาไปยังฐานข้อมูล AlloyDB Omni หลักได้อย่างราบรื่น

11. ติดตั้งใช้งาน pgAdmin4 เพื่อเข้าถึงฐานข้อมูล

คุณสามารถเรียกใช้ pgAdmin4 ภายในคลัสเตอร์ Kubernetes ได้โดยตรงเพื่อจัดเตรียมคอนโซลการดูแลระบบบนเว็บสำหรับการค้นหา จัดการ และตรวจสอบ AlloyDB Omni

1. ติดตั้ง pgAdmin4 ผ่าน Helm

ติดตั้ง pgadmin4 ในเนมสเปซ omni-demo โดยทำดังนี้

helm install my-pgadmin oci://docker.io/dpage/pgadmin4-helm \
  --namespace omni-demo \
  --set ingress.enabled=false \
  --set image.tag=latest \
  --set auth.email="admin@example.com" \
  --set auth.password="AdminPassword123"

แผนภูมินี้ตั้งชื่อทรัพยากร Kubernetes ว่า pgadmin4 (Deployment, Service, PersistentVolumeClaim) และติดป้ายกำกับพ็อดด้วย app=pgadmin4 โดยไม่คำนึงถึงชื่อรุ่น Helm (my-pgadmin)

ตรวจสอบว่าพ็อด pgAdmin4 ทำงานอยู่โดยทำดังนี้

kubectl wait --namespace omni-demo \
  --for=condition=ready pod \
  --selector=app=pgadmin4 \
  --timeout=300s

2. ส่งต่อพอร์ตและเข้าถึง UI บนเว็บ

ส่งต่อพอร์ต pgAdmin4 ไปยังสภาพแวดล้อมในเครื่องหรือ Cloud Shell โดยทำดังนี้

kubectl port-forward service/pgadmin4 5050:80 -n omni-demo

kubectl port-forward จะทำงานอยู่เบื้องหน้าต่อไปตราบใดที่คุณใช้ UI บนเว็บของ pgAdmin4 เปิดเทอร์มินัลที่ 2 (หรือแท็บ Cloud Shell ใหม่) สำหรับคำสั่งอื่นๆ แล้วกด Ctrl+C ในเทอร์มินัลนี้เมื่อคุณพร้อมที่จะไปยังขั้นตอนถัดไป

เปิดอินเทอร์เฟซเว็บ pgAdmin4 โดยทำดังนี้

เส้นทางที่ 1 (Google Cloud Shell): คลิกปุ่มตัวอย่างบนเว็บในเมนูด้านขวาบน เลือกเปลี่ยนพอร์ต ป้อน 5050 แล้วคลิกเปลี่ยนและแสดงตัวอย่าง
เส้นทางที่ 2 (เวิร์กสเตชันในเครื่อง): เปิด http://localhost:5050 ในเบราว์เซอร์ขณะที่คำสั่ง kubectl port-forward กำลังทำงาน

เข้าสู่ระบบโดยใช้:

อีเมล: admin@example.com
รหัสผ่าน: AdminPassword123

3. ลงทะเบียน AlloyDB Omni ใน pgAdmin4

ใน pgAdmin4 ให้คลิกขวาที่ Servers > Register > Server...
ในแท็บทั่วไป ให้ทำดังนี้
- ชื่อ: AlloyDB Omni Primary
ในแท็บการเชื่อมต่อ ให้ทำดังนี้
- ชื่อ/ที่อยู่โฮสต์: al-adbo-rw-ilb.omni-demo.svc.cluster.local (หรือ al-omni-pgbouncer-pgb-svc.omni-demo.svc.cluster.local สำหรับ PgBouncer)
- พอร์ต: 5432 (หรือ 6432 สำหรับ PgBouncer)
- ฐานข้อมูลการบำรุงรักษา: postgres
- ชื่อผู้ใช้: postgres
- รหัสผ่าน: ChangeMe123
คลิกบันทึก แล้วยืนยันเซสชันและตารางฐานข้อมูลที่ใช้งานอยู่

12. ปรับขนาด CPU และหน่วยความจำด้วยการบำรุงรักษาที่ใช้เวลาหยุดทำงานน้อย (LDTM)

เมื่อปรับขนาดการประมวลผลและหน่วยความจำในแนวตั้งบนฐานข้อมูลที่ใช้งานจริง การอัปเดตแบบเดิมจะทำให้การรีสตาร์ทฐานข้อมูลหยุดชะงัก AlloyDB Omni มีการบำรุงรักษาที่ใช้เวลาหยุดทำงานน้อย (LDTM) เพื่ออัปเดตผ่านตัวจำลองโดยรบกวนแอปพลิเคชันน้อยที่สุด

1. เปิดใช้คำอธิบายประกอบ LDTM

ใส่คำอธิบายประกอบ DBCluster เพื่อเปิดใช้ LDTM สำหรับการอัปเดต

kubectl annotate dbclusters.alloydbomni.dbadmin.goog adbo -n omni-demo dbcluster.dbadmin.goog/enableLDTM=true --overwrite

2. ปรับขนาดทรัพยากร CPU และหน่วยความจำ

อัปเดตแหล่งข้อมูลหลักจาก cpu: 1, memory: 4Gi เป็น cpu: 2, memory: 8Gi:

kubectl patch dbcluster adbo -n omni-demo --type=merge -p '{
  "spec": {
    "primarySpec": {
      "resources": {
        "cpu": 2,
        "memory": "8Gi"
      }
    }
  }
}'

3. ตรวจสอบความคืบหน้าในการปรับขนาด LDTM

ตรวจสอบเงื่อนไขการอัปเดตทีละส่วนและการเปลี่ยนจากสแตนด์บายเป็นหลัก ดังนี้

kubectl get dbcluster adbo -n omni-demo -o yaml | grep -A 5 -B 2 "LDTMScalingInProgress"

ดูฝักถั่วกลิ้งอย่างสวยงาม

kubectl get pods -n omni-demo -w

LDTM จะเตรียมสแตนด์บายที่อัปเดตก่อน ยืนยันการจำลองสตรีมมิง ดำเนินการสลับอย่างรวดเร็ว และอัปเดตอินสแตนซ์ที่เหลือโดยไม่ทำให้บริการหยุดชะงัก

ยืนยันการจัดสรรทรัพยากรที่อัปเดตแล้ว

kubectl get dbcluster adbo -n omni-demo -o jsonpath='{.spec.primarySpec.resources}'

13. แหล่งข้อมูลการล้างข้อมูล

หากต้องการเพิ่มความจุของคลัสเตอร์และป้องกันไม่ให้มีการเรียกเก็บเงินที่ไม่จำเป็นในบัญชี Google Cloud ให้ล้างทรัพยากรที่จัดสรรไว้ในระหว่าง Codelab นี้

หากคุณเรียกใช้การล้างข้อมูลในเซสชันเทอร์มินัลใหม่ (เส้นทางที่ 1) ระบบจะไม่ตั้งค่าตัวแปรสภาพแวดล้อมจากขั้นตอนก่อนหน้าอีกต่อไป ส่งออกอีกครั้งโดยใช้ค่าเดียวกับที่ใช้ก่อนหน้านี้ ดังนี้

export PROJECT_ID="<YOUR_PROJECT_ID>"
export REGION="us-central1"
export CLUSTER_NAME="omni-autopilot-cluster"
export BUCKET_NAME="${PROJECT_ID}-omni-backups"
export SA_NAME="omni-backup-sa"
gcloud config set project ${PROJECT_ID}

1. ลบภาระงานของฐานข้อมูล (เส้นทางที่ 1 และเส้นทางที่ 2)

ทำเครื่องหมายทั้ง 2 คลัสเตอร์ว่าลบแล้วเพื่อผ่านการตรวจสอบเว็บฮุคการรับเข้า รอให้โอเปอเรเตอร์นำทรัพยากร DBCluster ออก แล้วลบเนมสเปซ

kubectl patch dbcluster adbo -n omni-demo --type=merge -p '{"spec":{"isDeleted":true}}'
kubectl patch dbcluster adbo-cloned -n omni-demo --type=merge -p '{"spec":{"isDeleted":true}}'
kubectl wait --for=delete dbcluster/adbo dbcluster/adbo-cloned -n omni-demo --timeout=300s
kubectl delete namespace omni-demo

หากคุณใช้คลัสเตอร์ Kubernetes ของตนเอง (เส้นทางที่ 2) และต้องการนำโอเปอเรเตอร์ AlloyDB Omni และ cert-manager ออกด้วย ให้ทำดังนี้

helm uninstall alloydbomni-operator -n alloydb-omni-system
kubectl delete namespace alloydb-omni-system
helm uninstall cert-manager -n cert-manager
kubectl delete namespace cert-manager

2. ลบที่เก็บข้อมูล GCS และบัญชีบริการ IAM (เส้นทางที่ 1 เท่านั้น)

หากคุณสร้างที่เก็บข้อมูล Google Cloud Storage และบัญชีบริการในเส้นทางที่ 1 ให้ทำดังนี้

gcloud storage rm --recursive gs://${BUCKET_NAME}
gcloud projects remove-iam-policy-binding ${PROJECT_ID} \
  --member="serviceAccount:${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \
  --role="roles/storage.objectAdmin"
gcloud iam service-accounts delete ${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com --quiet

3. ลบคลัสเตอร์ GKE (เส้นทางที่ 1 เท่านั้น)

หากคุณจัดสรรคลัสเตอร์ GKE Autopilot ในเส้นทางที่ 1 ให้ทำดังนี้

gcloud container clusters delete ${CLUSTER_NAME} --region=${REGION} --quiet

14. ขอแสดงความยินดี

ยินดีด้วย คุณได้ทำ Codelab ของ AlloyDB Omni ใน Kubernetes เสร็จสมบูรณ์แล้ว

สิ่งที่เราได้พูดถึงไปแล้ว

จัดสรรคลัสเตอร์ GKE Autopilot (เส้นทางที่ 1) หรือเตรียมคลัสเตอร์ Kubernetes ที่มีอยู่ (เส้นทางที่ 2)
ติดตั้งใช้งาน cert-manager และโอเปอเรเตอร์ AlloyDB Omni Kubernetes ผ่าน Helm แล้ว
ติดตั้งใช้งาน AlloyDB Omni DBCluster อินสแตนซ์เดียวแล้ว
อัปเกรดคลัสเตอร์เป็นความพร้อมใช้งานสูง (HA) ด้วยสแตนด์บายแบบซิงโครนัสและเปิดใช้การกำหนดเส้นทางสแตนด์บายแบบอ่านอย่างเดียว
สร้างทรัพยากร BackupPlan อัตโนมัติสำหรับทั้งพื้นที่เก็บข้อมูลถาวรในเครื่องและ Google Cloud Storage (GCS)
ดำเนินการสำรองข้อมูลตามต้องการและตรวจสอบการกู้คืนฐานข้อมูล
ดำเนินการกู้คืนช่วงเวลา (PITR) ไปยังคลัสเตอร์ฐานข้อมูลที่โคลนใหม่
ติดตั้งใช้งานเครื่องมือรวมการเชื่อมต่อ PgBouncer สำหรับการเชื่อมต่อไคลเอ็นต์ที่ปรับขนาดได้
ติดตั้งใช้งานและเชื่อมต่อ pgAdmin4 สำหรับการจัดการฐานข้อมูล
ดำเนินการบำรุงรักษาโดยมีช่วงเวลาที่ระบบไม่ทำงานต่ำ (LDTM) เพื่อปรับขนาดทรัพยากรการประมวลผลและหน่วยความจำแบบไดนามิก

ขั้นตอนถัดไป

สำรวจการกู้ข้อมูลคืนหลังจากภัยพิบัติ (DR) ของ AlloyDB Omni ในสภาพแวดล้อมแบบหลายคลัสเตอร์
ดูข้อมูลเพิ่มเติมเกี่ยวกับความสามารถของ AlloyDB Omni AI และ pgvector

15. แบบสำรวจ

คุณจะใช้บทแนะนำนี้อย่างไร

อ่านอย่างเดียว

อ่านและทำแบบฝึกหัด