POSTGRES-barman

 

Menggunakan Barman untuk Pemulihan Bencana PostgreSQL

https://id.sqldat.com/xvs/bzl/1011017097.html

Pasti ada banyak alat canggih yang tersedia sebagai opsi pencadangan dan pemulihan untuk PostgreSQL secara umum; Barman, PgBackRest, BART adalah beberapa nama dalam konteks ini. Apa yang menarik perhatian kami adalah bahwa Barman adalah alat yang mengejar dengan cepat penyebaran produksi dan tren pasar.

Baik itu penyebaran berbasis buruh pelabuhan, perlu menyimpan cadangan di penyimpanan cloud yang berbeda atau kebutuhan arsitektur pemulihan bencana yang sangat dapat disesuaikan - Barman adalah pesaing yang sangat kuat dalam semua kasus tersebut.

Blog ini mengeksplorasi Barman dengan beberapa asumsi tentang penerapan, namun dalam kasus apa pun ini tidak boleh dianggap hanya set fitur yang mungkin. Barman jauh melampaui apa yang dapat kami tangkap di blog ini dan harus dieksplorasi lebih lanjut jika 'pencadangan dan pemulihan instance PostgreSQL' dipertimbangkan.

Asumsi Penerapan DR Siap 

RPO=0 umumnya dikenakan biaya - penerapan server siaga sinkron sering kali memenuhinya, tetapi kemudian hal itu cukup sering memengaruhi TPS server utama.

Seperti PostgreSQL, Barman memberikan banyak opsi penerapan untuk memenuhi kebutuhan Anda dalam hal RPO vs kinerja. Pikirkan kesederhanaan penerapan, RPO=0 atau hampir nol dampak kinerja; Barman cocok untuk semuanya.

Kami mempertimbangkan penerapan berikut untuk menetapkan solusi pemulihan bencana untuk arsitektur pencadangan dan pemulihan kami.

Gambar 1:Penerapan PostgreSQL dengan Barman

Ada dua situs (seperti pada umumnya untuk situs pemulihan bencana) - Situs-X dan Situs-Y.

Di Site-X ada:

• Satu server 'pgServer' menghosting pgServer instance server PostgreSQL, dan satu pengguna OS 'postgres' 
  • Instance PostgreSQL juga menjadi host peran pengguna super 'bmuser'
• Satu server 'bServer' yang menghosting binari Barman dan pengguna OS 'bmuser'

Di Site-Y ada:

• Satu server 'geobServer' yang menghosting binari Barman dan pengguna OS 'bmuser'

Ada beberapa jenis koneksi yang terlibat dalam penyiapan ini.

• Antara 'bServer' dan 'pgServer':
  • Konektivitas bidang manajemen dari Barman ke Instans PostgreSQL
  • konektivitas rsync untuk melakukan pencadangan basis aktual dari Barman ke Instans PostgreSQL
  • Pengarsipan WAL menggunakan barman-wal-archive dari Instance PostgreSQL ke Barman
  • Streaming WAL menggunakan pg_receivexlog di Barman
• Antara 'bServer' dan 'geobserver':
  • Sinkronisasi antar server Barman untuk menyediakan geo-replikasi

Konektivitas Pertama 

Kebutuhan konektivitas utama antar server adalah melalui ssh. Untuk membuatnya menggunakan kunci ssh tanpa kata sandi. Mari buat kunci ssh dan tukarkan.

Di pgServer:

example@sqldat.com$ ssh-keygen -q -t rsa -N '' -f ~/.ssh/id_rsa <<<y 2>&1 >/dev/null

example@sqldat.com$ ssh-copy-id -i ~/.ssh/id_rsa.pub example@sqldat.com

example@sqldat.com$ ssh example@sqldat.com "chmod 600 ~/.ssh/authorized_keys"

Di bServer:

example@sqldat.com$ ssh-keygen -q -t rsa -N '' -f ~/.ssh/id_rsa <<<y 2>&1 >/dev/null

example@sqldat.com$ ssh-copy-id -i ~/.ssh/id_rsa.pub example@sqldat.com

example@sqldat.com$ ssh example@sqldat.com "chmod 600 ~/.ssh/authorized_keys"

Di geobServer:

example@sqldat.com$ ssh-keygen -q -t rsa -N '' -f ~/.ssh/id_rsa <<<y 2>&1 >/dev/null

example@sqldat.com$ ssh-copy-id -i ~/.ssh/id_rsa.pub example@sqldat.com

example@sqldat.com$ ssh example@sqldat.com "chmod 600 ~/.ssh/authorized_keys"

Konfigurasi Instance PostgreSQL 

Ada dua hal utama yang kita perlukan untuk menyusun kembali instance postgres - Direktori dasar dan log WAL / Transaksi yang dihasilkan setelahnya. Server energik dengan cerdas melacaknya. Yang kami butuhkan adalah memastikan bahwa umpan yang tepat dibuat agar Barman dapat mengumpulkan artefak ini.

Tambahkan baris berikut ke postgresql.conf:

listen_addresses = '172.25.130.180'     #as per above deployment assumption

wal_level = replica                     #or higher 

archive_mode = on

archive_command = 'barman-wal-archive -U bmuser bserver pgserver %p'

Perintah arsip memastikan bahwa ketika WAL akan diarsipkan oleh instance postgres, utilitas barman-wal-arsip mengirimkannya ke Server Barman. Perlu dicatat bahwa paket barman-cli karenanya harus tersedia di 'pgServer'. Ada pilihan lain untuk menggunakan rsync jika kita tidak ingin menggunakan utilitas barman-wal-archive.

Tambahkan yang berikut ke pg_hba.conf:

host     all                    all     172.25.130.186/32     md5

host     replication            all     172.25.130.186/32     md5

Pada dasarnya memungkinkan replikasi dan koneksi normal dari 'bmserver' ke instance postgres ini.

Sekarang cukup mulai ulang instance dan buat peran pengguna super yang disebut bmuser:

example@sqldat.com$ pg_ctl restart

example@sqldat.com$ createuser -s -P bmuser 

Jika diperlukan, kita dapat menghindari penggunaan bmuser sebagai pengguna super juga; yang akan membutuhkan hak istimewa yang diberikan kepada pengguna ini. Untuk contoh di atas, kami juga menggunakan bmuser sebagai kata sandi. Tapi itu saja, sejauh konfigurasi instance PostgreSQL diperlukan.

Konfigurasi Barman 

Barman memiliki tiga komponen dasar dalam konfigurasinya:

• Konfigurasi global 
• Konfigurasi tingkat server 
• Pengguna yang akan menjalankan bartender 

 Dalam kasus kami, karena Barman diinstal menggunakan rpm, kami memiliki file konfigurasi global yang disimpan di:

/etc/barman.conf

Kami ingin menyimpan konfigurasi tingkat server di direktori home bmuser, maka file konfigurasi global kami memiliki konten berikut:

[barman]

barman_user = bmuser

configuration_files_directory = /home/bmuser/barman.d

barman_home = /home/bmuser

barman_lock_directory = /home/bmuser/run

log_file = /home/bmuser/barman.log

log_level = INFO

Konfigurasi Server Barman Utama 

Dalam penerapan di atas, kami memutuskan untuk menyimpan server Barman utama di pusat data/situs yang sama tempat instance PostgreSQL disimpan. Manfaat yang sama adalah lebih sedikit lag dan pemulihan lebih cepat jika diperlukan. Tak perlu dikatakan, lebih sedikit komputasi dan/atau kebutuhan bandwidth jaringan diperlukan di server PostgreSQL juga.

Untuk membiarkan Barman mengelola instance PostgreSQL di pgServer, kita perlu menambahkan file konfigurasi (kita beri nama pgserver.conf) dengan konten berikut:

[pgserver]

description =  "Example pgserver configuration"

ssh_command = ssh example@sqldat.com

conninfo = host=pgserver user=bmuser dbname=postgres

backup_method = rsync

reuse_backup = link

backup_options = concurrent_backup

parallel_jobs = 2

archiver = on

archiver_batch_size = 50

path_prefix = "/usr/pgsql-12/bin"



streaming_conninfo = host=pgserver user=bmuser dbname=postgres

streaming_archiver=on

create_slot = auto

Dan file .pgpass yang berisi kredensial untuk bmuser dalam instance PostgreSQL:

echo 'pgserver:5432:*:bmuser:bmuser' > ~/.pgpass 

Untuk lebih memahami item konfigurasi penting:

• ssh_command :Digunakan untuk membuat koneksi di mana rsync akan dilakukan 
• koneksi :String koneksi untuk memungkinkan Barman membuat koneksi dengan server postgres
• reuse_backup :Untuk mengizinkan pencadangan tambahan dengan penyimpanan lebih sedikit 
• metode_cadangan :metode untuk mengambil cadangan direktori dasar
• path_prefix :lokasi penyimpanan biner pg_receivexlog 
• streaming_conninfo :String koneksi yang digunakan untuk streaming WAL 
• buat_slot :Untuk memastikan slot dibuat oleh instance postgres 

Konfigurasi Server Pasif Barman 

Konfigurasi situs geo-replikasi cukup sederhana. Yang dibutuhkan hanyalah informasi koneksi ssh di mana situs simpul pasif ini akan melakukan replikasi.

Yang menarik adalah bahwa simpul pasif seperti itu dapat bekerja dalam mode campuran; dengan kata lain - mereka dapat bertindak sebagai server Barman aktif untuk melakukan pencadangan untuk situs PostgreSQL dan secara paralel bertindak sebagai situs replikasi/berjenjang untuk server Barman lainnya.

Karena, dalam kasus kami, instance Barman (di Situs-Y) ini hanya perlu node pasif, yang kami butuhkan hanyalah membuat file /home/bmuser/barman.d/pgserver.conf dengan konfigurasi berikut:

[pgserver]

description =  "Geo-replication or sync for pgserver"

primary_ssh_command = ssh example@sqldat.com

Dengan asumsi bahwa kunci telah dipertukarkan dan konfigurasi global pada node ini dilakukan seperti yang disebutkan sebelumnya - kita cukup banyak menyelesaikan konfigurasi.

Dan Inilah Pencadangan dan Pemulihan Pertama Kami 

Pada server pastikan bahwa proses latar belakang untuk menerima WAL telah dipicu; dan kemudian periksa konfigurasi server:

example@sqldat.com$ barman cron

example@sqldat.com$ barman check pgserver

Pemeriksaan harus OK untuk semua sublangkah. Jika tidak, lihat /home/bmuser/barman.log.

Terbitkan perintah pencadangan pada Barman untuk memastikan ada DATA dasar di mana WAL dapat diterapkan:

example@sqldat.com$ barman backup pgserver

Pada 'geobmserver' pastikan bahwa replikasi dilakukan dengan menjalankan perintah berikut:

example@sqldat.com$ barman cron 

example@sqldat.com$ barman list-backup pgserver

Cron harus dimasukkan ke dalam file crontab (jika tidak ada). Demi kesederhanaan, saya belum menunjukkannya di sini. Perintah terakhir akan menunjukkan bahwa folder cadangan telah dibuat di geobmserver juga.

Sekarang pada instance Postgres, mari kita buat beberapa data dummy:

example@sqldat.com$ psql -U postgres -c "CREATE TABLE dummy_data( i INTEGER);"

example@sqldat.com$ psql -U postgres -c "insert into dummy_data values ( generate_series (1, 1000000 ));"

Replikasi WAL dari instance PostgreSQL dapat dilihat menggunakan perintah di bawah ini:

example@sqldat.com$ psql -U postgres -c "SELECT * from pg_stat_replication ;”

Untuk membuat ulang instance di Site-Y, pertama-tama pastikan bahwa catatan WAL dialihkan. atau contoh ini, untuk membuat pemulihan yang bersih:

example@sqldat.com$ barman switch-xlog --force --archive pgserver

Di Situs-X, mari kita tampilkan instance PostgreSQL mandiri untuk memeriksa apakah pencadangan itu waras:

example@sqldat.com$ barman cron 

barman recover --get-wal pgserver latest /tmp/data

Sekarang, edit file postgresql.conf dan postgresql.auto.conf sesuai kebutuhan. Berikut ini jelaskan perubahan yang dilakukan untuk contoh ini:

• postgresql.conf :listen_addresses berkomentar agar default ke localhost
• postgresql.auto.conf :menghapus sudo bmuser dari restore_command 

Tampilkan DATA ini di /tmp/data dan periksa keberadaan catatan Anda.

Kesimpulan

Ini hanyalah puncak gunung es. Barman jauh lebih dalam dari ini karena fungsionalitas yang disediakannya - mis. bertindak sebagai standby yang disinkronkan, skrip pengait dan sebagainya. Tak perlu dikatakan, dokumentasi secara keseluruhan harus dieksplorasi untuk mengonfigurasinya sesuai kebutuhan lingkungan produksi Anda.