Mengelola ketersediaan tinggi di Kubernetes

Pilih versi dokumentasi:

Halaman ini menjelaskan cara mengaktifkan dan menguji ketersediaan tinggi (HA) di cluster database AlloyDB Omni berbasis Kubernetes. Dokumen ini mengasumsikan pengetahuan dasar tentang penerapan file manifes Kubernetes dan penggunaan alat command line kubectl.

Ringkasan

Anda mengaktifkan HA di cluster database dengan mengonfigurasi operator Kubernetes AlloyDB Omni untuk membuat replika standby dari instance database utama. Operator AlloyDB Omni mengonfigurasi cluster database Anda untuk terus memperbarui data pada replika ini, dan cocok dengan 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:

  1. Ubah manifes cluster database untuk menyertakan bagian availability di bagian spec. Bagian ini menggunakan parameter numberOfStandbys 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 adalah 5. Jika Anda tidak yakin tentang jumlah standby yang diperlukan, mulailah dengan menetapkan nilai ke 1 atau 2.

  2. Terapkan kembali manifes.

Menonaktifkan HA

Untuk menonaktifkan HA, ikuti langkah-langkah berikut:

  1. Tetapkan numberOfStandbys ke 0 di manifes cluster:

    spec:
  availability:
    numberOfStandbys: 0

  2. Terapkan kembali manifes.

Memverifikasi HA di cluster database

Untuk memeriksa status HA di cluster database, periksa status HAReady. Jika status HAReady adalah True, HA akan diaktifkan dan berfungsi di cluster. Jika False, HA akan diaktifkan tetapi belum siap karena masih 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 failover otomatis akan dimulai:

  • Waktu antara health check (default-nya adalah 30 detik)

  • Jumlah health check yang gagal berturut-turut (default-nya adalah 3)

Failover otomatis dimulai setelah jumlah health check yang gagal berturut-turut terjadi, 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 waktu nonaktif.

Operator AlloyDB Omni mendukung failover otomatis dan manual. Failover otomatis diaktifkan secara default.

Failover menghasilkan urutan peristiwa berikut:

  1. Operator AlloyDB Omni mengalihkan instance database utama ke offline.

  2. Operator AlloyDB Omni mempromosikan replika standby untuk menjadi instance database utama yang baru.

  3. Operator AlloyDB Omni menghapus instance database utama sebelumnya.

  4. Operator AlloyDB Omni membuat replika standby baru.

Menonaktifkan failover otomatis

Failover otomatis diaktifkan secara default di cluster database.

Untuk menonaktifkan failover otomatis, ikuti langkah-langkah berikut:

  1. Tetapkan enableAutoFailover ke false 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 health check 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 health check atau nilai minimum, tetapkan kolom healthcheckPeriodSeconds dan autoFailoverTriggerThreshold ke nilai bilangan bulat di manifes cluster:

spec:
  availability:
    healthcheckPeriodSeconds: HEALTHCHECK_PERIOD
    autoFailoverTriggerThreshold: AUTOFAILOVER_TRIGGER_THRESHOLD

Ganti kode berikut:

  • HEALTHCHECK_PERIOD: nilai bilangan bulat yang menunjukkan jumlah detik yang akan ditunggu di antara setiap health check. Nilai default-nya adalah 30. Nilai minimumnya adalah 1 dan nilai maksimumnya adalah 86400 (setara dengan satu hari).

  • AUTOFAILOVER_TRIGGER_THRESHOLD: nilai bilangan bulat untuk jumlah kegagalan berturut-turut untuk health check sebelum failover dipicu. Nilai default-nya adalah 3. Nilai minimumnya adalah 0. Tidak ada nilai maksimum. Jika kolom ini ditetapkan ke 0, nilai default 3 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 diterapkan.

  • DB_CLUSTER_NAME: nama cluster database yang akan di-failover.

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 ke resource failover saat Anda membuatnya.

  • NAMESPACE: namespace cluster database.

Perintah ini menampilkan Success setelah instance database utama yang baru siap digunakan. Untuk memantau status instance standby baru, lihat bagian berikutnya.

Melakukan switchover ke instance standby

Switchover 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 serta replika standby akan dibalik. Gunakan switchover untuk mendapatkan kontrol yang lebih besar atas pengujian penyiapan pemulihan dari bencana tanpa kehilangan data.

Operator AlloyDB Omni mendukung switchover manual. Switchover menghasilkan urutan peristiwa berikut:

  1. Operator AlloyDB Omni mengalihkan instance database utama ke offline.

  2. Operator AlloyDB Omni mempromosikan replika standby untuk menjadi instance database utama yang baru.

  3. Operator AlloyDB Omni mengalihkan instance database utama sebelumnya untuk menjadi replika standby.

Melakukan switchover

Sebelum memulai switchover, lakukan hal berikut:

Untuk melakukan switchover, buat dan terapkan manifes untuk resource switchover baru:

apiVersion: alloydbomni.dbadmin.goog/v1
kind: Switchover
metadata:
    name: SWITCHOVER_NAME
spec:
     dbclusterRef: DB_CLUSTER_NAME
     newPrimary: STANDBY_REPLICA_NAME

Ganti kode berikut:

  • SWITCHOVER_NAME: nama untuk resource switchover ini—misalnya, switchover-1.

  • DB_CLUSTER_NAME: nama instance database utama yang diterapkan oleh operasi switchover.

  • STANDBY_REPLICA_NAME: nama instance database yang ingin Anda promosikan untuk menjadi instance utama yang baru.

    Untuk mengidentifikasi nama replika standby, jalankan perintah berikut:

    kubectl get instances.alloydbomni.internal.dbadmin.goog

Memulihkan instance standby secara otomatis

Jika instance standby tidak tersedia, operator AlloyDB Omni akan memulihkan instance dengan menghapus replika standby lama dan membuat replika standby baru yang menggantikannya. Waktu default untuk memicu pemulihan otomatis adalah 90 detik.

Memulihkan cluster database secara otomatis membantu mempertahankan replikasi database utama yang sehat dan berkelanjutan.

Menonaktifkan pemulihan instance secara otomatis

Secara default, pemulihan instance standby secara otomatis diaktifkan di cluster database.

Untuk menonaktifkan pemulihan otomatis, ikuti langkah-langkah berikut:

  1. Di manifes cluster, tetapkan enableAutoHeal ke false:

    spec:
  availability:
    enableAutoHeal: false

Menyesuaikan setelan pemicu pemulihan otomatis

Untuk setiap cluster database, Anda dapat menggunakan setelan untuk menyesuaikan pemulihan otomatis.

Operator AlloyDB Omni mengeluarkan health check reguler yang dapat Anda konfigurasi. Untuk mengetahui informasi selengkapnya, lihat Menyesuaikan setelan pemicu failover otomatis. Jika replika standby mencapai nilai minimum pemicu pemulihan otomatis, operator AlloyDB Omni akan memicu pemulihan otomatis.

Nilai minimum adalah jumlah kegagalan berturut-turut untuk health check sebelum pemulihan dipicu. Untuk mengubah nilai minimum, tetapkan autoHealTriggerThreshold di manifes cluster:

spec:
  availability:
    autoHealTriggerThreshold: AUTOHEAL_TRIGGER_THRESHOLD

Ganti kode berikut:

  • AUTOHEAL_TRIGGER_THRESHOLD: nilai bilangan bulat untuk jumlah kegagalan berturut-turut untuk health check sebelum pemulihan dipicu. Nilai default-nya adalah 5. Nilai minimumnya adalah 2 karena kemungkinan error sementara dan satu kali pada health check standby.

Memecahkan masalah pemulihan instance

Jika Anda menggunakan sejumlah besar cluster database dalam satu cluster Kubernetes, atau jika Anda memiliki cluster database yang kurang disediakan, pemulihan otomatis dapat menyebabkan ketidaktersediaan untuk operator AlloyDB Omni atau cluster database. Jika Anda menerima error yang dimulai dengan HealthCheckProber: health check for instance failed dan error tersebut merujuk ke waktu tunggu atau kegagalan untuk terhubung, coba perbaikan yang direkomendasikan berikut:

Berikut adalah contoh error yang mungkin disebabkan oleh pemulihan otomatis yang berlebihan. 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:

  1. Tetapkan enableStandbyAsReadReplica ke true di manifes cluster database:

    spec:
  availability:
    enableStandbyAsReadReplica: true

  2. Terapkan kembali manifes.

  3. Verifikasi bahwa endpoint hanya baca dilaporkan di kolom status objek DBCluster:

    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