Halaman ini menampilkan dokumentasi untuk AlloyDB Omni versi 15.7.0.
Buka versi dokumentasi AlloyDB Omni untuk memilih versi yang berbeda.

Halaman ini diterjemahkan oleh Cloud Translation API.

Mengkloning cluster database di Kubernetes menggunakan pencadangan lokal

Dokumen ini menjelaskan cara meng-clone cluster database di Kubernetes menggunakan cadangan lokal cluster database AlloyDB Omni.

Dokumen ini membuat asumsi berikut:

Cluster database sumber dan target Anda dibuat di Google Kubernetes Engine, dan disk cadangan adalah persistent disk Compute Engine.
Persistent disk Compute Engine yang digunakan sebagai disk cadangan di database tidak digunakan oleh cluster database lainnya.

Saat meng-clone cluster database, Anda harus mengikuti langkah-langkah berikut:

Identifikasi informasi disk cadangan, seperti nama volume persisten dan pengendali persistent disk Compute Engine untuk disk cadangan cluster database sumber. Pastikan Anda mengaktifkan fitur pencadangan untuk cluster database sumber, dan Anda memiliki setidaknya satu pencadangan yang berhasil. Jika kondisi ini tidak terpenuhi, ikuti petunjuk di Mengaktifkan dan menjadwalkan pencadangan.
Buat resource PersistentVolume untuk menggunakan disk cadangan yang ada di cluster database target guna mengakses disk cadangan cluster database sumber.
Buat dan terapkan file manifes resource DBCluster di cluster database target dengan parameter livenessProbe dinonaktifkan dan informasi disk cadangan ditambahkan.
Gunakan perintah pgBackRest untuk memverifikasi bahwa cadangan sumber dapat diakses.
Gunakan perintah pgBackRest untuk memulihkan cadangan ke cluster database target.

Sebelum memulai

Pastikan Anda memiliki akses ke disk cadangan tempat cadangan cluster database sumber Anda disimpan.
Disk cadangan cluster database sumber harus dapat di-mount ke cluster database target. Untuk mengetahui informasi selengkapnya, lihat Volume Persisten. Jika backend penyimpanan yang mendasarinya tidak mendukung akses ReadOnlyMany (ROX), pastikan disk cadangan tidak digunakan oleh pod apa pun di cluster sumber.
Karena disk cadangan sumber dipasang ke cluster database target, file pgBackRest.conf akan digunakan kembali apa adanya.
Pastikan Anda login ke database sebagai pengguna postgres.

Mendapatkan informasi disk cadangan sumber

Sebagai bagian dari proses pemulihan, tentukan nama Persistent Volume Claim (PVC) disk cadangan untuk cluster database sumber Anda. PVC digunakan dalam Kubernetes untuk mengelola penyimpanan persisten untuk aplikasi.

Contoh perintah berikut membantu menemukan nama PV yang mendasarinya dan pengendali disk persisten Compute Engine. Dalam contoh ini, semua disk cadangan adalah persistent disk Compute Engine, yang dapat diakses di seluruh VM Compute Engine menggunakan ID pengendali disk.

Hubungkan ke cluster database target untuk menemukan nama PVC:
```
 kubectl get pvc -n DB_CLUSTER_NAMESPACE | grep DB_CLUSTER_NAME | grep backuprepodisk
```
Ganti kode berikut:
- DB_CLUSTER_NAMESPACE: namespace Kubernetes untuk rencana cadangan ini. Nama ini harus cocok dengan namespace cluster database.
- DB_CLUSTER_NAME: nama cluster database ini—misalnya, my-db-cluster.
Berikut adalah contoh responsnya.
```
    backuprepodisk-my-db-cluster-br-0   Bound
    pvc-36d8f05d-ef1a-4750-ac01-9bb330c15b3a   10Gi       RWO            standard-rwo   5d21h
```
Gunakan nama PVC disk cadangan dari langkah sebelumnya—misalnya, backuprepodisk-my-db-cluster-br-0, untuk menemukan nama PV yang mendasarinya dan pengendali persistent disk Compute Engine:
```
  kubectl get pvc/PVC_NAME -n DB_CLUSTER_NAMESPACE -o jsonpath={.spec.volumeName}
```
Ganti kode berikut:
- PVC_NAME: nama PVC disk cadangan dari respons di langkah sebelumnya—misalnya backuprepodisk-my-db-cluster-br-0.

Ekspor konfigurasi berdasarkan nama PV sebagai variabel yang akan digunakan di bagian berikutnya:

  export BACKUP_DISK_SIZE=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.capacity.storage}")
  export FS_TYPE=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.csi.fsType}")
  export VOLUME_HANDLER=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.csi.volumeHandle}")
  export STORAGE_CLASS=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.storageClassName}")

Ganti kode berikut:

PV_NAME: nama PV disk cadangan dari respons di langkah sebelumnya. Misalnya, "backupDiskVolume".

Membuat resource volume persisten

Dengan menggunakan nama pengendali disk, buat resource PersistentVolume.

Di cluster Kubernetes target, buat file manifes PersistentVolume:

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: PV_NAME
    spec:
      storageClassName: "${STORAGE_CLASS}"
      capacity:
        storage: "${BACKUP_DISK_SIZE}"
      accessModes:
        - ReadWriteOnce
      csi:
        driver: pd.csi.storage.gke.io
        volumeHandle: "${VOLUME_HANDLER}"
        fsType: "${FS_TYPE}"

Ganti kode berikut:

PV_NAME: nama resource PersistentVolume yang akan dibuat.

Terapkan file manifes:
```
  kubectl apply -f PV_FILENAME
```
Ganti kode berikut:
- PV_FILENAME: nama file manifes PersistentVolume yang dibuat di langkah sebelumnya.

Membuat cluster database target

Buat cluster database dengan menonaktifkan parameter livenessProbe untuk sementara. Setelah pemulihan selesai, konfigurasi ulang parameter livenessProbe.

Buat file manifes DBCluster:

  apiVersion: v1
  kind: Secret
  metadata:
    name: db-pw-DB_CLUSTER_NAME
  type: Opaque
  data:
    DB_CLUSTER_NAME: "ENCODED_PASSWORD"
  ---
  apiVersion: alloydbomni.dbadmin.goog/v1
  kind: DBCluster
  metadata:
    name: DB_CLUSTER_NAME
  spec:
    databaseVersion: "15.7.0"
    primarySpec:
      availabilityOptions:
        livenessProbe: "Disabled"
      adminUser:
        passwordRef:
          name: db-pw-DB_CLUSTER_NAME
      resources:
        cpu: CPU_COUNT
        memory: MEMORY_SIZE
        disks:
        - name: DataDisk
          size: DATA_DISK_SIZE
        - name: BackupDisk
          size: ${BACKUP_DISK_SIZE}
          storageClass: ${STORAGE_CLASS}
          volumeName: PV_NAME

Ganti kode berikut:

DB_CLUSTER_NAME: nama cluster database ini—misalnya, my-db-cluster.
ENCODED_PASSWORD: sandi login database untuk peran pengguna postgres default, yang dienkode sebagai string base64—misalnya, Q2hhbmdlTWUxMjM= untuk ChangeMe123.
CPU_COUNT: jumlah CPU yang tersedia untuk setiap instance database dalam cluster database ini.
MEMORY_SIZE: jumlah memori per instance database dari cluster database ini. Sebaiknya tetapkan ke 8 gigabyte per CPU. Misalnya, jika Anda menetapkan CPU_COUNT ke 2, sebaiknya tetapkan memory ke 16Gi.
DATA_DISK_SIZE: ukuran disk per instance database, misalnya, 10Gi.

Terapkan file manifes:
```
  kubectl apply -f DBCLUSTER_FILENAME
```
Ganti kode berikut:
- DBCLUSTER_FILENAME: nama file manifes DBCluster yang dibuat di langkah sebelumnya.

Gunakan perintah kubectl describe untuk memverifikasi bahwa resource cluster database berada dalam status READY.

Memverifikasi cadangan sumber di cluster database target

Jalankan perintah pgBackRest untuk memverifikasi bahwa cadangan cluster database sumber dapat diakses di cluster database target.

Di cluster database target, temukan detail pod cluster database:

  kubectl get pod -l "alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME, alloydbomni.internal.dbadmin.goog/task-type=database"

Respons menyertakan nama pod database cluster.

Login ke pod database:
```
  kubectl exec -ti DATABASE_POD_NAME  -- /bin/bash
```
Ganti kode berikut:
- DATABASE_POD_NAME : nama pod cluster database dari langkah sebelumnya.
Hentikan pod sebelum mengupdate file konfigurasi pgBackRest:
```
  supervisorctl.par stop postgres
```

Update file konfigurasi pgBackRest:

  cp /backup/pgbackrest.conf /backup/pgbackrest.conf.bak
  rm /backup/pgbackrest.conf
  cat << EOF > /backup/pgbackrest.conf
  [db]
  pg1-path=/mnt/disks/pgsql/data
  pg1-socket-path=/tmp
  pg1-user=pgbackrest
  [global]
  log-path=/backup/logs
  log-level-file=info
  EOF

Verifikasi cadangan sumber di pod cluster database:

pgbackrest --config-path=/backup --stanza=db --repo=1 info

Berikut adalah contoh respons:

  stanza: db
      status: ok
      cipher: none
      db (current)
          wal archive min/max (15): 000000010000000000000002/00000001000000000000000D
          full backup: 20240213-231400F
              timestamp start/stop: 2024-02-13 23:14:00+00 / 2024-02-13 23:17:14+00
              wal start/stop: 000000010000000000000003 / 000000010000000000000003
              database size: 38.7MB, database backup size: 38.7MB
              repo1: backup set size: 4.6MB, backup size: 4.6MB
          incr backup: 20240213-231400F_20240214-000001I
              timestamp start/stop: 2024-02-14 00:00:01+00 / 2024-02-14 00:00:05+00
              wal start/stop: 00000001000000000000000D / 00000001000000000000000D
              database size: 38.7MB, database backup size: 488.3KB
              repo1: backup set size: 4.6MB, backup size: 84.2KB
              backup reference list: 20240213-231400F

Stempel waktu dalam respons digunakan untuk memulihkan cadangan lengkap atau memulihkan dari titik waktu dari periode pemulihan.

Memulihkan cadangan di cluster database target

Setelah mengidentifikasi cadangan atau titik waktu yang ingin Anda pulihkan, jalankan perintah pgBackRest di cluster database target. Untuk mengetahui informasi selengkapnya tentang perintah ini, lihat Perintah Pemulihan.

Berikut adalah beberapa contoh perintah pemulihan pgBackRest:

Memulihkan dari cadangan

pgbackrest --config-path=/backup --stanza=db --repo=1 restore --set=20240213-231400F --type=immediate --target-action=promote --delta --link-all --log-level-console=info

Memulihkan dari titik waktu

pgbackrest --config-path=/backup --stanza=db --repo=1 restore --target="2024-01-22 11:27:22" --type=time --target-action=promote --delta --link-all --log-level-console=info

Mulai ulang pod

Setelah perintah pemulihan berhasil diselesaikan, Anda dapat memulai proses postgres.

supervisorctl.par start postgres

Setelah proses postgres dimulai, Anda dapat terhubung ke instance utama dan menjalankan kueri untuk memverifikasi bahwa data dipulihkan dari cadangan. Untuk mengetahui informasi selengkapnya, lihat Menghubungkan ke AlloyDB Omni yang berjalan di Kubernetes.

Mengonfigurasi cluster database

Setelah meng-clone cluster database, konfigurasikan spesifikasi cluster database Anda. Pastikan untuk mengaktifkan parameter livenessProbe menggunakan perintah berikut:

    kubectl patch dbcluster DBCLUSTER_FILENAME --type merge -p '{"spec":{"primarySpec":{"availabilityOptions":{"livenessProbe":"Enabled"}}}}'

Langkah selanjutnya

Mengkloning cluster database di Kubernetes menggunakan cadangan Cloud Storage