Status Manajemen Cadangan Sumber Terbuka Saat Ini untuk PostgreSQL

Ada banyak cara untuk mengatasi pengambilan cadangan cluster PostgreSQL. Ada beberapa artikel dan blog yang menyajikan berbagai teknologi yang dengannya kita dapat menyimpan data berharga kita di PostgreSQL. Ada solusi pencadangan logis, pencadangan fisik di tingkat OS, di tingkat sistem file, dan sebagainya. Di blog ini kita tidak akan membahas bagian teoretis yang cukup tercakup oleh berbagai blog dan artikel serta dokumentasi resmi.

Blog ini berfokus pada keadaan berbagai alat dan solusi yang tersedia dan upaya menyajikan perbandingan menyeluruh berdasarkan pengalaman kehidupan nyata. Artikel ini sama sekali tidak mencoba untuk mempromosikan produk tertentu, saya sangat menyukai semua alat, solusi, dan teknologi yang dijelaskan di blog ini. Tujuannya di sini adalah untuk mencatat kekuatan mereka, kelemahan mereka dan untuk memandu pengguna akhir tentang alat mana yang paling sesuai dengan lingkungan, infrastruktur, dan persyaratan spesifiknya. Berikut adalah artikel bagus yang menjelaskan alat pencadangan untuk PostgreSQL di berbagai level.

Saya tidak akan menjelaskan cara menggunakan berbagai alat di blog ini, karena info ini didokumentasikan di blog di atas dan juga di dokumen resmi serta sumber daya lainnya melalui internet. Tapi saya akan menjelaskan pro dan kontra seperti yang saya alami dalam praktek. Di blog ini, kami secara eksklusif berurusan dengan cadangan PostgreSQL fisik berbasis PITR klasik yang bergantung pada:

• pg_basebackup atau pg_start_backup()/pg_stop_backup
• salinan fisik
• pengarsipan WAL atau replikasi streaming

Ada beberapa produk dan solusi bagus, beberapa open source dan gratis untuk digunakan sementara yang lain komersial. Sepengetahuan saya, itu adalah:

• pgbarman oleh kuadran ke-2 (gratis)
• pgbackrest (gratis)
• pg_probackup oleh Postgres Professional (gratis)
• BART oleh EDB (komersial)

Saya tidak memiliki kesempatan untuk mencoba BART karena ini berjalan pada rasa Linux yang tidak saya gunakan. Di blog ini, saya akan memasukkan pemikiran dan kesan saya sendiri saat berinteraksi dengan masing-masing penulis/komunitas/pengelola masing-masing solusi karena ini merupakan aspek yang sangat penting yang biasanya diremehkan pada awalnya. Sedikit terminologi untuk lebih memahami berbagai istilah di setiap alat:

pgbarman

Pgbarman atau hanya bartender adalah yang tertua dari alat-alat itu. Rilis terbaru adalah 2.6 (dirilis saat saya sedang mengerjakan blog ini! yang merupakan berita bagus).

Pgbarman mendukung pencadangan dasar melalui dua metode:

• pg_basebackup (backup_method=postgres)
• rsync (backup_method=rsync)

dan transfer WAL melalui:

• Pengarsipan WAL
  • melalui rsync
  • via barman-wal-archive / put-wal
• WAL melalui replikasi streaming dengan slot replikasi
  • Asinkron
  • Sinkron

Ini memberi kita 8 kombinasi luar biasa yang dengannya kita dapat menggunakan bartender. Masing-masing memiliki pro dan kontra.

Pencadangan dasar melalui pg_basebackup (backup_method =postgres)

Kelebihan:

• cara terbaru/modern
• bergantung pada teknologi inti PostgreSQL yang telah terbukti
• direkomendasikan oleh dokumen resmi

Kekurangan:

• tidak ada cadangan tambahan
• tidak ada pencadangan paralel
• tidak ada kompresi jaringan
• tidak ada duplikasi data
• tidak ada batas bandwidth jaringan

Pencadangan dasar melalui rsync (backup_method =rsync)

Kelebihan:

• tua dan terbukti
• Pencadangan tambahan
• deduplikasi data
• kompresi jaringan
• pencadangan paralel
• batas bandwidth jaringan

Kekurangan:

• bukan cara yang direkomendasikan (oleh penulis)

Transfer WAL melalui pengarsipan WAL (via rsync)

Kelebihan:

• penyetelan lebih mudah

Kekurangan:

• Tidak ada RPO=0 (tidak ada kehilangan data)
• tidak ada cara untuk memulihkan dari kegagalan jaringan yang lama dan berkelanjutan

Transfer WAL melalui pengarsipan WAL (via barman-wal-archive / put-wal)

Kelebihan:

• cara terbaru dan direkomendasikan (diperkenalkan pada 2.6)
• lebih andal/aman daripada rsync

Kekurangan:

• Tidak ada RPO=0 (tidak ada kehilangan data)
• masih belum ada cara untuk memulihkan dari kegagalan jaringan yang lama dan berkelanjutan

Transfer WAL melalui streaming WAL dengan slot replikasi (via pg_receivewal)

Kelebihan:

• lebih modern (dan direkomendasikan)
• RPO=0 (tanpa kehilangan data) dalam mode sinkron

Kekurangan:

• selalu dikaitkan dengan slot replikasi. Dapat berkembang jika terjadi kegagalan jaringan

Jadi, sementara pg_basebackup (metode postgres) tampak seperti masa depan bagi pgbarman, pada kenyataannya, semua fitur mewah hadir dengan metode rsync. Jadi mari kita daftar semua fitur Barman secara lebih rinci:

• Operasi jarak jauh (cadangan/pemulihan)
• Pencadangan tambahan. Salah satu fitur hebat dari bartender, pencadangan tambahan didasarkan pada perbandingan tingkat file dari file database terhadap cadangan terakhir dalam katalog. Dalam energik istilah "diferensial" mengacu pada konsep yang berbeda:Dengan terminologi energik, cadangan diferensial adalah cadangan terakhir + perubahan individu dari cadangan terakhir. Dokumen energik mengatakan bahwa mereka menyediakan cadangan diferensial melalui WAL. Pencadangan tambahan energik bekerja pada tingkat file, yang berarti jika suatu file diubah, seluruh file akan ditransfer. Ini seperti pgbackrest dan tidak seperti beberapa penawaran lain seperti pg_probackup atau BART yang mendukung cadangan diferensial/tambahan tingkat blok. Pencadangan tambahan energik ditentukan melalui:reuse_backup =tautan atau salin. Dengan mendefinisikan "salin" kami mencapai pengurangan waktu pencadangan karena hanya file yang diubah yang ditransfer dan dicadangkan tetapi masih tidak ada pengurangan ruang karena file yang tidak diubah disalin dari cadangan sebelumnya. Dengan mendefinisikan "tautan" maka file yang tidak berubah akan ditautkan secara keras (tidak disalin) dari cadangan terakhir. Dengan cara ini kita mencapai pengurangan waktu dan pengurangan ruang. Saya tidak ingin membawa lebih banyak kebingungan dalam hal ini, tetapi pada kenyataannya, cadangan tambahan bartender secara langsung sebanding dengan cadangan tambahan pgbackrest, karena pelayan memperlakukan (melalui tautan atau menyalin) cadangan tambahan secara efektif sebagai cadangan penuh. Jadi di kedua sistem, cadangan tambahan berkaitan dengan file yang diubah sejak pencadangan terakhir. Namun, mengenai pencadangan diferensial, artinya berbeda di setiap sistem yang disebutkan di atas, seperti yang akan kita lihat di bawah.
• Cadangkan dari standby. Barman memberikan opsi untuk melakukan sebagian besar operasi pencadangan basis dari siaga sehingga membebaskan yang utama dari beban IO tambahan. Namun, perlu diketahui bahwa WAL tetap harus berasal dari primer. Tidak masalah jika Anda menggunakan archive_command atau streaming WAL melalui slot replikasi, Anda belum dapat (sampai tulisan ini dibuat dengan bartender menggunakan versi 2.6) menurunkan tugas ini ke standby.
• pekerjaan paralel untuk pencadangan dan pemulihan
• Seperangkat pengaturan retensi yang kaya dan komprehensif berdasarkan salah satu dari:
  • Redundansi (jumlah cadangan yang harus disimpan)
  • Jendela pemulihan (bagaimana masa lalu cadangan harus disimpan)
  Menurut pendapat saya dari perspektif pengguna, di atas bagus. Pengguna dapat menentukan reuse_backup =link dan jendela pemulihan dan biarkan bartender (tugas cron-nya) menangani sisanya. Tidak ada cadangan diff/incr/full dll yang perlu dikhawatirkan atau dijadwalkan atau dikelola. Sistem (petugas bar) melakukan hal yang benar secara transparan.
• Memrogram skrip kait acara pra/pasca Anda sendiri.
• Pemetaan ulang tablespace

Itu adalah kekuatan terbaik dari energik. Dan benar-benar ini hampir lebih dari rata-rata yang diminta DBA dari alat pencadangan dan pemulihan. Namun, ada beberapa poin yang bisa lebih baik:

• Milis tidak begitu aktif dan pengelola jarang menulis atau menjawab pertanyaan
• Tidak ada fitur untuk melanjutkan pencadangan yang gagal/terganggu
• Slot replikasi atau penggunaan rsync/barman-wal-archive untuk pengarsipan tidak memaafkan jika jaringan gagal atau kegagalan lain dari situs cadangan. Dalam kedua kasus, jika pemadaman jaringan cukup lama dan perubahan dalam DB bernilai banyak file WAL maka yang utama akan menderita "tidak ada ruang tersisa di perangkat" dan akhirnya akan macet. (bukan hal yang baik). Apa yang menjanjikan di sini adalah bahwa bartender sekarang menyediakan cara alternatif (untuk rsync) untuk mentransfer WAL sehingga perlindungan tambahan terhadap mis. pg_wal space exhaustion mungkin diterapkan di masa depan, yang bersama dengan resume cadangan akan benar-benar membuat bartender sempurna, setidaknya untuk saya.

pgbackrest

Pgbackrest adalah tren saat ini di antara alat pencadangan sumber terbuka, terutama karena efisiensinya untuk mengatasi volume data yang sangat besar dan kehati-hatian yang diberikan pembuatnya dalam validasi cadangan melalui checksum. Pada tulisan ini ada pada versi v2.09, dan dokumen dapat ditemukan di sini. Panduan Pengguna mungkin sedikit ketinggalan zaman tetapi dokumen lainnya sangat mutakhir dan akurat. Pgbackrest bergantung pada pengarsipan WAL menggunakan archive_command-nya sendiri dan mekanisme transfer filenya sendiri yang lebih baik dan lebih aman daripada rsync. Jadi pgbackrest cukup maju karena tidak memberikan pilihan yang lebih besar yang disediakan bartender. Karena tidak ada mode sinkron yang terlibat, secara alami pgbackrest tidak menjamin RPO=0 (nol kehilangan data). Mari kita jelaskan konsep pgbackrest:

• Cadangan dapat berupa:
  • Penuh. Cadangan lengkap menyalin seluruh cluster database.
  • Diferensial (berbeda). Cadangan diferensial hanya menyalin file yang diubah sejak pencadangan penuh terakhir. Agar pemulihan berhasil, cadangan diferensial dan cadangan lengkap sebelumnya harus valid.
  • Inkremental (termasuk). Cadangan inkremental hanya menyalin file yang diubah sejak pencadangan terakhir (yang mungkin berupa cadangan lengkap, diferensial, atau bahkan cadangan inkremental). Sama halnya dengan cadangan diferensial, untuk melakukan pemulihan yang berhasil, semua cadangan yang diperlukan sebelumnya (termasuk cadangan ini, perbedaan terbaru, dan cadangan lengkap sebelumnya) harus valid.
• Sebuah bait adalah definisi dari semua parameter yang diperlukan dari cluster PostgreSQL. Server PostgreSQL normal memiliki baitnya sendiri, sedangkan server cadangan akan memiliki satu bait untuk setiap cluster PostgreSQL yang dicadangkan.
• Konfigurasi adalah tempat menyimpan informasi tentang bait (biasanya /etc/pgbackrest.conf)
• Repositori adalah tempat pgbackrest menyimpan WAL dan cadangan

Pengguna didorong untuk mengikuti dokumentasi seperti yang disarankan oleh dokumentasi itu sendiri, dari atas ke bawah. Fitur paling penting dari pgbackrest adalah:

• Pencadangan dan pemulihan paralel
• Tidak diperlukan akses SQL langsung ke server PostgreSQL
• Operasi Lokal/Jarak Jauh
• Retensi berdasarkan:
  • retensi cadangan penuh (jumlah cadangan lengkap yang harus disimpan)
  • retensi cadangan berbeda (jumlah cadangan berbeda yang harus disimpan)
  Cadangan tambahan tidak memiliki penyimpanannya sendiri dan kedaluwarsa segera setelah cadangan sebelumnya kedaluwarsa. Jadi pengguna dapat menentukan jadwal untuk mengambil cadangan penuh dan satu set cadangan bergulir di antara mereka.
• Cadangkan dari standby. Beberapa file masih harus berasal dari file utama tetapi salinan massal berlangsung di standby. Tetap WAL harus berasal dari yang utama.
• Integritas cadangan. Orang-orang di belakang pgbackrest sangat berhati-hati dalam hal integritas cadangan. Setiap file diperiksa pada waktu pencadangan dan juga diperiksa setelah pemulihan untuk memastikan bahwa tidak ada bug perangkat keras atau perangkat lunak yang bermasalah yang dapat menyebabkan pemulihan yang salah. Juga jika checksum tingkat halaman diaktifkan di cluster PostgreSQL maka checksum juga dihitung untuk setiap file. Selain itu, checksum dihitung untuk setiap file WAL.
• Jika kompresi dinonaktifkan dan tautan keras diaktifkan, cluster dapat langsung ditampilkan dari katalog. Ini sangat penting untuk database besar multi-TB.
• Resume dari back yang gagal/terganggu. Sangat berguna jika jaringan tidak dapat diandalkan.
• Pemulihan delta:Pemulihan ultra cepat untuk database besar, tanpa membersihkan seluruh cluster.
• Dorong WAL asinkron &Paralel ke server cadangan. Ini adalah salah satu poin terkuat dari pgbackrest. Pengarsip PostgreSQL hanya menyalin ke spool melalui push-arsip dan pekerjaan berat transfer dan pemrosesan terjadi dalam proses pgbackrest terpisah. Hal ini memungkinkan transfer WAL besar-besaran sambil memastikan waktu respons PostgreSQL yang rendah.
• Pemetaan ulang tablespace
• Dukungan Amazon S3
• Dukungan untuk ukuran antrian WAL maks. Ketika situs pencadangan sedang down atau jaringan gagal, menggunakan opsi ini akan mengejek seperti pengarsipan berhasil, memungkinkan PostgreSQL untuk menghapus WAL mencegah pengisian pg_wal, dan dengan demikian menyimpan server pgsql dari potensi PANIC.

Jadi pgbackrest dari segi fitur memberikan banyak penekanan dalam hal validasi dan kinerja data, tidak mengherankan jika pgbackrest digunakan oleh instalasi PostgreSQL terbesar dan tersibuk. Namun, ada satu hal yang dapat diperbaiki:

• Akan sangat berguna untuk memiliki opsi yang lebih "liberal" sejauh menyangkut retensi, yaitu menyediakan cara untuk menentukan beberapa periode retensi secara deklaratif dan kemudian membiarkan pgbackrest menangani cadangan penuh/diff/incr sesuai kebutuhan.

pg_probackup

Pg_proback adalah alat lain yang menjanjikan untuk pencadangan. Ini awalnya didasarkan pada pg_arman. Penekanannya adalah pada kinerja cadangan. Ini didasarkan pada katalog, dan instance, sangat mirip dengan alat lainnya, jadi kami memilikinya. Fitur utamanya meliputi:

• Dukungan tingkat cadangan yang kaya mulai dari:
  • Cadangan penuh
  • Tiga jenis tambahan:
    • Pencadangan HALAMAN. Perubahan level ditemukan melalui pemindaian WAL. Memerlukan akses penuh ke urutan WAL tanpa gangguan sejak pencadangan sebelumnya.
    • Cadangan DELTA. Hanya halaman yang diubah yang disalin ke cadangan. Terlepas dari pengarsipan WAL, menempatkan beban tertentu di server.
    • Pencadangan PTRACK. Memerlukan patching inti pgsql khusus. Bekerja dengan mempertahankan bitmap dengan cepat segera setelah halaman dimodifikasi. Pencadangan yang sangat cepat dengan beban minimal di server.
• Cadangan juga dapat dibagi menjadi:
  • Pencadangan otomatis. Itu tidak memiliki persyaratan pada WAL di luar cadangan. Tidak ada PITR.
  • Arsipkan cadangan. Mereka mengandalkan pengarsipan berkelanjutan, dan mendukung PITR.
• model multithreaded (berbeda dengan bartender, pgbackrest dan tentu saja PostgreSQL sendiri yang mengikuti model multiproses)
• Konsistensi data dan validasi sesuai permintaan tanpa pemulihan
• Cadangkan dari standby tanpa akses ke primer.
• Spesifikasi kebijakan retensi ekspresif di mana redundansi dapat digunakan dalam mode AND bersama dengan jendela. Menggabungkan cadangan (melalui penggabungan) didukung dengan mengonversi cadangan tambahan sebelumnya menjadi penuh sebagai cara untuk mengosongkan ruang dan menyediakan metode untuk rotasi cadangan yang lancar.

Jadi, pg_probackup menyediakan serangkaian fitur hebat dengan penekanan pada kinerja sesuatu yang akan menguntungkan instalasi besar. Namun masih ada beberapa hal yang kurang, yaitu:

• Tidak ada rilis resmi yang mendukung pencadangan jarak jauh. Ini berarti pg_probackup harus dijalankan pada host yang sama dengan cluster pgsql. (Ada cabang dev yang menangani pencadangan dari situs jarak jauh serta pengarsipan ke server cadangan jarak jauh)
• Tidak ada dukungan untuk resume pencadangan yang gagal.

Kita dapat meringkas paragraf di atas dengan matriks fitur seperti di bawah ini.

Kontrol Cluster

ClusterControl menyediakan fungsionalitas baik untuk membuat cadangan langsung atau menjadwalkannya, dan mengotomatiskan tugas dengan cara yang sederhana dan cepat.

Kita dapat memilih antara dua metode pencadangan, pgdump (logis) dan pg_basebackup (biner). Kami juga dapat menentukan tempat untuk menyimpan cadangan (di server database, di server ClusterControl atau di cloud), tingkat kompresi dan enkripsi.

Selain itu, dengan ClusterControl kita dapat menggunakan fitur Pemulihan Point-in-Time dan verifikasi cadangan untuk memvalidasi cadangan yang dihasilkan.