Google sử dụng công nghệ AI để dịch nội dung sang ngôn ngữ bạn ưu tiên. Bản dịch bằng AI có thể có lỗi.

Triển khai và quản lý AlloyDB Omni trên Kubernetes (GKE hoặc cụm của riêng bạn)

1. Giới thiệu

Trong lớp học lập trình này, bạn sẽ tìm hiểu cách cài đặt trình điều hành AlloyDB Omni Kubernetes (trình điều phối vùng chứa) trên một cụm Google Kubernetes Engine (GKE) Autopilot hoặc cụm Kubernetes của riêng bạn, đồng thời quản lý toàn bộ quy trình vòng đời cơ sở dữ liệu từ đầu đến cuối và Hành trình trọng yếu của người dùng (CUJ).

AlloyDB Omni là phiên bản có thể tải xuống của AlloyDB, được thiết kế để chạy ở mọi nơi, từ môi trường tại chỗ đến Google Cloud hoặc điện toán biên. Với trình điều phối vùng chứa, AlloyDB Omni tự động hoá khả năng hoạt động cao, tự động chuyển đổi dự phòng, tự khôi phục, bảo trì định kỳ với thời gian ngừng hoạt động tối thiểu, gộp kết nối, sao lưu tự động và khôi phục tại một thời điểm.

AlloyDB cho PostgreSQL so với AlloyDB Omni: AlloyDB cho PostgreSQL là dịch vụ cơ sở dữ liệu được quản lý toàn diện trên Google Cloud. AlloyDB Omni đóng gói cùng một công cụ cơ sở dữ liệu AlloyDB vào các vùng chứa có thể tải xuống để bạn tự chạy và vận hành (trên cơ sở hạ tầng riêng, trên các đám mây công cộng khác như Amazon EKS hoặc Azure AKS, trên OpenShift hoặc trên máy trạm của nhà phát triển) nhằm đáp ứng các yêu cầu về nơi lưu trữ dữ liệu, đám mây lai hoặc phát triển cục bộ. Trong quá trình triển khai thực tế, bạn thường chạy trình điều hành AlloyDB Omni Kubernetes trên cụm Kubernetes của riêng mình (Lộ trình 2). Đường dẫn 1 chỉ sử dụng GKE Autopilot làm hộp cát Kubernetes tiện lợi, không cần thiết lập cục bộ nếu bạn chưa có cụm.

Chọn đường dẫn môi trường

Bạn có thể hoàn thành lớp học lập trình này theo một trong hai cách sau:

Cách 1: Có tài khoản Google Cloud (GKE Autopilot) – Cấp một cụm GKE Autopilot được quản lý toàn diện bằng Google Cloud Shell hoặc Google Cloud Console.
Lộ trình 2: Không có tài khoản Google Cloud (Sử dụng cụm Kubernetes của riêng bạn) – Sử dụng cụm Kubernetes hiện có (phiên bản 1.21 trở lên) với kubectl và helm được định cấu hình trên máy trạm của bạn. Bạn không cần có tài khoản Google Cloud hoặc gcloud CLI.

Điều kiện tiên quyết

Hiểu biết cơ bản về các khái niệm của Kubernetes (kubectl, Helm, Định nghĩa tài nguyên tuỳ chỉnh).
Đối với Lộ trình 1 (Google Cloud / GKE Autopilot):
- Một dự án trên Google Cloud đã bật tính năng thanh toán.
- Quyền truy cập vào Google Cloud Shell hoặc một máy trạm được định cấu hình bằng gcloud, kubectl và helm.
Đối với Lộ trình 2 (Sử dụng cụm Kubernetes của riêng bạn):
- Một cụm Kubernetes chạy phiên bản 1.21 trở lên có StorageClass mặc định để cấp phép PersistentVolume động.
- Các nút tính toán chạy nhân Linux 4.18 trở lên có bật cgroup v2 (x86-64/AMD64) và có ít nhất 8 vCPU và 24 GiB RAM có thể phân bổ trên toàn bộ cụm.
- Một máy trạm được định cấu hình bằng kubectl và helm được kết nối với cụm của bạn.

Kiến thức bạn sẽ học được

Cách cấp phép một cụm GKE Autopilot (Lộ trình 1) hoặc xác thực một cụm Kubernetes hiện có (Lộ trình 2).
Cách cài đặt cert-manager và toán tử AlloyDB Omni Kubernetes thông qua Helm.
Cách triển khai AlloyDB Omni một thực thể DBCluster.
Cách mở rộng quy mô lên Chế độ có độ sẵn sàng cao (HA) bằng chế độ chờ đồng bộ và bật chức năng chờ chỉ có thể đọc.
Cách định cấu hình sao lưu tự động theo lịch vào bộ nhớ kho lưu trữ cục bộ (và tuỳ chọn Google Cloud Storage trên Đường dẫn 1).
Cách thực hiện sao lưu theo yêu cầu và xác minh việc khôi phục dữ liệu về trạng thái trước đó.
Cách thực hiện Khôi phục tại thời điểm (PITR) cho một cụm cơ sở dữ liệu mới được sao chép.
Cách triển khai tính năng gộp kết nối PgBouncer để điều chỉnh quy mô kết nối của ứng dụng.
Cách triển khai pgAdmin4 để quản lý và truy vấn cơ sở dữ liệu một cách trực quan.
Cách thực hiện quy trình Bảo trì ít gây gián đoạn (LDTM) để điều chỉnh tài nguyên CPU và bộ nhớ.

Bạn cần có

Cách 1: Google Cloud Shell có cài đặt sẵn các tiện ích gcloud, kubectl và helm.
Cách 2: Một thiết bị đầu cuối có kết nối kubectl và helm với cụm Kubernetes của bạn.
Để xem tài liệu tham khảo, hãy xem hướng dẫn triển khai AlloyDB Omni chính thức.

2. Thiết lập và yêu cầu

Chọn Cách 1 nếu bạn đang sử dụng tài khoản Google Cloud để tạo cụm GKE Autopilot hoặc Cách 2 nếu bạn đang sử dụng cụm Kubernetes của riêng mình mà không có tài khoản Google Cloud.

Cách 1: Thiết lập dự án Google Cloud (GKE Autopilot)

Trong Google Cloud Console, hãy chọn hoặc tạo một dự án trên Google Cloud.
Xác nhận rằng bạn đã bật tính năng thanh toán cho dự án của mình. Tìm hiểu cách xác minh trạng thái thanh toán.
Mở Google Cloud Shell bằng cách nhấp vào biểu tượng Activate Cloud Shell (Kích hoạt Cloud Shell) ở góc trên bên phải của Google Cloud Console hoặc bằng cách truy cập vào shell.cloud.google.com. Cloud Shell cung cấp một môi trường điện toán được tải bằng gcloud, kubectl và helm.
Đặt mã dự án làm biến môi trường và định cấu hình 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}

Bật các API Google Cloud cần thiết cho GKE và Cloud Storage:

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

Cách 2: Thiết lập cụm máy chủ của riêng bạn (Không có tài khoản Google Cloud)

Nếu bạn không có tài khoản Google Cloud và đang sử dụng cụm Kubernetes của riêng mình, hãy xác minh các điều kiện tiên quyết sau đây trong thiết bị đầu cuối trước khi tiếp tục:

Xác minh rằng kubectl và helm có thể kết nối với cụm của bạn và các nút của bạn đang Ready:

kubectl get nodes
helm version

Xác minh rằng cụm của bạn có một StorageClass mặc định được đánh dấu là (default). Tệp kê khai DBCluster và BackupPlan tự động cung cấp PersistentVolumeClaims bằng cách sử dụng StorageClass mặc định của cụm:

kubectl get storageclass

Nếu không có StorageClass nào được đánh dấu là (default), hãy chỉ định một làm mặc định trước khi tiếp tục:

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

Xác nhận rằng các nút tính toán của bạn đáp ứng các yêu cầu về phần cứng và hệ điều hành của nhà mạng:
- Hệ điều hành và nhân hệ điều hành: Nhân hệ điều hành Linux 4.18 trở lên có bật cgroup v2 trên các nút x86-64/AMD64.
- Dung lượng cụm: Ít nhất 8 vCPU và 24 GiB bộ nhớ có thể phân bổ trên các nút tính toán để chạy đồng thời các phiên bản cơ sở dữ liệu HA (được điều chỉnh thành 2 vCPU và 8 GiB mỗi phiên bản ở Bước 12), phiên bản được sao chép PITR, PgBouncer và pgAdmin4.
- Quyền truy cập mạng: Quyền truy cập Internet ra bên ngoài để lấy hình ảnh vùng chứa từ gcr.io/alloydb-omni, quay.io/jetstack và docker.io.

3. Cung cấp hoặc kết nối với cụm Kubernetes

Nếu bạn đang làm theo Lộ trình 1 (Tài khoản Google Cloud), thì GKE Autopilot sẽ cung cấp một chế độ Kubernetes được quản lý toàn diện, không cần can thiệp, trong đó Google quản lý cơ sở hạ tầng cụm, việc cấp phát nút và tự động cấp tài nguyên bổ sung. Bạn có thể tạo cụm GKE Autopilot bằng Google Cloud CLI hoặc Google Cloud Console.

Cách A: Tạo cụm GKE Autopilot thông qua CLI (Đường dẫn 1)

Thực thi lệnh gcloud sau trong Cloud Shell:

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

Cách B: Tạo cụm GKE Autopilot thông qua Console (Cách 1)

Mở Kubernetes Engine trong Google Cloud Console.
Trong ngăn điều hướng bên trái, hãy nhấp vào Clusters (Cụm).
Nhấp vào Tạo.
Trong mục GKE Autopilot, hãy nhấp vào Định cấu hình.
Chỉ định tên cụm (ví dụ: omni-autopilot-cluster) và chọn khu vực bạn muốn (us-central1).
Nhấp vào Tạo.

Xác minh khả năng kết nối của cụm (Đường dẫn 1 và Đường dẫn 2)

Nếu bạn đã tạo một cụm GKE Autopilot trong Đường dẫn 1, hãy định cấu hình thông tin xác thực kubectl:

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

Đối với cả Đường dẫn 1 và Đường dẫn 2, hãy xác minh khả năng kết nối với cụm Kubernetes:

kubectl get nodes

4. Cài đặt Điều kiện tiên quyết của Operator và Operator

Trình vận hành AlloyDB Omni Kubernetes cần có cert-manager để quản lý chứng chỉ TLS của webhook tiếp nhận.

1. Cài đặt cert-manager

Cài đặt cert-manager bằng biểu đồ Helm chính thức:

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

Xác minh rằng các nhóm cert-manager đang chạy:

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

2. Cài đặt AlloyDB Omni Operator

Triển khai toán tử AlloyDB Omni Kubernetes vào không gian tên alloydb-omni-system bằng 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

Xác minh rằng các nhóm toán tử đang hoạt động tốt và đang chạy:

kubectl get pods -n alloydb-omni-system

5. Tạo cụm cơ sở dữ liệu một thực thể

Trong bước này, bạn sẽ tạo một không gian tên ứng dụng chuyên dụng và triển khai một phiên bản AlloyDB Omni DBCluster duy nhất.

1. Tạo không gian tên và thông tin xác thực của quản trị viên

Tạo không gian tên omni-demo cho khối lượng công việc của cơ sở dữ liệu:

kubectl create namespace omni-demo

Tạo một Kubernetes Secret lưu trữ mật khẩu cho người dùng quản trị viên cơ sở dữ liệu postgres mặc định:

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. Triển khai DBCluster một phiên bản

Tạo tệp kê khai DBCluster một thực thể:

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. Xác minh mức độ sẵn sàng của cụm

Theo dõi trạng thái của cụm cho đến khi DBCLUSTERPHASE đạt đến DBClusterReady. Quá trình cấp phép ban đầu có thể mất vài phút: toán tử phải tạo ổ đĩa cố định và lấy hình ảnh cơ sở dữ liệu, đồng thời trên GKE Autopilot, có thể cần phải cấp phép một nút mới trước.

kubectl get dbcluster -n omni-demo -w

Nhấn Ctrl+C để thoát khỏi chế độ xem khi DBCLUSTERPHASE đạt đến DBClusterReady.

Kết quả mẫu:

NAME   PRIMARYENDPOINT   PRIMARYPHASE   DBCLUSTERPHASE   HAREADYSTATUS   HAREADYREASON
adbo   10.128.0.45       Ready          DBClusterReady

Lưu ý địa chỉ IP PRIMARYENDPOINT, đây là ClusterIP của Dịch vụ Kubernetes đọc-ghi al-adbo-rw-ilb. AlloyDB Omni lắng nghe trên cổng PostgreSQL mặc định 5432.

Kiểm tra các tài nguyên mà toán tử đã điều chỉnh từ tệp kê khai DBCluster duy nhất – Pod cơ sở dữ liệu, DataDisk PersistentVolumeClaim và al-adbo-rw-ilb Service:

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

6. Nâng cấp lên Chế độ có tính sẵn sàng cao (HA) và bật Chế độ chờ chỉ có thể đọc

AlloyDB Omni cung cấp tính năng có sẵn cao (HA) tích hợp sẵn với tính năng sao chép trực tuyến, giám sát tình trạng tự động, chuyển đổi dự phòng tự động và phân phát bản sao chỉ đọc.

1. Bật tính năng HA và bản sao chỉ có thể đọc

Cập nhật thông số kỹ thuật DBCluster để định cấu hình 1 phiên bản dự phòng và bật tính năng định tuyến dự phòng chỉ có thể đọc:

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

2. Xác minh độ ổn định của HA

Chờ thực thể dự phòng cấp phép và đạt được trạng thái sao chép trực tuyến tốt (HAREADYSTATUS đạt True và HAREADYREASON đạt Ready), sau đó nhấn Ctrl+C để thoát khỏi chế độ xem:

kubectl get dbcluster adbo -n omni-demo -w

Kiểm tra điều kiện trạng thái HAReady:

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

Xác minh rằng cả điểm cuối đọc-ghi và điểm cuối chỉ có thể đọc đều được phát hành:

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

Kết quả mẫu:

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

Điểm cuối Đọc-Ghi (Dịch vụ al-adbo-rw-ilb) định tuyến đến cơ sở dữ liệu chính, trong khi điểm cuối Chỉ đọc (Dịch vụ al-adbo-ro-ilb) phân phối các truy vấn đọc trên các phiên bản dự phòng.

7. Định cấu hình Automated BackupPlans (Cục bộ và GCS)

AlloyDB Omni cung cấp tính năng sao lưu vật lý và lưu trữ WAL thông qua Tài nguyên tuỳ chỉnh BackupPlan. Bạn có thể định cấu hình thời gian lưu giữ bản sao lưu, lịch biểu cron tự động và mục tiêu sao lưu (ổ đĩa cố định cục bộ hoặc Google Cloud Storage).

1. Tạo BackupPlan cục bộ

Tạo một BackupPlan ghi bản sao lưu vào bộ nhớ Kubernetes cục bộ được đính kèm vào các thực thể cơ sở dữ liệu:

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

Xác minh rằng BackupPlan cục bộ đã sẵn sàng:

kubectl get backupplan backupplan-local -n omni-demo

Chờ cho đến khi PHASE báo cáo Ready và NEXTBACKUPTIME được lên lịch.

2. Tạo GCS BackupPlan (Cách 1: Chỉ Google Cloud – Không bắt buộc)

Để lưu trữ bản sao lưu bên ngoài trong một bộ chứa Google Cloud Storage, hãy tạo một bộ chứa GCS, định cấu hình khoá bí mật của tài khoản dịch vụ và áp dụng BackupPlan trên đám mây.

Tạo một bộ chứa Cloud Storage:

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

Tạo một tài khoản dịch vụ có quyền Quản trị viên đối tượng lưu trữ và tạo khoá cho tài khoản đó:

Thận trọng: Trình vận hành AlloyDB Omni đọc thông tin xác thực Cloud Storage từ khoá tài khoản dịch vụ mà bạn lưu trữ trong Kubernetes Secret. Tài liệu của nhà điều hành không đề cập đến các cách xác thực khác, chẳng hạn như Liên kết Workload Identity cho GKE. Nếu tổ chức của bạn thực thi chính sách tổ chức iam.disableServiceAccountKeyCreation, thì lệnh keys create sẽ không thành công. Trong trường hợp đó, hãy bỏ qua phần còn lại của bước Tạo GCS BackupPlan. Các bước còn lại của lớp học lập trình này sử dụng kế hoạch sao lưu cục bộ.

Khoá tài khoản dịch vụ là thông tin xác thực có thời hạn sử dụng dài. Bước tiếp theo sẽ xoá bản sao trên máy của bạn và bước dọn dẹp sẽ xoá tài khoản dịch vụ và khoá của tài khoản đó. Để biết thêm thông tin, hãy xem phần Tạo kế hoạch lưu trữ bản sao lưu trong 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"

Tạo khoá bí mật trong không gian tên Kubernetes:

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

Áp dụng tệp kê khai GCS BackupPlan. Trường key là thư mục trong bộ chứa mà toán tử ghi bản sao lưu vào. Tên này phải bắt đầu bằng /.

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

Xác minh trạng thái GCS BackupPlan:

kubectl get backupplan backupplan-gcs -n omni-demo

Chờ cho đến khi PHASE báo cáo Ready và NEXTBACKUPTIME được lên lịch.

8. Chèn dữ liệu, kích hoạt sao lưu và kiểm thử khôi phục

Trong bước này, bạn sẽ điền dữ liệu ban đầu vào cơ sở dữ liệu chính, kích hoạt bản sao lưu thủ công theo yêu cầu, thêm dữ liệu tiếp theo và khôi phục từ bản sao lưu để chứng minh việc khôi phục dữ liệu.

1. Điền sẵn dữ liệu ban đầu

Chạy một nhóm máy khách PostgreSQL tạm thời để kết nối với cơ sở dữ liệu thông qua Dịch vụ đọc-ghi al-adbo-rw-ilb với tư cách là người dùng 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;
  "

Khi được nhắc nhập mật khẩu, hãy nhập ChangeMe123. Đây là mật khẩu bạn đã mã hoá bằng base64 trong Bí mật db-pw-adbo ở Bước 5.

2. Kích hoạt tính năng sao lưu theo yêu cầu

Tạo tài nguyên tuỳ chỉnh Backup theo cách thủ công tham chiếu đến BackupPlan cục bộ:

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

Theo dõi tiến trình sao lưu:

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

Đợi cho đến khi PHASE chuyển sang Succeeded.

3. Thay đổi dữ liệu (Thêm bản ghi mới)

Chèn thêm bản ghi sau bản sao lưu:

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;
  "

Cơ sở dữ liệu hiện chứa 4 hàng.

4. Khôi phục từ bản sao lưu

Kích hoạt khôi phục về trạng thái được ghi lại trong 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

Theo dõi thao tác khôi phục:

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

Chờ cho đến khi PHASE đạt đến ProvisionSucceeded và xác minh rằng DBCluster trở về DBClusterReady:

kubectl get dbcluster adbo -n omni-demo -w

5. Xác minh trạng thái dữ liệu đã khôi phục

Truy vấn bảng customers để xác minh rằng chỉ có các bản ghi trước khi sao lưu:

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;
  "

Kết quả xác nhận chỉ có 2 hàng (Alpha Co và Beta LLC), xác minh rằng cơ sở dữ liệu đã được khôi phục về trạng thái sao lưu chính xác.

9. Khôi phục tại một thời điểm cụ thể (PITR) cho cơ sở dữ liệu được sao chép

Tính năng Khôi phục tại một thời điểm (PITR) cho phép khôi phục cơ sở dữ liệu về bất kỳ giây nào trong khoảng thời gian khôi phục bằng cách sử dụng bản sao lưu cơ sở và nhật ký luồng WAL, cung cấp dữ liệu đã khôi phục vào một cụm cơ sở dữ liệu mới được sao chép.

Vì toán tử liên tục lưu trữ Nhật ký ghi trước (WAL), nên PITR cho phép bạn khôi phục sau các lỗi vô tình do con người hoặc ứng dụng gây ra (ví dụ: DELETE hoặc DROP TABLE ngoài ý muốn lúc 2:15:00 chiều) bằng cách sao chép cơ sở dữ liệu đến đúng giây trước khi xảy ra lỗi (2:14:59 chiều) mà không cần chạm vào cụm ban đầu.

1. Ghi lại dấu thời gian hiện tại và thay đổi dữ liệu

Lấy dấu thời gian UTC hiện tại:

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

Chèn một bản ghi kiểm thử đại diện cho một nội dung sửa đổi không mong muốn sau dấu thời gian này:

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. Thực hiện khôi phục về một thời điểm

Áp dụng Tài nguyên tuỳ chỉnh Restore để định cấu hình pointInTime và 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

Theo dõi thao tác khôi phục cho đến khi PHASE đạt đến ProvisionSucceeded:

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

3. Xác minh cơ sở dữ liệu được sao chép

Sau khi quá trình khôi phục hoàn tất, hãy đợi DBCluster mới được sao chép đạt đến DBClusterReady (nhấn Ctrl+C để thoát khỏi chế độ xem):

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

Truy vấn cơ sở dữ liệu được sao chép adbo-cloned thông qua Dịch vụ đọc-ghi 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;
  "

Hãy lưu ý rằng Unwanted Record Post-Timestamp không có trong cụm được sao chép, cho thấy quá trình khôi phục chính xác đến đúng thời điểm mục tiêu.

10. Triển khai trình gộp kết nối PgBouncer

Tính năng gộp kết nối giúp giảm mức hao tổn bộ nhớ cơ sở dữ liệu và độ trễ kết nối. Trình vận hành quản lý các phiên bản PgBouncer theo cách gốc thông qua Tài nguyên tuỳ chỉnh PgBouncer.

PostgreSQL phân nhánh một quy trình hệ điều hành riêng biệt cho mọi kết nối máy khách, vì vậy, hàng trăm kết nối đồng thời từ các dịch vụ web, dịch vụ vi mô hoặc tác nhân AI có thể làm cạn kiệt bộ nhớ cơ sở dữ liệu. PgBouncer nằm trước cơ sở dữ liệu và ghép nhiều kết nối máy khách ngắn hạn (tối đa max_client_conn) vào một nhóm nhỏ các kết nối máy chủ PostgreSQL dài hạn (default_pool_size cho mỗi cặp người dùng/cơ sở dữ liệu, giới hạn ở max_db_connections).

1. Triển khai PgBouncer

Triển khai một trình gộp PgBouncer có 2 bản sao được liên kết với cụm 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. Xác minh trạng thái PgBouncer

Theo dõi trạng thái của PgBouncer cho đến khi PHASE là Ready:

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

Kiểm tra các nhóm và dịch vụ PgBouncer đang chạy:

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

3. Kết nối qua PgBouncer

Kết nối ứng dụng thông qua dịch vụ PgBouncer trên cổng 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 uỷ quyền truy vấn một cách liền mạch đến cơ sở dữ liệu AlloyDB Omni chính.

11. Triển khai pgAdmin4 để truy cập vào cơ sở dữ liệu

Bạn có thể chạy pgAdmin4 ngay trong cụm Kubernetes để cung cấp bảng điều khiển quản trị dựa trên nền tảng web nhằm truy vấn, quản lý và kiểm tra AlloyDB Omni.

1. Cài đặt pgAdmin4 qua Helm

Cài đặt pgadmin4 trong không gian tên 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"

Biểu đồ này đặt tên cho các tài nguyên Kubernetes là pgadmin4 (Triển khai, Dịch vụ, PersistentVolumeClaim) và gắn nhãn cho các Nhóm bằng app=pgadmin4, bất kể tên bản phát hành Helm (my-pgadmin).

Xác minh rằng nhóm pgAdmin4 đang chạy:

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

2. Chuyển tiếp cổng và truy cập vào giao diện người dùng web

Chuyển tiếp cổng pgAdmin4 đến môi trường cục bộ hoặc Cloud Shell:

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

kubectl port-forward sẽ tiếp tục chạy trên nền trước trong suốt thời gian bạn sử dụng giao diện người dùng web pgAdmin4. Mở một thiết bị đầu cuối thứ hai (hoặc một thẻ Cloud Shell mới) cho các lệnh khác và nhấn Ctrl+C trong thiết bị đầu cuối này khi bạn đã sẵn sàng chuyển sang bước tiếp theo.

Mở giao diện web pgAdmin4:

Cách 1 (Google Cloud Shell): Nhấp vào nút Web Preview (Xem trước trên web) trong trình đơn trên cùng bên phải, chọn Change port (Thay đổi cổng), nhập 5050 rồi nhấp vào Change and Preview (Thay đổi và xem trước).
Cách 2 (Máy trạm cục bộ): Mở http://localhost:5050 trong trình duyệt khi lệnh kubectl port-forward đang chạy.

Đăng nhập bằng:

Email: admin@example.com
Mật khẩu: AdminPassword123

3. Đăng ký AlloyDB Omni trong pgAdmin4

Trong pgAdmin4, hãy nhấp chuột phải vào Servers (Máy chủ) > Register (Đăng ký) > Server... (Máy chủ...).
Trong thẻ Chung:
- Tên: AlloyDB Omni Primary
Trong thẻ Kết nối:
- Tên/địa chỉ máy chủ lưu trữ: al-adbo-rw-ilb.omni-demo.svc.cluster.local (hoặc al-omni-pgbouncer-pgb-svc.omni-demo.svc.cluster.local cho PgBouncer)
- Cổng: 5432 (hoặc 6432 cho PgBouncer)
- Cơ sở dữ liệu bảo trì: postgres
- Tên người dùng: postgres
- Mật khẩu: ChangeMe123
Nhấp vào Lưu rồi xác minh phiên và bảng cơ sở dữ liệu đang hoạt động.

12. Mở rộng CPU và bộ nhớ bằng tính năng Bảo trì ít gây gián đoạn (LDTM)

Khi mở rộng quy mô theo chiều dọc cho tài nguyên điện toán và bộ nhớ trên cơ sở dữ liệu chính thức, các bản cập nhật truyền thống sẽ gây gián đoạn do phải khởi động lại cơ sở dữ liệu. AlloyDB Omni cung cấp tính năng Bảo trì ít gây gián đoạn (LDTM) để triển khai các bản cập nhật thông qua bản sao mà không gây gián đoạn nhiều cho ứng dụng.

1. Bật chú thích LDTM

Chú thích DBCluster để bật LDTM cho các bản cập nhật:

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

2. Mở rộng tài nguyên CPU và bộ nhớ

Cập nhật tài nguyên chính từ cpu: 1, memory: 4Gi thành cpu: 2, memory: 8Gi:

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

3. Theo dõi tiến trình điều chỉnh quy mô LDTM

Theo dõi bản cập nhật định kỳ và các điều kiện chuyển đổi từ chế độ chờ sang chế độ chính:

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

Quan sát các pod lăn một cách mượt mà:

kubectl get pods -n omni-demo -w

LDTM chuẩn bị trước phiên bản dự phòng đã cập nhật, xác minh việc sao chép trực tuyến, thực hiện chuyển đổi nhanh và cập nhật phiên bản còn lại mà không làm gián đoạn dịch vụ.

Xác minh mức phân bổ tài nguyên đã cập nhật:

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

13. Tài nguyên dọn dẹp

Để giải phóng dung lượng cụm và tránh các khoản phí không cần thiết cho tài khoản Google Cloud, hãy dọn dẹp các tài nguyên được cấp phát trong lớp học lập trình này.

Nếu bạn đang chạy quy trình dọn dẹp trong một phiên dòng lệnh mới (Đường dẫn 1), thì các biến môi trường từ các bước trước đó sẽ không còn được đặt nữa. Xuất lại các tệp đó bằng chính những giá trị bạn đã dùng trước đây:

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. Xoá khối lượng công việc của cơ sở dữ liệu (Đường dẫn 1 và Đường dẫn 2)

Đánh dấu cả hai cụm là đã xoá để vượt qua quy trình kiểm tra webhook kiểm soát, đợi toán tử xoá tài nguyên DBCluster, sau đó xoá không gian tên:

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

Nếu bạn đã sử dụng cụm Kubernetes của riêng mình (Cách 2) và cũng muốn xoá toán tử AlloyDB Omni và 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. Xoá bộ chứa GCS và tài khoản dịch vụ IAM (Chỉ dành cho Đường dẫn 1)

Nếu bạn đã tạo bộ chứa Google Cloud Storage và tài khoản dịch vụ trong Cách 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. Xoá cụm GKE (Chỉ đường dẫn 1)

Nếu bạn đã cấp phát một cụm GKE Autopilot trong Lộ trình 1:

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

14. Xin chúc mừng

Xin chúc mừng! Bạn đã hoàn thành lớp học lập trình về AlloyDB Omni trên Kubernetes.

Nội dung đã đề cập

Đã cấp phép một cụm GKE Autopilot (Đường dẫn 1) hoặc chuẩn bị một cụm Kubernetes hiện có (Đường dẫn 2).
Triển khai cert-manager và toán tử AlloyDB Omni Kubernetes thông qua Helm.
Đã triển khai một phiên bản AlloyDB Omni DBCluster.
Nâng cấp cụm lên cấu hình có tính sẵn sàng cao (HA) với các bản sao dự phòng đồng bộ và bật tính năng định tuyến đến bản sao dự phòng chỉ có thể đọc.
Tạo tài nguyên BackupPlan tự động cho cả bộ nhớ ổn định cục bộ và Google Cloud Storage (GCS).
Thực hiện sao lưu theo yêu cầu và xác thực việc khôi phục cơ sở dữ liệu.
Thực hiện khôi phục tại thời điểm (PITR) cho một cụm cơ sở dữ liệu mới được sao chép.
Triển khai trình gộp kết nối PgBouncer để có thể mở rộng kết nối máy khách.
Triển khai và kết nối pgAdmin4 để quản lý cơ sở dữ liệu.
Thực hiện Bảo trì ít thời gian ngừng hoạt động (LDTM) để linh hoạt điều chỉnh tài nguyên điện toán và bộ nhớ.

Các bước tiếp theo

Khám phá tính năng Khôi phục sau thảm hoạ (DR) của AlloyDB Omni trong môi trường nhiều cụm.
Tìm hiểu thêm về các chức năng của AlloyDB Omni AI và pgvector.

15. Khảo sát

Bạn sẽ sử dụng hướng dẫn này như thế nào?

Chỉ đọc qua

Đọc và hoàn thành bài tập