Halaman ini menunjukkan cara meng-clone cluster database di Kubernetes menggunakan cadangan lokal cluster database AlloyDB Omni.
Langkah-langkah di halaman ini mengasumsikan bahwa cluster database sumber dan target Anda dibuat di Google Kubernetes Engine, dan disk cadangan adalah persistent disk Compute Engine. Hal ini juga mengasumsikan bahwa persistent disk Compute Engine yang digunakan sebagai cadangan di database tidak digunakan oleh cluster database lainnya.
Alur kerja berikut menjelaskan langkah-langkah yang digunakan untuk meng-clone:
- Identifikasi informasi disk cadangan, seperti nama volume persisten dan pengendali persistent disk Compute Engine, untuk disk cadangan cluster database sumber.
- 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 parameterlivenessProbe
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 tentang langkah-langkah untuk memastikan disk Anda dapat dipasang, lihat Volume Persistent.
- 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—misalnyabackuprepodisk-my-db-cluster-br-0
.
Ekspor konfigurasi berdasarkan nama PV sebagai variabel yang akan digunakan di bagian berikutnya:
export 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.
Membuat resource volume persisten di cluster database target
Dengan menggunakan nama pengendali disk, buat resource PersistentVolume
.
Di cluster database target, buat file manifes
PersistentVolume
:apiVersion: v1 kind: PersistentVolume metadata: name: backupdisk spec: storageClassName: "${STORAGE_CLASS}" capacity: storage: "${DISK_SIZE}" accessModes: - ReadWriteOnce csi: driver: pd.csi.storage.gke.io volumeHandle: "${VOLUME_HANDLER}" fsType: "${FS_TYPE}"
Terapkan file manifes:
kubectl apply -f PV_FILENAME
Ganti kode berikut:
- PV_FILENAME: nama file manifes
PersistentVolume
yang dibuat di langkah sebelumnya.
- PV_FILENAME: nama file manifes
Membuat cluster database target
Buat cluster database dengan menonaktifkan parameter livenessProbe
untuk sementara saat proses pemulihan selesai.
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: primarySpec: availabilityOptions: livenessProbe: "Disabled" adminUser: passwordRef: name: db-pw-DB_CLUSTER_NAME resources: memory: 100Gi cpu: 10 disks: - name: DataDisk size: 40Gi - name: BackupDisk size: ${DISK_SIZE} storageClass: ${STORAGE_CLASS} volumeName: backupdisk
Ganti kode berikut:
DB_CLUSTER_NAME
: nama cluster database ini—misalnya,my-db-cluster
.ENCODED_PASSWORD
: sandi login database untuk peran penggunapostgres
default, yang dienkode sebagai string base64—misalnya,Q2hhbmdlTWUxMjM=
untukChangeMe123
.
Terapkan file manifes:
kubectl apply -f DBCLUSTER_FILENAME
Ganti kode berikut:
- DBCLUSTER_FILENAME: nama file manifes
DBCluster
yang dibuat di langkah sebelumnya.
- DBCLUSTER_FILENAME: nama file manifes
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 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 selesai, 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.