Ringkasan arsitektur referensi ketersediaan AlloyDB Omni

Halaman ini memperkenalkan arsitektur ketersediaan AlloyDB Omni yang dapat Anda gunakan untuk memastikan bahwa database AlloyDB Omni Anda dapat dipulihkan secara tepat waktu dengan sedikit atau tanpa kehilangan data.

Untuk memastikan kelangsungan bisnis dan meminimalkan kehilangan data, ketersediaan tinggi (HA) dan pemulihan dari bencana (DR) adalah strategi perlindungan data yang penting untuk AlloyDB Omni. HA berfokus pada mempertahankan ketersediaan database dan meminimalkan Batas Waktu Pemulihan (RTO), sementara DR menangani pemulihan dari peristiwa yang merusak dan meminimalkan Toleransi Jumlah Data yang Hilang (RPO).

RTO dan RPO disesuaikan dengan persyaratan bisnis dan ditentukan sebagai berikut:

  • RTO adalah waktu maksimum saat database dapat mengalami gangguan atau tidak tersedia sebelum bisnis mengalami konsekuensi yang tidak dapat diterima, seperti hilangnya pendapatan atau produktivitas.
  • RPO adalah jumlah maksimum kehilangan data yang dapat dialami bisnis sebelum memengaruhi persyaratan bisnis. Misalnya, sistem inventaris yang memerlukan jejak audit lengkap mungkin memiliki persyaratan tanpa kehilangan data.

AlloyDB Omni menawarkan arsitektur referensi ketersediaan berikut yang memberikan tingkat ketersediaan yang meningkat:

  1. Ketersediaan standar: melindungi data Anda menggunakan cadangan.
  2. Ketersediaan yang ditingkatkan: melindungi data Anda menggunakan replikasi zonal di suatu region (HA).
  3. Ketersediaan premium: melindungi data Anda menggunakan replikasi regional dan zonal (HA dan DR).

Mekanisme ketersediaan

Berikut adalah mekanisme utama yang memastikan ketersediaan:

  • Pencadangan database
  • Replikasi database

Pencadangan database

Pencadangan database, aspek mendasar dari perlindungan data, melibatkan pembuatan salinan fisik file data database. Berbagai jenis pencadangan—penuh, inkremental, dan diferensial—menawarkan keseimbangan yang bervariasi antara toleransi durasi kehilangan data (RPO), ukuran dan durasi pencadangan, serta waktu pemulihan.

Untuk memastikan pemulihan yang efisien dan meminimalkan kehilangan data jika terjadi kegagalan sistem, strategi pencadangan yang andal harus mencakup pencadangan database dan file write-ahead log (WAL). Pencadangan file data secara rutin (biasanya setiap hari) sangat penting. Anda juga harus mencadangkan file WAL, yang mencatat modifikasi database dan sangat penting untuk pemulihan point-in-time dan menjaga integritas data selama pemulihan.

Replikasi database

PostgreSQL menawarkan server replika untuk meningkatkan keandalan. Replika ini diklasifikasikan sebagai standby warm, yang tidak menerima koneksi aplikasi, atau standby hot, yang beroperasi dalam mode hanya baca. Perubahan dari database utama terus diterapkan ke replika agar data replika tetap terkini. Jika database utama gagal, replika akan dipromosikan ke status utama dan mengambil alih tanggung jawab database utama.

Replika database dapat ditempatkan di zona atau pusat data yang sama dengan instance utama, di zona yang berbeda, di region yang berbeda, atau di campuran lokasi tersebut. Makin jauh lokasi replika dari database utama, makin besar latensi saat mengirim perubahan untuk menjaga agar replika tetap terbaru. Untuk deployment di berbagai lokasi yang berjauhan untuk memitigasi kegagalan berskala besar, seperti kesalahan regional, replikasi data biasanya dilakukan secara asinkron. Pendekatan ini menghindari penurunan performa yang dapat terjadi dalam penyiapan tersebut.

Dalam deployment ketersediaan tinggi, replika biasanya di-deploy dalam jarak yang dekat dengan database utama. Misalnya, replika yang di-deploy di zona berbeda dalam pusat data yang sama menawarkan RTO rendah dan RPO mendekati nol. Di sisi lain, dalam konfigurasi pemulihan dari bencana, replika di-deploy di pusat data atau region terpisah, bergantung pada tingkat perlindungan terhadap gangguan yang diperlukan. Pendekatan ini menghasilkan RPO yang lebih tinggi (karena replikasi mungkin asinkron) dan RTO yang bervariasi.

Tabel berikut merangkum mekanisme yang digunakan untuk arsitektur referensi ketersediaan AlloyDB Omni:

Fitur Standar Peningkatan Premium
Cadangan ✔ ✔ ✔
Replika Zonal ❌ ✔ ✔
Replika Lintas Zona ❌ ✔ ✔
Replika Regional ❌ ❌ ✔

Tabel 1. Mekanisme ketersediaan AlloyDB Omni yang didukung

Skenario kegagalan dan pemulihan database

Kegagalan database dapat terjadi pada tingkat berikut:

  • Kegagalan instance (node atau server): database itu sendiri gagal.
  • Kegagalan server: server yang menghosting database gagal.
  • Kegagalan zona: seluruh pusat data yang menampung server mengalami kegagalan.
  • Kegagalan region: seluruh region yang berisi beberapa pusat data (zona ketersediaan) tidak tersedia, misalnya, karena banjir atau gempa bumi berkekuatan besar.

Kemungkinan dan risiko bencana berkurang jika jumlah peristiwa lebih sedikit dan biaya untuk mencegah peristiwa ini meningkat. Bisnis harus menentukan toleransi risiko mereka dan memilih apakah akan menerima potensi gangguan atau berinvestasi dalam arsitektur yang lebih tangguh untuk meminimalkan risiko.

Tabel berikut merangkum skenario pemulihan yang didukung oleh arsitektur referensi AlloyDB Omni:

Jenis Bencana Standar Peningkatan Premium
Kegagalan VM/Instance ✔ ✔ ✔
Kegagalan Node/Server ✔ ✔ ✔
Kegagalan Zona ❌ ✔ ✔
Kegagalan Regional ❌ ❌ ✔

Tabel 2. Skenario pemulihan yang didukung

Pertimbangkan tujuan bisnis Anda untuk database AlloyDB Omni, seperti kebutuhan penting akan ketersediaan beberapa 9 (99,99%) dan nol kehilangan data saat pemulihan untuk aplikasi penting. Tujuan arsitektur referensi ketersediaan adalah untuk memenuhi persyaratan RTO dan RPO.

AlloyDB Omni menawarkan arsitektur ketersediaan standar, yang ditingkatkan, dan premium untuk melindungi database dari gangguan terencana dan tidak terencana, yang disesuaikan dengan berbagai kebutuhan bisnis. Misalnya, lingkungan pengembangan dapat menggunakan perlindungan dasar dengan pencadangan, sedangkan aplikasi penting dapat menggunakan penyiapan ketersediaan tinggi dan pemulihan dari bencana.

Langkah berikutnya

Pelajari lebih lanjut arsitektur referensi ketersediaan AlloyDB Omni: