Ringkasan arsitektur referensi ketersediaan AlloyDB Omni

Pilih versi dokumentasi:

Halaman ini memperkenalkan arsitektur ketersediaan AlloyDB Omni yang dapat Anda gunakan untuk memastikan database AlloyDB Omni dapat dipulihkan 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 penting untuk AlloyDB Omni. HA berfokus pada mempertahankan ketersediaan database dan meminimalkan Batas Waktu Pemulihan (RTO), sedangkan DR menangani pemulihan dari peristiwa bencana dan meminimalkan Toleransi Durasi Kehilangan Data (RPO).

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

  • RTO adalah waktu maksimum database dapat nonaktif atau tidak tersedia sebelum bisnis mengalami konsekuensi yang tidak dapat diterima, seperti kehilangan 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 pencadangan.
  2. Ketersediaan yang ditingkatkan: melindungi data Anda menggunakan replikasi zona di suatu region (HA).
  3. Ketersediaan premium: melindungi data Anda menggunakan replikasi zona dan regional (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 tangguh harus mencakup pencadangan file database dan log tulis-sebelum-tulis (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 mempertahankan integritas data selama pemulihan.

Replikasi database

PostgreSQL menawarkan server replika untuk meningkatkan keandalan. Replika ini diklasifikasikan sebagai standby hangat, yang tidak menerima koneksi aplikasi, atau standby aktif, yang beroperasi dalam mode hanya baca. Perubahan dari database utama terus diterapkan ke replika untuk menjaga data replika tetap terbaru. Jika database utama gagal, replika akan dipromosikan ke status utama dan mengasumsikan 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 campuran lokasi ini. Semakin jauh replika berada dari database utama, semakin besar latensi saat mengirim perubahan untuk menjaga replika tetap terbaru. Untuk deployment di lokasi yang jauh untuk mengurangi kegagalan skala 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 di dekat database utama. Misalnya, replika yang di-deploy di zona yang 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 yang diperlukan terhadap gangguan. 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 Enhanced Premium
Cadangan ✔ ✔ ✔
Replika Zona ❌ ✔ ✔
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 gagal.
  • 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 akan menurun jika ada lebih sedikit peristiwa dan biaya untuk mencegah peristiwa ini meningkat. Bisnis harus menentukan toleransi risiko 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 Enhanced 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 untuk beberapa 9 (99,99%) ketersediaan dan tanpa kehilangan data saat pemulihan untuk aplikasi penting. Tujuan dari arsitektur referensi ketersediaan adalah untuk memenuhi persyaratan RTO dan RPO.

AlloyDB Omni menawarkan arsitektur ketersediaan standar, ditingkatkan, dan premium untuk melindungi database dari gangguan terencana dan tidak terencana, yang selaras 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: