PostgreSQL adalah database relasional objek open source yang dikenal karena keandalan dan integritas data. Metode ini mematuhi ACID, dan mendukung kunci asing, gabungan, tampilan, pemicu, dan prosedur tersimpan.
Dokumen ini ditujukan bagi administrator database, arsitek cloud, dan profesional operasi yang tertarik untuk men-deploy topologi PostgreSQL yang sangat tersedia di Google Kubernetes Engine (GKE).
Tujuan
Dalam tutorial ini, Anda akan mempelajari cara:- Menggunakan Terraform untuk membuat cluster GKE regional.
- Men-deploy database PostgreSQL yang sangat tersedia.
- Menyiapkan pemantauan untuk aplikasi PostgreSQL.
- Melakukan upgrade database PostgreSQL dan cluster GKE.
- Melakukan simulasi gangguan cluster dan failover replika PostgreSQL.
- Melakukan pencadangan dan pemulihan database PostgreSQL.
Arsitektur
Bagian ini menjelaskan arsitektur solusi yang akan Anda buat dalam tutorial ini.
Anda akan menyediakan dua cluster GKE di region yang berbeda: cluster primer dan cluster cadangan. Untuk tutorial ini, cluster utama berada di region us-central1
dan cluster cadangan berada di region us-west1
. Arsitektur ini memungkinkan Anda menyediakan database PostgreSQL yang sangat tersedia dan melakukan pengujian untuk pemulihan dari bencana (disaster recovery), seperti yang akan dijelaskan nanti dalam tutorial ini.
Untuk cluster sumber, Anda akan menggunakan diagram Helm (bitnami/postgresql-ha
) untuk menyiapkan cluster PostgreSQL dengan ketersediaan tinggi.
Biaya
Dalam dokumen ini, Anda akan menggunakan komponen Google Cloud yang dapat ditagih berikut:
Untuk membuat perkiraan biaya berdasarkan proyeksi penggunaan Anda,
gunakan kalkulator harga.
Setelah menyelesaikan tugas yang dijelaskan dalam dokumen ini, Anda dapat menghindari penagihan berkelanjutan dengan menghapus resource yang Anda buat. Untuk mengetahui informasi selengkapnya, lihat Pembersihan.
Sebelum memulai
Menyiapkan project
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
-
In the Google Cloud console, on the project selector page, click Create project to begin creating a new Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the Google Kubernetes Engine, Backup for GKE, Artifact Registry, Compute Engine, and IAM APIs.
-
In the Google Cloud console, on the project selector page, click Create project to begin creating a new Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the Google Kubernetes Engine, Backup for GKE, Artifact Registry, Compute Engine, and IAM APIs.
Menyiapkan peran
-
Grant roles to your user account. Run the following command once for each of the following IAM roles:
role/storage.objectViewer, role/logging.logWriter, role/artifactregistry.Admin, roles/container.clusterAdmin, role/container.serviceAgent, roles/serviceusage.serviceUsageAdmin, roles/iam.serviceAccountAdmin
gcloud projects add-iam-policy-binding PROJECT_ID --member="user:USER_IDENTIFIER" --role=ROLE
- Replace
PROJECT_ID
with your project ID. -
Replace
USER_IDENTIFIER
with the identifier for your user account. For example,user:myemail@example.com
. - Replace
ROLE
with each individual role.
- Replace
Menyiapkan lingkungan Anda
Dalam tutorial ini, Anda akan menggunakan Cloud Shell untuk mengelola resource yang dihosting di Google Cloud. Cloud Shell telah diinstal dengan software yang akan Anda perlukan untuk tutorial ini, termasuk Docker, kubectl
, gcloud CLI, Helm, dan Terraform.
Untuk menggunakan Cloud Shell guna menyiapkan lingkungan Anda:
Luncurkan sesi Cloud Shell dari Konsol Google Cloud, dengan mengklik Activate Cloud Shell di Konsol Google Cloud. Tindakan ini akan meluncurkan sesi di panel bawah Konsol Google Cloud.
Menetapkan variabel lingkungan.
export PROJECT_ID=PROJECT_ID export SOURCE_CLUSTER=cluster-db1 export REGION=us-central1
Ganti nilai berikut:
- PROJECT_ID: project ID Google Cloud Anda.
Tetapkan variabel lingkungan default.
gcloud config set project PROJECT_ID
Buat clone repositori kode.
git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
Ubah ke direktori kerja.
cd kubernetes-engine-samples/databases/gke-stateful-postgres
Membuat infrastruktur cluster
Di bagian ini, Anda akan menjalankan skrip Terraform untuk membuat Virtual Private Cloud (VPC) kustom, repositori Artifact Registry untuk menyimpan image PostgreSQL, dan dua cluster GKE regional.
Satu cluster akan di-deploy di us-central1
dan cluster kedua untuk pencadangan akan di-deploy di us-west1
.
Untuk membuat cluster, ikuti langkah-langkah berikut:
Autopilot
Di Cloud Shell jalankan perintah berikut:
terraform -chdir=terraform/gke-autopilot init
terraform -chdir=terraform/gke-autopilot apply -var project_id=$PROJECT_ID
Saat diminta, ketik yes
.
Memahami konfigurasi Terraform
File konfigurasi Terraform membuat resource berikut untuk men-deploy infrastruktur Anda:
- Membuat repositori Artifact Registry untuk menyimpan image Docker.
- Membuat jaringan VPC dan subnet untuk antarmuka jaringan VM.
Membuat cluster GKE utama.
Terraform membuat cluster pribadi di region
us-central1
, dan mengaktifkan Pencadangan untuk GKE demi pemulihan dari bencana (disaster recovery) dan Google Cloud Managed Service for Prometheus untuk pemantauan cluster.Google Cloud Managed Service untuk Prometheus hanya didukung di cluster Autopilot yang menjalankan GKE versi 1.25 atau yang lebih baru.
Membuat cluster cadangan di region
us-west1
untuk pemulihan dari bencana (disaster recovery).
Standard
Di Cloud Shell jalankan perintah berikut:
terraform -chdir=terraform/gke-standard init
terraform -chdir=terraform/gke-standard apply -var project_id=$PROJECT_ID
Saat diminta, ketik yes
.
Memahami konfigurasi Terraform
File konfigurasi Terraform membuat resource berikut untuk men-deploy infrastruktur Anda:
- Membuat repositori Artifact Registry untuk menyimpan image Docker.
- Membuat jaringan VPC dan subnet untuk antarmuka jaringan VM.
Membuat cluster GKE utama.
Terraform membuat cluster pribadi di region
us-central1
, dan mengaktifkan Pencadangan untuk GKE demi pemulihan dari bencana (disaster recovery) dan Google Cloud Managed Service for Prometheus untuk pemantauan cluster.Membuat cluster cadangan di region
us-west1
untuk pemulihan dari bencana (disaster recovery).
Men-deploy PostgreSQL di cluster Anda
Di bagian ini, Anda akan men-deploy instance database PostgreSQL untuk menjalankan GKE menggunakan chart Helm.
Menginstal PostgreSQL
Untuk menginstal PostgreSQL di cluster Anda, ikuti langkah-langkah berikut.
Mengonfigurasi akses Docker.
gcloud auth configure-docker us-docker.pkg.dev
Isi Artifact Registry dengan image Docker PostgreSQL yang diperlukan.
./scripts/gcr.sh bitnami/postgresql-repmgr 15.1.0-debian-11-r0 ./scripts/gcr.sh bitnami/postgres-exporter 0.11.1-debian-11-r27 ./scripts/gcr.sh bitnami/pgpool 4.3.3-debian-11-r28
Skrip ini mengirim image Bitnami berikut ke Artifact Registry agar dapat diinstal oleh Helm:
postgresql-repmgr
: Solusi cluster PostgreSQL ini mencakup pengelola replikasi PostgreSQL (repmgr), alat open source untuk mengelola replikasi dan failover pada cluster PostgreSQL.postgres-exporter
: Pengekspor PostgreSQL mengumpulkan metrik PostgreSQL untuk penggunaan Prometheus.pgpool
: Pgpool-II adalah proxy PostgreSQL. Platform ini menyediakan penggabungan koneksi dan load balancing.
Pastikan gambar yang benar disimpan di repo.
gcloud artifacts docker images list us-docker.pkg.dev/$PROJECT_ID/main \ --format="flattened(package)"
Outputnya mirip dengan hal berikut ini:
--- image: us-docker.pkg.dev/[PROJECT_ID]/main/bitnami/pgpool --- image: us-docker.pkg.dev/[PROJECT_ID]/main/bitnami/postgres-exporter --- image: us-docker.pkg.dev/h[PROJECT_ID]/main/bitnami/postgresql-repmgr
Konfigurasi akses command line
kubectl
ke cluster utama.gcloud container clusters get-credentials $SOURCE_CLUSTER \ --region=$REGION --project=$PROJECT_ID
Membuat namespace.
export NAMESPACE=postgresql kubectl create namespace $NAMESPACE
Jika Anda men-deploy ke cluster Autopilot, konfigurasikan penyediaan node di tiga zona. Langkah ini dapat dilewati jika Anda men-deploy ke cluster Standar.
Secara default, Autopilot menyediakan sumber daya hanya di dua zona. Deployment yang ditentukan dalam
prepareforha.yaml
memastikan bahwa Autopilot menyediakan node di tiga zona dalam cluster Anda, dengan menetapkan nilai berikut:replicas:3
podAntiAffinity
denganrequiredDuringSchedulingIgnoredDuringExecution
dantopologyKey: "topology.kubernetes.io/zone"
kubectl -n $NAMESPACE apply -f scripts/prepareforha.yaml
Mengupdate dependensi Helm.
cd helm/postgresql-bootstrap helm dependency update
Periksa dan verifikasi diagram yang akan diinstal Helm.
helm -n postgresql template postgresql . \ --set global.imageRegistry="us-docker.pkg.dev/$PROJECT_ID/main"
Instal diagram Helm.
helm -n postgresql upgrade --install postgresql . \ --set global.imageRegistry="us-docker.pkg.dev/$PROJECT_ID/main"
Outputnya mirip dengan hal berikut ini:
NAMESPACE: postgresql STATUS: deployed REVISION: 1 TEST SUITE: None
Pastikan replika PostgreSQL berjalan.
kubectl get all -n $NAMESPACE
Outputnya mirip dengan hal berikut ini:
NAME READY STATUS RESTARTS AGE pod/postgresql-postgresql-bootstrap-pgpool-75664444cb-dkl24 1/1 Running 0 8m39s pod/postgresql-postgresql-ha-pgpool-6d86bf9b58-ff2bg 1/1 Running 0 8m39s pod/postgresql-postgresql-ha-postgresql-0 2/2 Running 0 8m39s pod/postgresql-postgresql-ha-postgresql-1 2/2 Running 0 8m39s pod/postgresql-postgresql-ha-postgresql-2 2/2 Running 0 8m38s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/postgresql-postgresql-ha-pgpool ClusterIP 192.168.99.236 <none> 5432/TCP 8m39s service/postgresql-postgresql-ha-postgresql ClusterIP 192.168.90.20 <none> 5432/TCP 8m39s service/postgresql-postgresql-ha-postgresql-headless ClusterIP None <none> 5432/TCP 8m39s service/postgresql-postgresql-ha-postgresql-metrics ClusterIP 192.168.127.198 <none> 9187/TCP 8m39s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/postgresql-postgresql-bootstrap-pgpool 1/1 1 1 8m39s deployment.apps/postgresql-postgresql-ha-pgpool 1/1 1 1 8m39s NAME DESIRED CURRENT READY AGE replicaset.apps/postgresql-postgresql-bootstrap-pgpool-75664444cb 1 1 1 8m39s replicaset.apps/postgresql-postgresql-ha-pgpool-6d86bf9b58 1 1 1 8m39s NAME READY AGE statefulset.apps/postgresql-postgresql-ha-postgresql 3/3 8m39s
Membuat set data pengujian
Di bagian ini, Anda akan membuat database dan tabel dengan nilai sampel. Database berfungsi sebagai set data pengujian untuk proses failover yang akan Anda uji nanti dalam tutorial ini.
Menghubungkan ke instance PostgreSQL Anda.
cd ../../ ./scripts/launch-client.sh
Outputnya mirip dengan hal berikut ini:
Launching Pod pg-client in the namespace postgresql ... pod/pg-client created waiting for the Pod to be ready Copying script files to the target Pod pg-client ... Pod: pg-client is healthy
Mulai sesi shell.
kubectl exec -it pg-client -n postgresql -- /bin/bash
Buat database dan tabel, lalu masukkan beberapa baris pengujian.
psql -h $HOST_PGPOOL -U postgres -a -q -f /tmp/scripts/generate-db.sql
Verifikasi jumlah baris untuk setiap tabel.
psql -h $HOST_PGPOOL -U postgres -a -q -f /tmp/scripts/count-rows.sql
Outputnya mirip dengan hal berikut ini:
select COUNT(*) from tb01; count -------- 300000 (1 row) select COUNT(*) from tb02; count -------- 300000 (1 row)
Membuat data pengujian.
export DB=postgres pgbench -i -h $HOST_PGPOOL -U postgres $DB -s 50
Outputnya mirip dengan hal berikut ini:
dropping old tables... creating tables... generating data (client-side)... 5000000 of 5000000 tuples (100%) done (elapsed 29.85 s, remaining 0.00 s) vacuuming... creating primary keys... done in 36.86 s (drop tables 0.00 s, create tables 0.01 s, client-side generate 31.10 s, vacuum 1.88 s, primary keys 3.86 s).
Keluar dari Pod klien postgres.
exit
Memantau PostgreSQL
Di bagian ini, Anda akan melihat metrik dan menyiapkan pemberitahuan untuk instance PostgreSQL. Anda akan menggunakan Google Cloud Managed Service for Prometheus untuk melakukan pemantauan dan pemberitahuan.
Lihat metrik
Deployment PostgreSQL Anda menyertakan container file bantuan postgresql-exporter
. Container ini mengekspos endpoint /metrics
.
Google Cloud Managed Service for Prometheus dikonfigurasi untuk memantau Pod PostgreSQL di endpoint ini. Anda dapat melihat metrik ini melalui dasbor Konsol Google Cloud.
Konsol Google Cloud menyediakan beberapa cara untuk membuat dan menyimpan konfigurasi dasbor:
- Pembuatan dan Ekspor: Anda dapat membuat dasbor langsung di Konsol Google Cloud, lalu mengekspor dan menyimpannya di repositori kode. Untuk melakukannya, di toolbar dasbor, buka editor JSON dan download file JSON dasbor.
- Penyimpanan dan Impor: Anda dapat mengimpor dasbor dari file JSON dengan mengklik +Create Dasboard dan mengupload konten JSON dasbor menggunakan editor JSON).
Untuk memvisualisasikan data dari aplikasi PostgreSQL dan cluster GKE, ikuti langkah-langkah berikut:
Buat dasbor berikut.
cd monitoring gcloud monitoring dashboards create \ --config-from-file=dashboard/postgresql-overview.json \ --project=$PROJECT_ID gcloud monitoring dashboards create \ --config-from-file dashboard/gke-postgresql.json \ --project $PROJECT_ID
Di konsol Google Cloud, buka Dasbor Cloud Monitoring. Buka Dasbor Cloud Monitoring
Pilih Custom dari daftar dasbor. Dasbor berikut akan muncul:
- PostgreSQL Overview: Menampilkan metrik dari aplikasi PostgreSQL, termasuk waktu beroperasi database, ukuran database, dan latensi transaksi.
- GKE PostgreSQL GKCluster E: Menampilkan metrik dari cluster GKE tempat PostgreSQL berjalan, termasuk penggunaan CPU, penggunaan memori, dan pemanfaatan volume.
Klik setiap link untuk memeriksa dasbor yang dihasilkan.
Menyiapkan pemberitahuan
Pemberitahuan akan memberi Anda kesadaran yang tepat waktu tentang masalah di aplikasi sehingga Anda dapat menyelesaikan masalah ini dengan cepat. Anda dapat membuat kebijakan pemberitahuan untuk menentukan situasi saat Anda ingin mendapatkan pemberitahuan dan cara mendapatkan pemberitahuan. Anda juga dapat membuat saluran notifikasi yang memungkinkan Anda memilih tujuan pengiriman notifikasi.
Di bagian ini, Anda akan menggunakan Terraform untuk mengonfigurasi contoh pemberitahuan berikut:
db_max_transaction
: Memantau keterlambatan maksimum transaksi dalam hitungan detik; peringatan akan dipicu jika nilainya lebih besar dari 10.db_node_up
: Memantau status Pod database; 0 berarti Pod mati dan memicu pemberitahuan.
Untuk menyiapkan pemberitahuan, ikuti langkah-langkah berikut:
Mengonfigurasi pemberitahuan dengan Terraform.
EMAIL=YOUR_EMAIL cd alerting/terraform terraform init terraform plan -var project_id=$PROJECT_ID -var email_address=$EMAIL terraform apply -var project_id=$PROJECT_ID -var email_address=$EMAIL
Ganti nilai berikut:
- YOUR_EMAIL: alamat email Anda.
Outputnya mirip dengan hal berikut ini:
Apply complete! Resources: 3 added, 0 changed, 0 destroyed.
Menghubungkan ke Pod klien.
cd ../../../ kubectl exec -it --namespace postgresql pg-client -- /bin/bash
Buat pengujian beban untuk menguji pemberitahuan
db_max_transaction
.pgbench -i -h $HOST_PGPOOL -U postgres -s 200 postgres
Outputnya mirip dengan hal berikut ini:
dropping old tables... creating tables... generating data (client-side)... 20000000 of 20000000 tuples (100%) done (elapsed 163.22 s, remaining 0.00 s) vacuuming... creating primary keys... done in 191.30 s (drop tables 0.14 s, create tables 0.01 s, client-side generate 165.62 s, vacuum 4.52 s, primary keys 21.00 s).
Pemberitahuan ini memicu dan mengirim email ke YOUR_EMAIL dengan baris subjek yang diawali dengan "[ALERT] Maksimal Jeda transaksi".
Di konsol Google Cloud, buka halaman Alert Policy.
Pilih
db_max_transaction
dari kebijakan yang tercantum. Dari diagram, Anda akan melihat lonjakan dari pengujian beban yang melebihi penahanan nilai minimum 10 untuk metrik Prometheuspg_stat_activity_max_tx_duration/gauge
.Keluar dari Pod klien postgres.
exit
Mengelola upgrade PostgreSQL dan GKE
Update versi untuk PostgreSQL dan Kubernetes dirilis secara rutin. Ikuti praktik terbaik operasional untuk mengupdate lingkungan software Anda secara rutin. Secara default, GKE mengelola upgrade cluster dan kumpulan node untuk Anda.
Mengupgrade PostgreSQL
Bagian ini menunjukkan cara melakukan upgrade versi untuk PostgreSQL. Untuk tutorial ini, Anda akan menggunakan strategi update berkelanjutan untuk mengupgrade Pod, sehingga semua Pod tidak mengalami penghentian.
Untuk melakukan upgrade versi, ikuti langkah-langkah berikut:
Kirim versi image
postgresql-repmgr
yang telah diupdate ke Artifact Registry. Tentukan versi baru (misalnya,postgresql-repmgr 15.1.0-debian-11-r1
).NEW_IMAGE=us-docker.pkg.dev/$PROJECT_ID/main/bitnami/postgresql-repmgr:15.1.0-debian-11-r1 ./scripts/gcr.sh bitnami/postgresql-repmgr 15.1.0-debian-11-r1
Picu update berkelanjutan menggunakan
kubectl
.kubectl set image statefulset -n postgresql postgresql-postgresql-ha-postgresql postgresql=$NEW_IMAGE kubectl rollout restart statefulsets -n postgresql postgresql-postgresql-ha-postgresql kubectl rollout status statefulset -n postgresql postgresql-postgresql-ha-postgresql
Anda akan melihat StatefulSet menyelesaikan update berkelanjutan, dimulai dengan replika ordinal tertinggi hingga terendah.
Outputnya mirip dengan hal berikut ini:
Waiting for 1 pods to be ready... waiting for statefulset rolling update to complete 1 pods at revision postgresql-postgresql-ha-postgresql-5c566ccf49... Waiting for 1 pods to be ready... Waiting for 1 pods to be ready... waiting for statefulset rolling update to complete 2 pods at revision postgresql-postgresql-ha-postgresql-5c566ccf49... Waiting for 1 pods to be ready... Waiting for 1 pods to be ready... statefulset rolling update complete 3 pods at revision postgresql-postgresql-ha-postgresql-5c566ccf49...
Merencanakan upgrade GKE pada cluster Standar
Bagian ini berlaku jika Anda menjalankan cluster Standard. Anda dapat mengambil langkah-langkah proaktif dan menetapkan konfigurasi untuk mengurangi risiko serta memfasilitasi upgrade cluster yang lebih lancar saat menjalankan layanan stateful, termasuk:
Ikuti praktik terbaik GKE untuk mengupgrade cluster. Pilih strategi upgrade yang sesuai untuk memastikan upgrade terjadi selama periode masa pemeliharaan:
- Pilih upgrade lonjakan jika pengoptimalan biaya penting dan jika beban kerja Anda dapat menoleransi penonaktifan tuntas dalam waktu kurang dari 60 menit.
- Pilih upgrade blue-green jika beban kerja Anda tidak terlalu toleran terhadap gangguan, dan kenaikan biaya sementara karena penggunaan resource yang lebih tinggi dapat diterima.
Untuk mempelajari lebih lanjut, lihat Mengupgrade cluster yang menjalankan workload stateful.
Gunakan layanan Pemberi rekomendasi untuk memeriksa analisis dan rekomendasi penghentian layanan guna menghindari gangguan layanan.
Gunakan periode pemeliharaan untuk memastikan upgrade terjadi saat Anda menginginkannya. Sebelum masa pemeliharaan, pastikan pencadangan database Anda berhasil.
Sebelum mengizinkan traffic ke node yang diupgrade, gunakan pemeriksaan kesiapan dan keaktifan untuk memastikannya siap menerima traffic.
Buat Pemeriksaan yang menilai apakah replikasi sinkron sebelum menerima traffic. Hal ini dapat dilakukan melalui skrip kustom, bergantung pada kompleksitas dan skala database Anda.
Memverifikasi ketersediaan database selama upgrade cluster Standar
Bagian ini berlaku jika Anda menjalankan cluster Standard. Untuk memverifikasi ketersediaan PostgreSQL selama upgrade, proses umumnya adalah membuat traffic terhadap database PostgreSQL selama proses upgrade. Kemudian, gunakan pgbench
untuk memeriksa apakah database dapat menangani tingkat traffic dasar selama upgrade, dibandingkan dengan saat database sepenuhnya tersedia.
Menghubungkan ke instance PostgreSQL Anda.
./scripts/launch-client.sh
Outputnya mirip dengan hal berikut ini:
Launching Pod pg-client in the namespace postgresql ... pod/pg-client created waiting for the Pod to be ready Copying script files to the target Pod pg-client ... Pod: pg-client is healthy
Di Cloud Shell, lakukan shell ke Pod klien.
kubectl exec -it -n postgresql pg-client -- /bin/bash
Melakukan inisialisasi pgbench.
pgbench -i -h $HOST_PGPOOL -U postgres postgres
Gunakan perintah berikut untuk mendapatkan hasil dasar pengukuran guna mengonfirmasi bahwa aplikasi PostgreSQL Anda tetap sangat tersedia selama jangka waktu untuk upgrade. Untuk mendapatkan hasil dasar pengukuran, uji dengan multi-koneksi melalui multi tugas (thread) selama 30 detik.
pgbench -h $HOST_PGPOOL -U postgres postgres -c10 -j4 -T 30 -R 200
Outputnya terlihat mirip dengan ini:
pgbench (14.5) starting vacuum...end. transaction type: <builtin: TPC-B (sort of)> scaling factor: 1 query mode: simple number of clients: 10 number of threads: 4 duration: 30 s number of transactions actually processed: 5980 latency average = 7.613 ms latency stddev = 2.898 ms rate limit schedule lag: avg 0.256 (max 36.613) ms initial connection time = 397.804 ms tps = 201.955497 (without initial connection time)
Untuk memastikan ketersediaan selama upgrade, Anda dapat membuat beberapa beban terhadap database, dan memastikan bahwa aplikasi PostgreSQL memberikan tingkat respons yang konsisten selama upgrade. Untuk melakukan pengujian ini, buat beberapa traffic terhadap database, menggunakan perintah
pgbench
. Perintah berikut akan menjalankanpgbench
selama satu jam, menargetkan 200 TPS (transaksi per detik), dan mencantumkan rasio permintaan setiap 2 detik.pgbench -h $HOST_PGPOOL -U postgres postgres --client=10 --jobs=4 --rate=200 --time=3600 --progress=2 --select-only
Dengan keterangan:
--client
: Jumlah klien yang disimulasikan, yaitu jumlah sesi database serentak.--jobs
: Jumlah thread pekerja dalam pgbench. Menggunakan lebih dari satu thread dapat berguna di komputer multi-CPU. Klien didistribusikan secara merata di antara rangkaian pesan yang tersedia. Nilai defaultnya adalah 1.--rate
: Tarif diberikan dalam transaksi per detik--progress
: Menampilkan laporan progres setiap detik.
Outputnya mirip dengan hal berikut ini:
pgbench (14.5) starting vacuum...end. progress: 5.0 s, 354.8 tps, lat 25.222 ms stddev 15.038 progress: 10.0 s, 393.8 tps, lat 25.396 ms stddev 16.459 progress: 15.0 s, 412.8 tps, lat 24.216 ms stddev 14.548 progress: 20.0 s, 405.0 tps, lat 24.656 ms stddev 14.066
Di konsol Google Cloud, buka kembali dasbor PostgreSQL Overview di Cloud Monitoring. Perhatikan lonjakan pada grafik Connection per DB dan Connection per Pod.
Keluar dari Pod klien.
exit
Hapus Pod klien.
kubectl delete pod -n postgresql pg-client
Menyimulasikan gangguan layanan PostgreSQL
Di bagian ini, Anda akan menyimulasikan gangguan layanan di salah satu replika PostgreSQL dengan menghentikan layanan pengelola replikasi. Dengan begitu, Pod tidak akan menyalurkan traffic ke replika peer-nya dan pemeriksaan keaktifannya.
Buka sesi Cloud Shell baru dan konfigurasikan akses command line
kubectl
ke cluster utama.gcloud container clusters get-credentials $SOURCE_CLUSTER \ --region=$REGION --project=$PROJECT_ID
Melihat peristiwa PostgreSQL yang dimunculkan di Kubernetes.
kubectl get events -n postgresql --field-selector=involvedObject.name=postgresql-postgresql-ha-postgresql-0 --watch
Pada sesi Cloud Shell sebelumnya, simulasikan kegagalan layanan dengan menghentikan
repmgr
PostgreSQL.Lampirkan sesi Anda ke penampung database.
kubectl exec -it -n $NAMESPACE postgresql-postgresql-ha-postgresql-0 -c postgresql -- /bin/bash
Hentikan layanan menggunakan
repmgr
, lalu hapus checkpoint dan argumendry-run
.export ENTRY='/opt/bitnami/scripts/postgresql-repmgr/entrypoint.sh' export RCONF='/opt/bitnami/repmgr/conf/repmgr.conf' $ENTRY repmgr -f $RCONF node service --action=stop --checkpoint
Pemeriksaan keaktifan yang dikonfigurasi untuk container PostgreSQL akan mulai gagal dalam waktu lima detik. Proses ini berulang setiap sepuluh detik, sampai batas kegagalan enam kegagalan tercapai. Setelah nilai failureThreshold
tercapai, penampung akan dimulai ulang. Anda dapat mengonfigurasi parameter ini untuk mengurangi toleransi pemeriksaan keaktifan guna menyesuaikan persyaratan SLO deployment Anda.
Dari aliran peristiwa, Anda akan melihat pemeriksaan keaktifan dan kesiapan Pod gagal, dan pesan bahwa container harus dimulai ulang. Outputnya mirip dengan hal berikut ini:
0s Normal Killing pod/postgresql-postgresql-ha-postgresql-0 Container postgresql failed liveness probe, will be restarted
0s Warning Unhealthy pod/postgresql-postgresql-ha-postgresql-0 Readiness probe failed: psql: error: connection to server at "127.0.0.1", port 5432 failed: Connection refused...
0s Normal Pulled pod/postgresql-postgresql-ha-postgresql-0 Container image "us-docker.pkg.dev/psch-gke-dev/main/bitnami/postgresql-repmgr:14.5.0-debian-11-r10" already present on machine
0s Normal Created pod/postgresql-postgresql-ha-postgresql-0 Created container postgresql
0s Normal Started pod/postgresql-postgresql-ha-postgresql-0 Started container postgresql
Bersiap untuk pemulihan dari bencana (disaster recovery)
Untuk memastikan workload produksi tetap tersedia jika terjadi peristiwa yang mengganggu layanan, Anda harus menyiapkan rencana pemulihan dari bencana (disaster recovery) (DR). Untuk mempelajari lebih lanjut perencanaan DR, lihat Panduan perencanaan pemulihan dari bencana (disaster recovery).
Pemulihan dari bencana (disaster recovery) untuk Kubernetes dapat diimplementasikan dalam dua fase:
- Pencadangan mencakup pembuatan snapshot point-in-time status atau data Anda sebelum peristiwa yang mengganggu layanan terjadi.
- Pemulihan adalah pemulihan status atau data Anda dari salinan cadangan setelah terjadi bencana.
Untuk mencadangkan dan memulihkan workload di cluster GKE, Anda dapat menggunakan Pencadangan untuk GKE. Anda dapat mengaktifkan layanan ini di cluster baru dan yang sudah ada. Tindakan ini akan men-deploy agen Pencadangan untuk GKE yang berjalan di cluster Anda; agen bertanggung jawab untuk menangkap data cadangan konfigurasi dan volume serta mengatur pemulihan.
Pencadangan dan pemulihan dapat mencakup seluruh cluster, namespace, atau aplikasi (ditentukan oleh pemilih seperti matchLabels
).
Contoh skenario pencadangan dan pemulihan PostgreSQL
Contoh di bagian ini menunjukkan cara melakukan operasi pencadangan dan pemulihan pada cakupan aplikasi, menggunakan Resource Kustom ProtectedApplication
.
Diagram berikut menunjukkan resource komponen dalam ProtectedApplication, yaitu StatefulSet yang mewakili aplikasi postgresql-ha
dan deployment pgpool
, yang menggunakan label yang sama (app.kubernetes.io/name: postgresql-ha
).
Sebagai persiapan untuk mencadangkan dan memulihkan beban kerja PostgreSQL Anda, ikuti langkah-langkah berikut:
Siapkan variabel lingkungan. Dalam contoh ini, Anda akan menggunakan ProtectedApplication untuk memulihkan beban kerja PostgreSQL dan volumenya dari cluster GKE sumber (
us-central1
), lalu memulihkannya ke cluster GKE lain di region yang berbeda (us-west1
).export SOURCE_CLUSTER=cluster-db1 export TARGET_CLUSTER=cluster-db2 export REGION=us-central1 export DR_REGION=us-west1 export NAME_PREFIX=g-db-protected-app export BACKUP_PLAN_NAME=$NAME_PREFIX-bkp-plan-01 export BACKUP_NAME=bkp-$BACKUP_PLAN_NAME export RESTORE_PLAN_NAME=$NAME_PREFIX-rest-plan-01 export RESTORE_NAME=rest-$RESTORE_PLAN_NAME
Pastikan Pencadangan untuk GKE diaktifkan di cluster Anda. Library ini seharusnya sudah diaktifkan sebagai bagian dari penyiapan Terraform yang Anda lakukan sebelumnya.
gcloud container clusters describe $SOURCE_CLUSTER \ --project=$PROJECT_ID \ --region=$REGION \ --format='value(addonsConfig.gkeBackupAgentConfig)'
Jika Pencadangan untuk GKE diaktifkan, output perintah akan menunjukkan
enabled=True
.
Menyiapkan rencana cadangan dan melakukan pemulihan
Dengan pencadangan untuk GKE, Anda dapat membuat rencana pencadangan sebagai cron job. Rencana pencadangan berisi konfigurasi pencadangan yang mencakup cluster sumber, pemilihan beban kerja yang akan dicadangkan, dan region tempat penyimpanan artefak pencadangan yang dihasilkan berdasarkan rencana ini.
Untuk melakukan pencadangan dan pemulihan, ikuti langkah-langkah berikut:
Verifikasi status ProtectedApplication di
cluster-db1
.kubectl get ProtectedApplication -A
Outputnya terlihat mirip dengan ini:
NAMESPACE NAME READY TO BACKUP postgresql postgresql-ha true
Buat rencana cadangan untuk ProtectedApplication.
export NAMESPACE=postgresql export PROTECTED_APP=$(kubectl get ProtectedApplication -n $NAMESPACE | grep -v 'NAME' | awk '{ print $1 }')
gcloud beta container backup-restore backup-plans create $BACKUP_PLAN_NAME \ --project=$PROJECT_ID \ --location=$DR_REGION \ --cluster=projects/$PROJECT_ID/locations/$REGION/clusters/$SOURCE_CLUSTER \ --selected-applications=$NAMESPACE/$PROTECTED_APP \ --include-secrets \ --include-volume-data \ --cron-schedule="0 3 * * *" \ --backup-retain-days=7 \ --backup-delete-lock-days=0
Buat cadangan secara manual.
gcloud beta container backup-restore backups create $BACKUP_NAME \ --project=$PROJECT_ID \ --location=$DR_REGION \ --backup-plan=$BACKUP_PLAN_NAME \ --wait-for-completion
Menyiapkan paket pemulihan.
gcloud beta container backup-restore restore-plans create $RESTORE_PLAN_NAME \ --project=$PROJECT_ID \ --location=$DR_REGION \ --backup-plan=projects/$PROJECT_ID/locations/$DR_REGION/backupPlans/$BACKUP_PLAN_NAME \ --cluster=projects/$PROJECT_ID/locations/$DR_REGION/clusters/$TARGET_CLUSTER \ --cluster-resource-conflict-policy=use-existing-version \ --namespaced-resource-restore-mode=delete-and-restore \ --volume-data-restore-policy=restore-volume-data-from-backup \ --selected-applications=$NAMESPACE/$PROTECTED_APP \ --cluster-resource-scope-selected-group-kinds="storage.k8s.io/StorageClass","scheduling.k8s.io/PriorityClass"
Pulihkan dari cadangan.
gcloud beta container backup-restore restores create $RESTORE_NAME \ --project=$PROJECT_ID \ --location=$DR_REGION \ --restore-plan=$RESTORE_PLAN_NAME \ --backup=projects/$PROJECT_ID/locations/$DR_REGION/backupPlans/$BACKUP_PLAN_NAME/backups/$BACKUP_NAME \ --wait-for-completion
Memverifikasi bahwa cluster telah dipulihkan
Untuk memverifikasi bahwa cluster yang dipulihkan memiliki semua resource Pod, PersistentVolume, dan StorageClass yang diharapkan, ikuti langkah-langkah berikut:
Konfigurasi akses command line
kubectl
ke cluster cadangancluster-db2
.gcloud container clusters get-credentials $TARGET_CLUSTER --region $DR_REGION --project $PROJECT_ID
Verifikasi bahwa StatefulSet siap dengan 3/3 Pod.
kubectl get all -n $NAMESPACE
Outputnya mirip dengan hal berikut ini:
NAME READY STATUS RESTARTS AGE pod/postgresql-postgresql-ha-pgpool-778798b5bd-k2q4b 1/1 Running 0 4m49s pod/postgresql-postgresql-ha-postgresql-0 2/2 Running 2 (4m13s ago) 4m49s pod/postgresql-postgresql-ha-postgresql-1 2/2 Running 0 4m49s pod/postgresql-postgresql-ha-postgresql-2 2/2 Running 0 4m49s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/postgresql-postgresql-ha-pgpool ClusterIP 192.168.241.46 <none> 5432/TCP 4m49s service/postgresql-postgresql-ha-postgresql ClusterIP 192.168.220.20 <none> 5432/TCP 4m49s service/postgresql-postgresql-ha-postgresql-headless ClusterIP None <none> 5432/TCP 4m49s service/postgresql-postgresql-ha-postgresql-metrics ClusterIP 192.168.226.235 <none> 9187/TCP 4m49s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/postgresql-postgresql-ha-pgpool 1/1 1 1 4m49s NAME DESIRED CURRENT READY AGE replicaset.apps/postgresql-postgresql-ha-pgpool-778798b5bd 1 1 1 4m49s NAME READY AGE statefulset.apps/postgresql-postgresql-ha-postgresql 3/3 4m49s
Pastikan semua Pod di namespace
postgres
sudah berjalan.kubectl get pods -n $NAMESPACE
Outputnya mirip dengan hal berikut ini:
postgresql-postgresql-ha-pgpool-569d7b8dfc-2f9zx 1/1 Running 0 7m56s postgresql-postgresql-ha-postgresql-0 2/2 Running 0 7m56s postgresql-postgresql-ha-postgresql-1 2/2 Running 0 7m56s postgresql-postgresql-ha-postgresql-2 2/2 Running 0 7m56s
Memverifikasi PersistentVolumes dan StorageClass. Selama proses pemulihan, Pencadangan untuk GKE membuat Class Proxy dalam beban kerja target untuk menggantikan StorageClass yang disediakan dalam beban kerja sumber (
gce-pd-gkebackup-dn
dalam contoh output).kubectl get pvc -n $NAMESPACE
Outputnya mirip dengan hal berikut ini:
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE data-postgresql-postgresql-ha-postgresql-0 Bound pvc-be91c361e9303f96 8Gi RWO gce-pd-gkebackup-dn 10m data-postgresql-postgresql-ha-postgresql-1 Bound pvc-6523044f8ce927d3 8Gi RWO gce-pd-gkebackup-dn 10m data-postgresql-postgresql-ha-postgresql-2 Bound pvc-c9e71a99ccb99a4c 8Gi RWO gce-pd-gkebackup-dn 10m
Memvalidasi bahwa data yang diharapkan telah dipulihkan
Untuk memvalidasi bahwa data yang diharapkan telah dipulihkan, ikuti langkah-langkah berikut:
Menghubungkan ke instance PostgreSQL Anda.
./scripts/launch-client.sh kubectl exec -it pg-client -n postgresql -- /bin/bash
Verifikasi jumlah baris untuk setiap tabel.
psql -h $HOST_PGPOOL -U postgres -a -q -f /tmp/scripts/count-rows.sql select COUNT(*) from tb01;
Anda akan melihat hasil yang serupa dengan data yang Anda tulis sebelumnya di bagian Membuat set data pengujian. Outputnya mirip dengan hal berikut ini:
300000 (1 row)
Keluar dari Pod klien.
exit
Pembersihan
Agar tidak perlu membayar biaya pada akun Google Cloud Anda untuk resource yang digunakan dalam tutorial ini, hapus project yang berisi resource tersebut, atau simpan project dan hapus setiap resource.
Menghapus project
Cara termudah untuk menghindari penagihan adalah dengan menghapus project yang Anda buat untuk tutorial.
Delete a Google Cloud project:
gcloud projects delete PROJECT_ID
Langkah berikutnya
- Pelajari praktik terbaik untuk men-deploy database di GKE.
- Pelajari Volume Persisten secara lebih mendetail.
- Lihat contoh cara menggunakan Pgpool-II untuk replikasi streaming dengan cluster PostgreSQL ketersediaan tinggi.