Melindungi data Anda menggunakan pencadangan

Pilih versi dokumentasi:

Halaman ini menjelaskan arsitektur referensi Ketersediaan Standar AlloyDB Omni, yang menyediakan perlindungan data menggunakan pencadangan.

Kasus penggunaan

Arsitektur referensi ini mendukung skenario berikut:

  • Anda memiliki database yang dapat mentolerir waktu nonaktif dan kehilangan data sejak pencadangan terakhir.
  • Anda ingin melindungi database AlloyDB Omni dari kesalahan pengguna, kerusakan, atau kegagalan fisik di tingkat database (bukan snapshot server atau image VM).
  • Anda ingin dapat memulihkan database di tempat atau dari jarak jauh, mungkin hingga titik waktu tertentu.

Cara kerja arsitektur referensi

Arsitektur referensi Ketersediaan Standar mencakup pencadangan dan pemulihan database AlloyDB Omni, baik yang berjalan sebagai instance mandiri di server host, sebagai virtual machine (Menginstal AlloyDB Omni), atau di cluster Kubernetes (Menginstal AlloyDB Omni di Kubernetes).

Meskipun Ketersediaan Standar adalah implementasi dasar dan meminimalkan hardware atau layanan tambahan yang diperlukan, Batas Waktu Pemulihan (RTO) akan meningkat seiring dengan bertambahnya ukuran database. Semakin banyak data yang dicadangkan, semakin lama waktu yang dibutuhkan untuk memulihkan dan memulihkan database. Kehilangan data bergantung pada jenis pencadangan. Jika hanya file data yang dicadangkan secara berkala, saat Anda memulihkan, Anda akan mengalami kehilangan data sejak pencadangan terakhir.

Mengurangi RPO

Fitur pengarsipan berkelanjutan PostgreSQL memungkinkan Anda mencapai Batas Waktu Pemulihan (RPO) yang rendah dan mengaktifkan pemulihan point-in-time melalui pencadangan. Proses ini melibatkan pengarsipan file Write-Ahead Logging (WAL) dan streaming data WAL, yang berpotensi ke lokasi penyimpanan jarak jauh.

Jika file WAL hanya diarsipkan saat penuh atau pada interval tertentu, kehilangan database lengkap (termasuk file WAL saat ini) akan membatasi pemulihan ke file WAL yang terakhir diarsipkan, yang berarti bahwa Batas Waktu Pemulihan (RPO) harus mempertimbangkan potensi kehilangan data. Sebaliknya, transfer data WAL berkelanjutan memaksimalkan nol kehilangan data.

Saat melakukan pencadangan berkelanjutan, Anda dapat melakukan pemulihan ke titik waktu tertentu. Pemulihan point-in-time memungkinkan pemulihan ke status sebelum terjadi error, seperti penghapusan tabel yang tidak disengaja atau update batch yang salah. Namun, metode pemulihan ini memengaruhi Batas Waktu Pemulihan (RPO) kecuali jika database tambahan sementara digunakan.

Strategi pencadangan

Anda dapat mengonfigurasi pencadangan tingkat Postgres AlloyDB Omni untuk disimpan di penyimpanan lokal atau jarak jauh. Meskipun penyimpanan lokal mungkin lebih cepat untuk dicadangkan dan dipulihkan, penyimpanan jarak jauh biasanya lebih andal untuk menangani kegagalan saat seluruh host atau VM gagal.

Pencadangan di non-Kubernetes

Untuk deployment non-Kubernetes, Anda dapat menjadwalkan pencadangan menggunakan alat PostgreSQL berikut:

Atau, untuk database kecil, Anda dapat memilih untuk melakukan pencadangan logis database (menggunakan pg_dump untuk satu database atau pg_dumpall untuk seluruh cluster). Anda dapat memulihkan menggunakan pg_restore.

Pencadangan di Kubernetes menggunakan operator AlloyDB Omni

Untuk AlloyDB Omni yang di-deploy di cluster Kubernetes, Anda dapat mengonfigurasi pencadangan berkelanjutan menggunakan paket pencadangan untuk setiap cluster database. Untuk mengetahui informasi selengkapnya, lihat Mencadangkan dan memulihkan di Kubernetes.

Anda dapat menyimpan pencadangan AlloyDB Omni secara lokal atau jarak jauh di Cloud Storage, termasuk opsi yang disediakan oleh vendor cloud mana pun. Untuk mengetahui informasi selengkapnya, lihat Gambar 1, yang menunjukkan potensi tujuan pencadangan.

AlloyDB Omni dengan opsi pencadangan

Gambar 1. AlloyDB Omni dengan opsi pencadangan.

Pencadangan dapat dilakukan ke opsi penyimpanan lokal atau jarak jauh. Pencadangan lokal cenderung lebih cepat karena hanya mengandalkan throughput I/O, sedangkan pencadangan jarak jauh biasanya memiliki latensi yang lebih tinggi dan bandwidth jaringan yang lebih rendah. Namun, pencadangan jarak jauh memberikan perlindungan optimal, termasuk kegagalan zona.

Anda juga dapat membagi pencadangan lokal ke penyimpanan lokal atau bersama. Meskipun opsi penyimpanan lokal terpengaruh oleh kurangnya opsi pemulihan dari bencana saat host database gagal, penyimpanan bersama memungkinkan penyimpanan tersebut dipindahkan ke server lain, lalu digunakan untuk pemulihan. Artinya, penyimpanan bersama berpotensi menawarkan RTO yang lebih cepat.

Untuk deployment penyimpanan lokal dan bersama, jenis pencadangan berikut dapat dijadwalkan atau dilakukan secara manual sesuai permintaan:

  • Pencadangan penuh: pencadangan lengkap dari semua file database yang diperlukan untuk pemulihan data.
  • Pencadangan diferensial: pencadangan hanya perubahan file sejak pencadangan penuh terakhir.
  • Pencadangan inkremental: pencadangan hanya perubahan file sejak pencadangan terakhir dari jenis apa pun.

Pemulihan point-in-time

Pencadangan berkelanjutan file PostgreSQL Write-Ahead Logging (WAL) mendukung pemulihan point-in-time. Jika, setelah peristiwa kegagalan, file WAL tetap utuh dan dapat digunakan, Anda dapat menggunakan file ini untuk memulihkan tanpa kehilangan data.

Untuk mengontrol penulisan file WAL, Anda dapat mengonfigurasi parameter berikut:

Parameter Deskripsi

wal_writer_delay

Menentukan seberapa sering penulis WAL mem-flush WAL ke disk kecuali jika penulisan diaktifkan lebih awal oleh transaksi yang melakukan commit secara asinkron Nilai default-nya adalah 200 md. Meningkatkan nilai ini akan mengurangi frekuensi penulisan, tetapi dapat meningkatkan jumlah data yang hilang jika server mengalami error.

wal_writer_flush_after

Menentukan jumlah data WAL yang dapat terakumulasi sebelum penulis WAL memaksa flush ke disk. Nilai default-nya adalah 1 MB. Jika disetel ke nol, data WAL akan selalu di-flush ke disk secara langsung.

synchronous_commit

Menentukan apakah commit menampilkan respons kepada pengguna sebelum data WAL di-flush ke disk. Setelan default-nya adalah on, yang memastikan transaksi bersifat tahan lama. Dengan kata lain, commit telah ditulis ke disk sebelum menampilkan kode keberhasilan kepada pengguna. Jika disetel ke off, akan ada hingga tiga kali wal_writer_delay sebelum transaksi ditulis ke disk.

Pemantauan penggunaan WAL

Anda dapat menggunakan metode berikut untuk mengamati penggunaan WAL:

Metode pengamatan Deskripsi

pg_stat_wal

Tampilan standar ini memiliki kolom wal_write dan wal_sync, yang menyimpan jumlah penulisan WAL dan sinkronisasi WAL. Jika parameter konfigurasi track_wal_io_timing diaktifkan, wal_write_time dan wal_sync_time juga akan disimpan. Snapshot reguler dari tampilan ini dapat membantu menampilkan aktivitas tulis dan sinkronisasi WAL dari waktu ke waktu.
pg_current_wal_lsn() Fungsi ini menampilkan posisi nomor urutan log (lsn) saat ini yang, jika dikaitkan dengan stempel waktu dan dikumpulkan sebagai snapshot dari waktu ke waktu, dapat memberikan byte/detik WAL yang dihasilkan menggunakan fungsi pg_wal_lsn_diff(lsn1, lsn2). Fungsi ini adalah metrik yang berguna untuk memahami tingkat transaksi dan performa file WAL.

Streaming data WAL ke lokasi jarak jauh

Saat Anda menggunakan Barman, data WAL juga dapat disiapkan untuk di-streaming secara real time ke lokasi jarak jauh guna memastikan bahwa ada sedikit atau tidak ada kehilangan data pada pemulihan. Meskipun di-streaming secara real time, ada kemungkinan kecil kehilangan transaksi yang di-commit karena penulisan streaming ke server barman jarak jauh bersifat asinkron secara default. Namun, Anda dapat menyiapkan streaming WAL menggunakan mode sinkron yang menyimpan WAL dan mengirim respons status kembali ke database sumber. Perlu diingat bahwa pendekatan ini dapat memperlambat transaksi jika harus menunggu penulisan ini selesai sebelum melanjutkan.

Jadwal pencadangan

Di sebagian besar lingkungan, pencadangan biasanya dijadwalkan setiap minggu. Berikut adalah jadwal pencadangan mingguan yang umum:

  • Minggu: pencadangan penuh
  • Senin, Selasa: pencadangan
  • Rabu: pencadangan diferensial
  • Kamis, Jumat: pencadangan inkremental
  • Sabtu: pencadangan diferensial

Dengan menggunakan jadwal umum ini, jendela pemulihan bergulir selama satu minggu memerlukan ruang penyimpanan hingga tiga pencadangan penuh ditambah pencadangan inkremental atau diferensial yang diperlukan. Pendekatan ini mendukung pemulihan untuk kegagalan yang terjadi selama pencadangan penuh pada hari Minggu, dan pemulihan database diperlukan untuk diperpanjang hingga hari Minggu sebelumnya sebelum pencadangan dimulai.

Untuk meminimalkan RTO dengan potensi RPO yang lebih tinggi, database tambahan dapat beroperasi dalam mode pemulihan berkelanjutan. Hal ini melibatkan pemutaran ulang pencadangan dan terus memperbarui lingkungan sekunder dengan mengarsipkan dan memutar ulang file WAL baru. RPO sebenarnya, yang mencerminkan potensi kehilangan data, bergantung pada frekuensi transaksi, ukuran file WAL, dan penggunaan streaming WAL.

Memulihkan di non-Kubernetes

Untuk deployment non-Kubernetes, memulihkan database AlloyDB Omni melibatkan penghentian container Docker, lalu memulihkan data, atau memulihkan data ke lokasi lain dan meluncurkan instance Docker baru menggunakan data yang dipulihkan tersebut. Setelah container dimulai ulang, database dapat diakses dengan data yang dipulihkan.

Untuk mengetahui informasi selengkapnya tentang opsi pemulihan, lihat Memulihkan cluster AlloyDB Omni menggunakan pgBackRest dan Memulihkan cluster AlloyDB Omni menggunakan Barman.

Memulihkan di Kubernetes menggunakan Operator

Untuk memulihkan database di Kubernetes, operator menawarkan pemulihan ke cluster dan namespace Kubernetes yang sama, dari pencadangan bernama atau klon dari Point In Time (PIT). Untuk mengklon database ke cluster Kubernetes yang berbeda, gunakan pgBackRest. Untuk mengetahui informasi selengkapnya, lihat Mencadangkan dan memulihkan di Kubernetes dan Mengklon cluster database dari ringkasan pencadangan Kubernetes.

Penerapan

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

Manfaat

  • Mudah digunakan dan dikelola, serta cocok untuk database non-kritis dengan RTO/RPO yang fleksibel.
  • Hardware tambahan minimal diperlukan
  • Pencadangan selalu diperlukan untuk rencana pemulihan dari bencana (disaster recovery) penuh
  • Pemulihan ke titik waktu mana pun dalam jendela pemulihan dapat dilakukan

Batasan

  • Persyaratan penyimpanan yang mungkin lebih besar dari database itu sendiri, bergantung pada persyaratan retensi.
  • Pemulihan bisa lambat dan dapat mengakibatkan RTO yang lebih tinggi.
  • Dapat mengakibatkan kehilangan data, bergantung pada ketersediaan data WAL saat ini setelah kegagalan database, yang dapat memengaruhi RPO secara negatif.

Alternatif

  • Pertimbangkan Arsitektur Ketersediaan yang Ditingkatkan atau Premium untuk opsi ketersediaan dan pemulihan dari bencana (disaster recovery) yang lebih baik.

Langkah berikutnya