Melindungi data Anda menggunakan replikasi per zona

Pilih versi dokumentasi:

Halaman ini menjelaskan arsitektur referensi Ketersediaan yang Ditingkatkan AlloyDB Omni, yang memberikan ketersediaan tinggi dengan men-deploy satu atau beberapa replika database dalam region yang sama yang melindungi dari kegagalan tingkat node atau tingkat zona.

Kasus penggunaan

Arsitektur referensi ketersediaan ini cocok untuk kasus penggunaan berikut:

  • Aplikasi penting bisnis yang memerlukan RTO dan RPO yang lebih rendah.
  • Anda ingin men-deploy replika di zona atau node lain yang memberikan ketersediaan tinggi untuk database Anda dan melindungi dari kegagalan instance, server, dan zona.
  • Anda menginginkan perlindungan dari error pengguna dan kerusakan data (menggunakan cadangan).

Cara kerja arsitektur referensi

Ketersediaan yang Ditingkatkan ditambahkan ke Ketersediaan Standar dengan menambahkan instance replika baca dalam region untuk mengaktifkan ketersediaan tinggi (HA) yang mengurangi Tujuan Waktu Pemulihan (RTO). Pendekatan ini juga mengurangi Tujuan Titik Pemulihan (RPO) dengan mengizinkan perubahan transaksional streaming ke replika.

Ketersediaan tinggi di AlloyDB Omni menggunakan setidaknya dua instance database. Satu instance berfungsi sebagai database utama, yang mendukung operasi baca dan tulis. Instance yang tersisa berfungsi sebagai replika baca, yang beroperasi dalam mode hanya baca.

Berikut adalah konsep HA penting:

  • Failover adalah prosedur selama pemadaman layanan yang tidak direncanakan saat instance utama gagal, atau tidak tersedia, dan replika standby diaktifkan untuk menggunakan mode utama (baca-tulis). Proses ini disebut promosi. Biasanya dalam skenario ini, saat server atau database utama kembali online, database harus dibangun kembali dan kemudian harus bertindak sebagai standby. Untuk memberikan waktu aktif yang tinggi, mekanisme diterapkan untuk membuat failover otomatis.
  • A Switchover, juga dikenal sebagai pembalikan peran, adalah prosedur yang digunakan untuk mengalihkan mode antara database utama dan salah satu database standby, sehingga database utama menjadi standby dan standby menjadi utama. Switchover biasanya terjadi dengan cara yang terkontrol dan lancar, dan dapat dimulai karena berbagai alasan, misalnya, untuk mengizinkan waktu nonaktif dan penerapan patch pada database utama sebelumnya. Switchover yang lancar harus memungkinkan switch-back di masa mendatang tanpa perlu membuat ulang instance standby baru atau aspek lain dari konfigurasi replikasi.

Opsi ketersediaan tinggi

Di lingkungan Kubernetes, untuk mendukung HA, Anda dapat men-deploy AlloyDB Omni menggunakan operator Kubernetes AlloyDB Omni. Untuk mengetahui informasi selengkapnya, lihat Mengelola ketersediaan tinggi di Kubernetes.

Catatan: Patroni dan HAProxy adalah alat pihak ketiga non-komersial, dan kompatibel dengan AlloyDB Omni.

Sebaiknya Anda memiliki setidaknya dua database standby sehingga kehilangan satu database tidak memengaruhi ketersediaan tinggi cluster. Dalam mode tersebut, Anda memiliki setidaknya satu pasangan HA jika terjadi failover atau selama pemeliharaan node yang direncanakan.

Untuk merencanakan ukuran dan bentuk deployment AlloyDB Omni, lihat Merencanakan penginstalan AlloyDB Omni di VM.

Load balancer

Mekanisme penting lainnya yang membantu prosedur switchover dan failover yang lebih lancar adalah keberadaan load balancer.

Operator Kubernetes men-deploy load balancer-nya sendiri yang berperilaku dengan cara yang sama, membuat layanan untuk database yang mengarah ke load balancer agar hal ini transparan bagi pengguna.

Ketersediaan tinggi

Database replika baca yang di-deploy dalam region memberikan ketersediaan tinggi jika database utama gagal. Jika terjadi kegagalan database utama, database standby akan dipromosikan untuk menggantikan database utama dan aplikasi akan terus berjalan dengan sedikit atau tanpa pemadaman layanan.

Sebaiknya lakukan pemeriksaan rutin tahunan atau setengah tahunan dalam bentuk switchover untuk memastikan bahwa semua aplikasi yang mengandalkan database ini masih dapat terhubung dan merespons dalam jangka waktu yang sesuai.

Perlindungan tingkat zona dapat dicapai menggunakan salah satu jenis deployment dengan menempatkan salah satu replika baca standby di zona ketersediaan yang berbeda dari database utama.

Manfaat tambahan dari replika baca adalah kemampuan untuk mengalihkan operasi hanya baca ke database standby, yang dapat bertindak sebagai database pelaporan menggunakan data terbaru. Pendekatan ini mengurangi beban dan overhead pada database utama baca-tulis.

Konfigurasi pencadangan dan ketersediaan tinggi

Replika baca dapat disiapkan di beberapa zona yang memberikan ketersediaan tinggi. Meskipun memberikan RTO dan RPO yang rendah, hal ini tidak melindungi dari pemadaman layanan tertentu seperti kerusakan data logis seperti penghapusan tabel yang tidak disengaja atau pembaruan data yang salah. Oleh karena itu, pencadangan rutin harus dilakukan selain penyiapan HA. Lihat dokumentasi Arsitektur Ketersediaan Standar untuk mengetahui detailnya.

Gambar 1 menunjukkan konfigurasi HA yang direkomendasikan dengan dua database standby replika baca di dua zona ketersediaan yang berbeda.

AlloyDB Omni dengan opsi pencadangan dan ketersediaan tinggi

Gambar 1. AlloyDB Omni dengan opsi pencadangan dan ketersediaan tinggi.

Untuk melindungi dari kehilangan data jika instance utama gagal, konfigurasi replikasi dalam mode sinkron diperlukan. Meskipun metode ini memberikan perlindungan data yang kuat, metode ini dapat memengaruhi performa database utama karena semua commit harus ditulis ke database utama dan semua database standby yang disinkronkan. Koneksi jaringan latensi rendah antara instance database ini sangat penting untuk penyiapan ini.

Deployment HA Kubernetes

Untuk deployment Kubernetes, dengan menggunakan beberapa perubahan dan penambahan atribut dasar pada file deployment AlloyDB Omni, Anda dapat menambahkan standby failover atau replika baca untuk memungkinkan kegagalan database utama. Replika standby failover dan hanya baca dapat dikonfigurasi, dan operator akan menangani penyediaan dan publikasi layanan. Operator juga mengotomatiskan banyak proses HA seperti membangun kembali database standby setelah failover, dan menggunakan mekanisme pemulihan yang ada di mesin Kubernetes AlloyDB Omni.

Dalam deployment Kubernetes, ketersediaan infrastruktur dan aplikasi mendapatkan manfaat dari fitur Kubernetes bawaan yang menangani kegagalan node dan pod, termasuk hal berikut:

Selain perlindungan bawaan, operator mengekspos parameter berikut untuk memengaruhi deteksi utama atau standby yang gagal:

  • healthcheckPeriodSeconds: waktu antara health check. Defaultnya adalah 30 detik.
  • autoFailoverTriggerThreshold: jumlah health check yang gagal berturut-turut sebelum memulai failover. Nilai defaultnya adalah 3.

Untuk mengetahui informasi selengkapnya, lihat Mengelola ketersediaan tinggi di Kubernetes.

Penerapan

Saat memilih arsitektur referensi ketersediaan, perhatikan manfaat, batasan, dan alternatif berikut.

Manfaat

  • Melindungi dari kegagalan instance.
  • Melindungi dari kegagalan server.
  • Melindungi dari kegagalan zona.
  • RTO berkurang secara signifikan dari Ketersediaan Standar.

Batasan

  • Tidak ada perlindungan tambahan untuk bencana regional.
  • Potensi dampak performa pada database utama karena replikasi sinkron.
  • Mengonfigurasi streaming WAL PostgreSQL dalam mode sinkron menawarkan nol kehilangan data (RPO=0) selama operasi normal atau failover umum. Namun, pendekatan ini tidak melindungi dari kehilangan data dalam situasi kesalahan ganda tertentu, seperti saat semua instance standby hilang atau tidak dapat dijangkau dari database utama, dan hal ini segera diikuti dengan memulai ulang database utama.

Alternatif

Langkah berikutnya