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 AlloyDB Omni Kubernetes untuk membuat replika standby dari 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.

Aktifkan 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-nya. Bagian ini menggunakan parameter numberOfStandbys untuk menentukan jumlah siaga 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 perangkat siaga yang dibutuhkan, mulailah dengan menyetel nilai ke 1 atau 2.

  2. Terapkan kembali manifes.

Nonaktifkan HA

Untuk menonaktifkan HA, ikuti langkah-langkah berikut:

  1. Setel numberOfStandbys ke 0 di manifes cluster:

    spec:
  availability:
    numberOfStandbys: 0

  2. Terapkan kembali manifes.

Memverifikasi HA di cluster database

Untuk memeriksa status HA pada 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 (defaultnya adalah 30 detik)

  • Jumlah health check gagal berturut-turut (defaultnya adalah 3)

Pengalihan otomatis dimulai setelah sejumlah pemeriksaan kesehatan berturut-turut yang gagal terjadi, dengan waktu yang ditentukan di antara setiap pemeriksaan kesehatan 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 mengalihkan instance database utama ke offline.

  2. Operator AlloyDB Omni mempromosikan replika standby 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. Setel enableAutoFailover ke false di manifes cluster:

    spec:
  availability:
    enableAutoFailover: false

Menyesuaikan setelan pemicu pengalihan otomatis

Anda dapat menggunakan setelan untuk menyesuaikan failover otomatis untuk setiap cluster database.

Operator AlloyDB Omni melakukan health check reguler ke instance database utama serta ke semua replika standby. Frekuensi default untuk pemeriksaan kondisi 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 kondisi atau nilai batas, 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 health check. 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 health check sebelum failover dipicu. Nilai defaultnya adalah 3. Nilai minimumnya adalah 0. Tidak ada nilai maksimum. Jika kolom ini disetel 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 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 baru siap digunakan. Untuk memantau status instance standby baru, lihat bagian berikutnya.

Pengalihan ke instance standby

Pengalihan dilakukan saat Anda ingin menguji penyiapan pemulihan dari bencana atau aktivitas terencana lainnya yang memerlukan pengalihan peran database primer dan replika standby.

Setelah switchover selesai, arah replikasi dan peran instance database utama dan replika standby dibalik. Gunakan pengalihan untuk mendapatkan kontrol yang lebih besar atas pengujian penyiapan pemulihan bencana Anda tanpa kehilangan data.

Operator AlloyDB Omni mendukung pengalihan manual. Pengalihan menghasilkan urutan peristiwa berikut:

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

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

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

Melakukan pengalihan

Sebelum Anda 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: STANDBY_REPLICA_NAME

Ganti kode berikut:

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

  • DB_CLUSTER_NAME: nama instance database utama yang menjadi tujuan operasi pengalihan.

  • STANDBY_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

Memulihkan 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 replikasi yang sehat dan berkelanjutan dari database utama.

Menonaktifkan perbaikan instance secara otomatis

Secara default, perbaikan otomatis instance standby diaktifkan pada cluster database.

Untuk menonaktifkan perbaikan otomatis, ikuti langkah-langkah berikut:

  1. Di manifes cluster, setel enableAutoHeal ke false:

    spec:
  availability:
    enableAutoHeal: false

Menyesuaikan setelan pemicu pemulihan otomatis

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

Operator AlloyDB Omni melakukan health check rutin yang dapat Anda konfigurasi. Untuk mengetahui 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 health check sebelum perbaikan dipicu. Nilai defaultnya adalah 5. Nilai minimumnya adalah 2 karena kemungkinan terjadi error sementara satu kali pada health check siaga.

Memecahkan masalah perbaikan instance

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

Berikut adalah contoh error yang mungkin disebabkan oleh perbaikan otomatis yang berlebihan. Contoh ini tidak menyertakan 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 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