Melindungi data Anda menggunakan replikasi per zona

Pilih versi dokumentasi:

Halaman ini menjelaskan arsitektur referensi Ketersediaan yang Ditingkatkan AlloyDB Omni, yang menyediakan 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 bagi bisnis yang memerlukan RTO dan RPO yang lebih rendah.
  • Anda ingin men-deploy replika di zona atau node lain yang menyediakan ketersediaan tinggi untuk database Anda dan melindungi dari kegagalan instance, server, dan zona.
  • Anda menginginkan perlindungan dari kesalahan pengguna dan kerusakan data (menggunakan pencadangan).

Cara kerja arsitektur referensi

Ketersediaan yang ditingkatkan melengkapi Ketersediaan Standar dengan menambahkan instance replika baca dalam region untuk mengaktifkan ketersediaan tinggi (HA) yang mengurangi Tujuan Waktu Pemulihan (RTO). Pendekatan ini juga mengurangi Toleransi Jumlah Data yang Hilang (RPO) dengan mengizinkan perubahan transaksional streaming ke replika.

Ketersediaan tinggi di AlloyDB Omni menggunakan minimal 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 yang penting:

  • Failover adalah prosedur selama pemadaman layanan yang tidak direncanakan saat instance utama gagal, atau tidak tersedia, dan replika standby diaktifkan untuk mengambil alih mode utama (baca-tulis). Proses ini disebut promosi. Biasanya dalam skenario ini, saat server atau database utama kembali online, database harus dibangun ulang dan kemudian harus bertindak sebagai standby. Untuk memberikan waktu aktif yang tinggi, mekanisme telah diterapkan untuk membuat failover otomatis.
  • 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 database standby menjadi database utama. Pengalihan biasanya terjadi secara terkontrol dan lancar, dan dapat dimulai karena berbagai alasan, misalnya, untuk memungkinkan periode nonaktif dan penerapan patch pada database utama sebelumnya. Pengalihan yang lancar harus memungkinkan pengalihan kembali di masa mendatang tanpa perlu membuat ulang instance standby baru atau aspek lain dari konfigurasi replikasi.

Opsi ketersediaan tinggi

Untuk mendukung HA, Anda dapat men-deploy AlloyDB Omni dengan cara berikut:

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

Sebaiknya Anda memiliki minimal dua database standby sehingga hilangnya 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 pengalihan dan failover yang lebih lancar adalah keberadaan load balancer. Untuk deployment non-Kubernetes, software HAProxy menyediakan load balancing. HAProxy menawarkan load balancing dengan mendistribusikan traffic jaringan di beberapa server. HAProxy juga mempertahankan status health server backend yang terhubung dengannya dengan melakukan health check. Jika server gagal dalam health check, HAProxy akan berhenti mengirim traffic ke server tersebut hingga server tersebut lulus health check lagi.

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

Ketersediaan tinggi

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

Sebaiknya lakukan pemeriksaan rutin setiap tahun atau enam bulan sekali dalam bentuk pengalihan 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 memiliki replika baca adalah kemampuan untuk mengurangi beban operasi hanya baca ke database standby, yang dapat bertindak sebagai database pelaporan menggunakan data terbaru. Pendekatan ini mengurangi beban dan overhead pada primer baca-tulis.

Konfigurasi pencadangan dan ketersediaan tinggi

Replika baca dapat disiapkan di beberapa zona yang menyediakan ketersediaan tinggi. Meskipun memberikan RTO dan RPO yang rendah, hal ini tidak melindungi dari gangguan 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 memberikan perlindungan data yang kuat, metode ini dapat memengaruhi performa database utama karena semua commit perlu 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 replika standby failover atau replika baca untuk memungkinkan kegagalan database utama. Replika baca dan standby failover dapat dikonfigurasi, dan operator akan menangani penyediaan dan publikasi layanan. Operator juga mengotomatiskan banyak proses HA seperti membangun ulang database standby setelah failover, dan menggunakan mekanisme perbaikan yang ada di mesin Kubernetes AlloyDB Omni.

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

Selain perlindungan bawaan, operator mengekspos parameter berikut untuk memengaruhi deteksi kegagalan primer atau siaga:

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

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

Deployment HA non-Kubernetes

Deployment non-Kubernetes mandiri adalah konfigurasi manual yang memerlukan alat pihak ketiga yang lebih rumit untuk disiapkan dan dipelihara daripada deployment Kubernetes.

Saat Anda menggunakan deployment non-Kubernetes, ada beberapa parameter yang memengaruhi cara failover terdeteksi dan seberapa cepat failover terjadi setelah server utama menjadi tidak tersedia. Berikut adalah ringkasan singkat parameter tersebut:

  • Ttl: waktu maksimum yang diperlukan untuk mendapatkan kunci bagi database utama sebelum memulai failover. Defaultnya adalah 30 detik.
  • Loop_wait: lamanya waktu untuk menunggu sebelum memeriksa ulang. Defaultnya adalah 10 detik.
  • Retry_timeout: waktu tunggu sebelum menurunkan instance utama karena kegagalan jaringan. Defaultnya adalah 10 detik.

Untuk mengetahui informasi selengkapnya, lihat Arsitektur Ketersediaan Tinggi untuk AlloyDB Omni untuk PostgreSQL.

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 primer 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 instance utama, dan hal ini segera diikuti dengan memulai ulang instance utama.

Alternatif

Langkah berikutnya