Mengelola ketersediaan tinggi di Kubernetes

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:

  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 dengan 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-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:

  1. Operator AlloyDB Omni akan membuat instance database utama offline.

  2. Operator AlloyDB Omni mempromosikan replika standby menjadi instance database utama 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, 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 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 adalah 30. Nilai minimum adalah 1 dan nilai maksimum adalah 86400 (setara dengan satu hari).

  • AUTOFAILOVER_TRIGGER_THRESHOLD: nilai bilangan bulat untuk jumlah kegagalan berturut-turut untuk pemeriksaan kesehatan sebelum pengalihan gagal dipicu. Nilai defaultnya 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 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:

  1. Operator AlloyDB Omni akan membuat instance database utama offline.

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

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

Melakukan pengalihan

Sebelum memulai pengalihan, lakukan hal berikut:

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:

  1. Dalam manifes cluster, tetapkan enableAutoHeal ke false:

    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 adalah 3. Nilai minimumnya adalah 2 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:

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:

  1. Tetapkan enableStandbyAsReadReplica ke true dalam manifes cluster database:

    spec:
      availability:
        enableStandbyAsReadReplica: true
    
  2. Terapkan kembali manifes.

  3. Pastikan 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