Dokumen ini menunjukkan cara mengaktifkan dan menguji ketersediaan tinggi (HA) di cluster database AlloyDB Omni berbasis Kubernetes. Dokumen ini mengasumsikan pengetahuan dasar tentang cara menerapkan file manifes Kubernetes dan menggunakan alat command line kubectl
.
Ringkasan
Anda mengaktifkan HA di cluster database dengan mengonfigurasi operator Kubernetes AlloyDB Omni untuk membuat replika standby instance database utama Anda. Operator AlloyDB Omni mengonfigurasi cluster database Anda untuk terus memperbarui data pada replika ini, dan mencocokkan semua perubahan data pada instance utama Anda.
Mengaktifkan HA
Sebelum mengaktifkan HA di cluster database, pastikan cluster Kubernetes Anda memiliki hal berikut:
Penyimpanan untuk dua salinan lengkap data Anda
Resource komputasi untuk dua instance database yang berjalan secara paralel
Untuk mengaktifkan HA, ikuti langkah-langkah berikut:
Ubah manifes cluster database untuk menyertakan bagian
availability
di bagianspec
. Bagian ini menggunakan parameternumberOfStandbys
untuk menentukan jumlah standby yang akan ditambahkan.spec: availability: numberOfStandbys: NUMBER_OF_STANDBYS
Ganti
NUMBER_OF_STANDBYS
dengan jumlah standby yang ingin Anda tambahkan. Nilai maksimumnya adalah5
. Jika Anda tidak yakin dengan jumlah standby yang diperlukan, mulailah dengan menetapkan nilai ke1
atau2
.Terapkan kembali manifes.
Menonaktifkan HA
Untuk menonaktifkan HA, ikuti langkah-langkah berikut:
Tetapkan
numberOfStandbys
ke0
di manifes cluster:spec: availability: numberOfStandbys: 0
Terapkan kembali manifes.
Memverifikasi HA di cluster database
Untuk memeriksa status HA di cluster database, periksa status HAReady
-nya. Jika status HAReady
adalah True
, berarti HA diaktifkan dan berfungsi di cluster. Jika False
, berarti diaktifkan, tetapi belum siap karena sedang dalam
proses penyiapan.
Untuk memeriksa status HAReady
menggunakan command line kubectl
, jalankan perintah berikut:
kubectl get dbcluster.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -o jsonpath={.status.conditions[?(@.type == \'HAReady\')]} -n NAMESPACE
Ganti kode berikut:
DB_CLUSTER_NAME
: nama cluster database.NAMESPACE
: namespace cluster database.
Melakukan failover ke instance standby
Jika instance utama Anda tidak tersedia selama jangka waktu yang dapat dikonfigurasi, operator AlloyDB Omni akan otomatis melakukan failover dari instance database utama ke instance standby. Parameter berikut menentukan kapan harus memulai failover otomatis:
Waktu antara health check (default-nya adalah 30 detik)
Jumlah health check berturut-turut yang gagal (defaultnya adalah 3)
Failover otomatis dimulai setelah sejumlah health check berturut-turut gagal, dengan waktu yang ditentukan di antara setiap health check yang gagal. Jika nilai default dipertahankan, failover otomatis akan terjadi setelah 3 kegagalan health check berturut-turut yang masing-masing berjarak 30 detik.
Melakukan failover manual adalah opsi yang baik jika Anda ingin pulih dengan cepat dari kegagalan yang tidak terduga dan meminimalkan periode nonaktif.
Operator AlloyDB Omni mendukung failover otomatis dan manual. Failover otomatis diaktifkan secara default.
Failover menghasilkan urutan peristiwa berikut:
Operator AlloyDB Omni akan membuat instance database utama offline.
Operator AlloyDB Omni mempromosikan replika standby menjadi instance database utama baru.
Operator AlloyDB Omni menghapus instance database utama sebelumnya.
Operator AlloyDB Omni membuat replika standby baru.
Menonaktifkan failover otomatis
Failover otomatis diaktifkan secara default di cluster database.
Untuk menonaktifkan failover, ikuti langkah-langkah berikut:
Tetapkan
enableAutoFailover
kefalse
di manifes cluster:spec: availability: enableAutoFailover: false
Menyesuaikan setelan pemicu failover otomatis
Anda dapat menggunakan setelan untuk menyesuaikan failover otomatis untuk setiap cluster database.
Operator AlloyDB Omni mengeluarkan pemeriksaan kondisi reguler ke instance database utama
serta ke semua replika standby. Frekuensi default untuk
health check adalah 30
detik. Jika instance mencapai nilai minimum pemicu
failover otomatis, operator AlloyDB Omni akan memicu
failover otomatis.
Nilai minimum adalah jumlah kegagalan berturut-turut untuk health check sebelum failover dipicu. Untuk mengubah periode pemeriksaan kesehatan atau
nilai nilai minimum, tetapkan kolom healthcheckPeriodSeconds
dan
autoFailoverTriggerThreshold
ke nilai bilangan bulat dalam manifes
cluster:
spec:
availability:
healthcheckPeriodSeconds: HEALTHCHECK_PERIOD
autoFailoverTriggerThreshold: AUTOFAILOVER_TRIGGER_THRESHOLD
Ganti kode berikut:
HEALTHCHECK_PERIOD
: nilai bilangan bulat yang menunjukkan jumlah detik yang harus ditunggu di antara setiap pemeriksaan kesehatan. Nilai defaultnya adalah30
. Nilai minimum adalah1
dan nilai maksimum adalah86400
(setara dengan satu hari).AUTOFAILOVER_TRIGGER_THRESHOLD
: nilai bilangan bulat untuk jumlah kegagalan berturut-turut untuk pemeriksaan kesehatan sebelum pengalihan gagal dipicu. Nilai defaultnya adalah3
. Nilai minimumnya adalah0
. Tidak ada nilai maksimum. Jika kolom ini ditetapkan ke0
, nilai default3
akan digunakan.
Memicu failover manual
Untuk memicu failover manual, buat dan terapkan manifes untuk resource failover baru:
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Failover
metadata:
name: FAILOVER_NAME
namespace: NAMESPACE
spec:
dbclusterRef: DB_CLUSTER_NAME
Ganti kode berikut:
FAILOVER_NAME
: nama untuk resource ini—misalnya,failover-1
.NAMESPACE
: namespace untuk resource failover ini, yang harus cocok dengan namespace cluster database yang berlaku.DB_CLUSTER_NAME
: nama cluster database yang akan gagal.
Untuk memantau failover, jalankan perintah berikut:
kubectl get failover FAILOVER_NAME -o jsonpath={.status.state} -n NAMESPACE
Ganti kode berikut:
FAILOVER_NAME
: nama yang Anda tetapkan untuk resource failover saat membuatnya.NAMESPACE
: namespace cluster database.
Perintah ini menampilkan Success
setelah instance database utama baru siap
digunakan. Untuk memantau status instance standby baru, lihat bagian berikutnya.
Beralih ke instance standby
Peralihan dilakukan saat Anda ingin menguji penyiapan disaster recovery atau aktivitas terencana lainnya yang memerlukan pengalihan peran database utama dan replika standby.
Setelah switchover selesai, arah replikasi dan peran instance database utama dan replika standby akan dibalik. Gunakan switchover untuk mendapatkan kontrol yang lebih besar atas pengujian penyiapan disaster recovery tanpa kehilangan data.
Operator AlloyDB Omni mendukung pengalihan manual. Peralihan akan menghasilkan urutan peristiwa berikut:
Operator AlloyDB Omni akan membuat instance database utama offline.
Operator AlloyDB Omni mempromosikan replika standby menjadi instance database utama baru.
Operator AlloyDB Omni mengalihkan instance database utama sebelumnya menjadi replika standby.
Melakukan pengalihan
Sebelum memulai pengalihan, lakukan hal berikut:
Pastikan instance database utama dan replika standby berada dalam status yang baik. Untuk informasi selengkapnya, lihat Mengelola dan memantau AlloyDB Omni.
Verifikasi bahwa status HA saat ini dalam kondisi
HAReady
. Untuk mengetahui informasi selengkapnya, lihat Memverifikasi HA di cluster database.
Untuk melakukan pengalihan, buat dan terapkan manifes untuk resource pengalihan baru:
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Switchover
metadata:
name: SWITCHOVER_NAME
spec:
dbclusterRef: DB_CLUSTER_NAME
newPrimary: STANBDY_REPLICA_NAME
Ganti kode berikut:
SWITCHOVER_NAME
: nama untuk resource pengalihan ini — misalnya,switchover-1
.DB_CLUSTER_NAME
: nama instance database utama yang menjadi sasaran operasi pengalihan.STANBDY_REPLICA_NAME
: nama instance database yang ingin Anda promosikan menjadi instance utama baru.Untuk mengidentifikasi nama replika standby, jalankan perintah berikut:
kubectl get instances.alloydbomni.internal.dbadmin.goog
Memperbaiki instance standby secara otomatis
Jika instance standby tidak tersedia, operator AlloyDB Omni akan memperbaiki instance dengan menghapus replika standby lama dan membuat replika standby baru yang menggantikannya. Waktu default untuk memicu perbaikan otomatis adalah 90 detik.
Memperbaiki cluster database secara otomatis membantu mempertahankan replika database utama yang berkelanjutan dan sehat.
Menonaktifkan perbaikan instance secara otomatis
Secara default, perbaikan instance standby otomatis diaktifkan di cluster database.
Untuk menonaktifkan penyembuhan otomatis, ikuti langkah-langkah berikut:
Dalam manifes cluster, tetapkan
enableAutoHeal
kefalse
:spec: availability: enableAutoHeal: false
Menyesuaikan setelan pemicu perbaikan otomatis
Untuk setiap cluster database, Anda dapat menggunakan setelan untuk menyesuaikan perbaikan otomatis.
Operator AlloyDB Omni mengeluarkan pemeriksaan kesehatan rutin yang dapat Anda konfigurasi. Untuk informasi selengkapnya, lihat Menyesuaikan setelan pemicu failover otomatis. Jika replika standby mencapai nilai minimum pemicu perbaikan otomatis, operator AlloyDB Omni akan memicu perbaikan otomatis.
Nilai minimum adalah jumlah kegagalan berturut-turut untuk health check
sebelum perbaikan dipicu. Untuk mengubah nilai minimum, tetapkan
autoHealTriggerThreshold
dalam manifes cluster:
spec:
availability:
autoHealTriggerThreshold: AUTOHEAL_TRIGGER_THRESHOLD
Ganti kode berikut:
AUTOHEAL_TRIGGER_THRESHOLD
: nilai bilangan bulat untuk jumlah kegagalan berturut-turut untuk pemeriksaan kesehatan sebelum perbaikan dipicu. Nilai defaultnya adalah3
. Nilai minimumnya adalah2
karena kemungkinan error sementara satu kali pada pemeriksaan kesehatan standby.
Memecahkan masalah perbaikan instance
Jika Anda menggunakan banyak cluster database dalam satu cluster Kubernetes, mungkin (meskipun tidak mungkin) akan membebani perbaikan otomatis. Jika Anda menerima error yang dimulai dengan HealthCheckProber: health check for
instance failed
dan mereferensikan waktu tunggu habis atau kegagalan untuk terhubung, Anda dapat mencoba mengurangi error dengan melakukan tindakan berikut:
Kurangi jumlah cluster database yang Anda kelola di cluster Kubernetes.
Tingkatkan nilai minimum
healthcheckPeriodSeconds
sehingga health check terjadi lebih jarang. Untuk informasi selengkapnya, lihat Menyesuaikan setelan pemicu failover otomatis.Tingkatkan batas CPU, batas memori, atau keduanya, untuk operator AlloyDB Omni. Untuk informasi selengkapnya, lihat Tentang pengelolaan memori otomatis dan Menganalisis penggunaan heap memori operator AlloyDB Omni.
Berikut adalah contoh error yang mungkin disebabkan oleh perbaikan otomatis yang terlalu banyak. Contoh ini menghilangkan detail lingkungan yang membantu Anda mengidentifikasi sumber error, seperti nama cluster atau alamat IP.
HealthCheckProber: health check for instance failed" err="DBSE0005: DBDaemon Client Error. secure dbdaemon connection failed: context deadline exceeded...
HealthCheckProber: health check for instance failed" err="rpc error: code = Code(10303) desc = DBSE0303: Healthcheck: Health check table query failed. dbdaemon/healthCheck: read healthcheck table: timeout...
HealthCheckProber: health check for instance failed" err="rpc error: code = Code(12415) desc = DBSE2415: Postgres: failed to connect to database. dbdaemon/healthCheck: failed to connect...
Menggunakan replika standby sebagai instance hanya baca
Untuk menggunakan replika standby sebagai instance hanya baca, selesaikan langkah-langkah berikut:
Tetapkan
enableStandbyAsReadReplica
ketrue
dalam manifes cluster database:spec: availability: enableStandbyAsReadReplica: true
Terapkan kembali manifes.
Pastikan endpoint hanya baca dilaporkan di kolom
status
objekDBCluster
:kubectl describe dbcluster -n NAMESPACE DB_CLUSTER_NAME
Contoh respons berikut menunjukkan endpoint instance hanya baca:
Status: [...] Primary: [...] Endpoints: Name: Read-Write Value: 10.128.0.81:5432 Name: Read-Only Value: 10.128.0.82:5432