Pemahaman tentang pg_probackup. Bagian kedua

Kami terus berkenalan dengan alat pg_probackup .



Di bagian pertama , kami menginstal pg_probackup, membuat dan mengonfigurasi sebuah instance, mengambil dua backup - full dan incremental dalam mode DELTA, mempelajari cara melihat dan mengubah konfigurasi instance. Kami mendapat daftar cadangan, menulis skrip (bkp_base.sh) yang mencadangkan cluster dan mengirimkan hasil operasi pencadangan terakhir ke sistem pemantauan. Hari ini kami akan menangani tugas yang tidak kalah menarik.

Masalah 2

Diberikan: Kami memiliki dua server, yang pertama kami memiliki database kami (hostname srv_db1, user postgres), dan yang kedua kami akan menyimpan backup (hostname srv_bkp, user backup_user). Tetapi selain cadangan di server yang sama, kami akan menyimpan salinan log pra-perekaman agar dapat memulihkan ke titik waktu tertentu (Pemulihan titik waktu) dalam 3 hari terakhir.



Solusi:



Agar dapat memulihkan ke titik waktu yang dipilih (titik pemulihan), kita harus memiliki cadangan yang dibuat sebelum titik pemulihan, serta semua file WAL dari saat pencadangan dimulai hingga titik pemulihan.



Kami sudah memiliki cadangan, tetap mengkonfigurasi pengarsipan WAL di srv_bkp.

Hubungkan ke srv_db1 oleh pengguna postgres dan jalankan perintah berikut:

ssh-keygen -t rsa
ssh-copy-id backup_user@srv_bkp

Mari kita ubah file ~ / .ssh / autorized_keys menjadi srv_bkp:

command="pg_probackup-12 agent" ssh-rsa AAAA....

Kembali ke srv_db1, Anda perlu mengaktifkan mode arsip (archive_mode) dan mengkonfigurasi parameter archive_command. Ini berisi perintah untuk membuat cadangan segmen WAL penuh.

psql -c 'show archive_mode'

jika kembali mati, maka ubah ke hidup

psql -c 'alter system set archive_mode = on'

Agar perubahan diterapkan, Anda perlu memulai ulang PostgreSQL, tetapi untuk saat ini kami akan menunda tindakan ini dan mengkonfigurasi satu parameter lagi.



Jika aliran file WAL cukup besar, server cadangan mungkin akan segera kehabisan ruang, jadi kita dapat memasukkan opsi --compress di baris archive_command, kemudian file log akan dikompresi sebelum dikirim ke srv_bkp. Dan kita tidak perlu khawatir tentang fakta bahwa file-file ini perlu dibuka secara terpisah selama pemulihan - pg_probackup dapat bekerja dengan file yang dikompresi.

alter system set archive_command = 'pg_probackup-12 archive-push -B /home/backup_user/backup_db --instance=db1 --wal-file-path=%p --wal-file-name=%f --remote-host=srv_bkp --remote-user=backup_user --compress';

Sekarang Anda dapat memulai ulang.



Apa yang kami lakukan di tugas pertama disebut cadangan offline. Disebut demikian karena salinan seperti itu berisi semua file WAL yang diperlukan untuk memulihkannya. Dalam tugas saat ini, kami memindahkan dari salinan offline ke salinan arsip, salinan tersebut tidak berisi log yang diperlukan di dalamnya, tetapi ini tidak masalah, karena kami akan menyimpan semua file WAL yang kami butuhkan ke arsip. Saat memulihkan dari salinan cadangan, file WAL akan disalin dari arsip.



Karena dalam situasi yang dipertimbangkan kami beralih dari cadangan offline (dibuat dalam mode aliran) ke arsip (dalam mode arsip), situasi mungkin muncul di mana kami membuat salinan ketika mode arsip belum diaktifkan, setelah itu beberapa segmen WAL telah muncul dihapus. Artinya, pencadangan pertama setelah beralih ke mode arsip tidak dapat dilakukan dalam mode PAGE, karena segmen WAL dalam arsip antara salinan masa lalu dan saat ini mungkin tidak lengkap.



Mari lakukan ini menggunakan skrip yang dibuat di tugas pertama:

./bkp_base.sh DELTA

Kemudian kami akan membuat cadangan pertama kami dalam mode PAGE

./bkp_base.sh PAGE

Izinkan saya mengingatkan Anda bahwa ada tiga mode inkremental yang tersedia: PAGE, DELTA dan PTRACK. Mereka berbeda satu sama lain dalam cara mendapatkan informasi yang diperlukan tentang halaman yang diubah:

• DELTA — ,
• PAGE — WAL , ,
• PTRACK — - Block Change Tracking Oracle — , . ( ..). , .

Sekarang mari kita pikirkan, salinan cadangan, agar dapat dipulihkan darinya, membutuhkan file WAL yang dibuat selama pembuatan cadangan. Itu. jika kami membuat cadangan tambahan selama 30 menit dan selama 30 menit ini 10 GB WAL dibuat, maka hanya 10 GB ini yang diperlukan sehingga kami dapat memulihkannya secara konsisten. Semua file WAL lainnya hanya diperlukan untuk tujuan pemulihan waktu tertentu.



Tugas tersebut menunjukkan bahwa kami ingin dapat memulihkan kapan saja selama 3 hari terakhir. Artinya, semua WAL untuk periode ini harus disimpan, sebagai tambahan, semua WAL yang diperlukan untuk memulihkan dari cadangan sebelumnya harus disimpan, tetapi kami tidak perlu menyimpan semua file WAL lainnya!



Dan, jika kita bisa menggunakan perintah find untuk menghapus WAL usang, menambahkan mtime dan -exec rm {} ke dalamnya, menentukan segmen WAL mana yang diperlukan untuk memulihkan cadangan tertentu secara konsisten menjadi bukan tugas yang mudah. Ada baiknya pengembang memikirkan hal ini dan menambahkan parameter --wal-depth, yang dengannya Anda dapat mengatur kedalaman penyimpanan WAL, dihitung dalam cadangan.



Ini dapat dijelaskan secara skematis sebagai berikut:







Harap dicatat bahwa sekarang di suatu tempat di tengah hari Sabtu, yang berarti bahwa kami dapat menghapus semua file WAL yang tidak diperlukan untuk memulihkan cadangan yang lebih lama dari tiga hari (warna coklat pada grafik). WAL yang masih dibutuhkan disorot dengan warna kuning. Di sini pertanyaan logis mungkin muncul - tetapi bagaimanapun juga, ini sudah tengah hari Sabtu, yang berarti beberapa catatan pagi yang dibuat pada hari Rabu tidak lagi diperlukan, dan itu dapat dihapus. Ya, memang begitu, dan Anda dapat mengonfigurasi penghapusan kelebihan WAL setidaknya setiap menit, tetapi dalam artikel kami, kami akan menghapus log bersamaan dengan pembuatan cadangan, jadi meskipun tidak lagi termasuk dalam kebijakan penyimpanan, mereka akan dihapus saat membuat cadangan berikutnya. ...



Ubah pengaturan instance db1 - tambahkan masa pakai file WAL

pg_probackup set-config --instance db1 --wal-depth=3

Mari kita periksa apakah pengaturan telah diterapkan:

pg_probackup show-config --instance=db1 | grep wal-depth

Tambahkan flag --delete-wal ke perintah backup di skrip bkp_base.sh , dan juga hapus switch --stream, karena kita beralih dari backup offline ke yang diarsipkan

pg_probackup backup --instance=db1 -j 2 --progress -b $1 --compress --delete-expired --delete-wal

Saat ini, kami telah mengonfigurasi pembuatan cadangan arsip di server terpisah. Selain itu, file log ditambahkan di sini, yang memberi kita kesempatan untuk menggunakan pemulihan tidak hanya untuk cadangan tertentu, tetapi juga untuk melakukan pemulihan Point-in-time - pemulihan ke titik waktu tertentu.



Karena sekarang kita memiliki arsip file WAL, kita dapat menggunakan mode PAGE untuk membuat incremental backup, izinkan saya mengingatkan Anda bahwa dalam mode ini, perubahan relatif terhadap backup sebelumnya dihitung bukan oleh file data, tetapi oleh akumulasi WAL sejak backup sebelumnya.



PS Hanya untuk tujuan pendidikan! Mari buat tabel di database di server srv_db1:

psql -c 'create table timing(time_now timestamp with time zone)'

Kemudian tulis baris berikut ke crontab:

* * * * * psql -c 'insert into timing(select now())'

Setiap menit, informasi tentang waktu saat ini akan dicatat dalam database, informasi ini akan berguna bagi kita saat kita mengembalikan ke suatu titik waktu.

Masalah 3

Diberikan:



Kami memiliki dua server, yang pertama kami memiliki database kami (hostname srv_db1, user postgres), yang kedua menyimpan backup yang diarsipkan dan file WAL (hostname srv_bkp, user backup_user). Server lain srv_db2 muncul di lingkungan kami (user postgres), di mana kami harus menerapkan replika cluster kami dan mengkonfigurasi ulang pg_probackup sehingga dibutuhkan cadangan dari replika.



Keputusan:



Internet penuh dengan deskripsi tentang cara membuat replika di PostgreSQL, Anda hanya perlu mengarahkan "membuat replika di PostgreSQL" ke mesin pencari - pilih, saya tidak mau! Ada dokumentasi, artikel, dan bahkan video tutorial. Dan semua metode ini bagus, tetapi biasanya tidak memperhitungkan bahwa kita sudah memiliki cadangan. Kami ingin membuat replika menggunakan cadangan, jadi kami menghapus beban membaca dari master. Artinya, server produksi kami tidak akan mengetahui bahwa di suatu tempat di sebelahnya replika sedang dibuat (ini, tentu saja, dengan reservasi - di sini slot replikasi perlu dibuat dan hak akses untuk mendaftar, tetapi saat kami membuat replika, tidak ada beban tambahan pada master. tidak akan).



Kami mengatur akses dengan kunci antara server srv_bkp dan srv_db2, menginstal PostgreSQL dan pg_probackup di srv_db2 (kami melakukan semuanya kecuali instalasi PostgreSQL selama tugas pertama, tetapi jika Anda memiliki pertanyaan tentang menginstal DBMS, lihat di sini ).



Buka srv_db2

ssh-keygen -t rsa
ssh-copy-id backup_user@srv_bkp

Buka srv_bkp

ssh-copy-id postgres@srv_db2

Mari aktifkan paranoid internal kita dan edit ~ / .ssh / autorized_keys - insert

command="pg_probackup-12 agent"

sebelum kunci baru.



Menggunakan file WAL jauh lebih lambat daripada memulihkan dari cadangan, jadi mari buat cadangan tambahan lainnya - sambungkan ke server srv_bkp menggunakan backup_user dan jalankan perintah:

pg_probackup backup --instance=db1 -j 2 --progress -b PAGE --compress

Mengapa kami tidak menggunakan skrip yang kami buat? Faktanya adalah bahwa sebelumnya kami menambahkan opsi --delete-wal ke skrip, yaitu, setelah membuat cadangan ini, kami tidak akan dapat memulihkan ke titik waktu tiga hari yang lalu. Tetapi jika kita meninggalkan backup ini, maka backup berikutnya yang dibuat dengan menjalankan script kita akan tetap meninggalkan WAL hanya untuk dua hari terakhir, yaitu, setelah kita memulihkan dari backup ini, masuk akal untuk menghapusnya.



Kami melakukan pemulihan:

time pg_probackup restore --instance=db1 -D /var/lib/pgsql/12/data -j 2 --restore-as-replica --progress --remote-proto=ssh --remote-host=srv_db2 --archive-host=srv_bkp --archive-user=backup_user --log-level-console=log --log-level-file=verbose --log-filename=restore_rep.log

Direktori / var / lib / pgsql / 12 / data harus kosong, sebagai tambahan, pada server srv_db1, Anda harus membuat perubahan pada pg_hba.conf - izinkan akses dari server srv_db2 menggunakan protokol replikasi.

host    replication     all             srv_db2                 md5

Kami membaca kembali konfigurasi:

psql -c 'select pg_reload_conf()'

Memeriksa kesalahan ketik:

psql -c 'select * from pg_hba_file_rules'

buat file ~ / .pgpass di srv_db2, di mana kami menentukan izin koneksi di srv_db1 tetapi kali ini dengan basis replikasi dan mulai PostgreSQL.

srv_db1:5432:replication:backup:Strong_PWD

Dan mari kita ubah haknya menjadi 600:

chmod 600 ~/.pgpass

Kami memulai cluster di srv_db2.



Mari kita periksa apakah semuanya bekerja dengan baik. Kami akan menggunakan kemungkinan berikut untuk ini.



Kami melihat file log replika di dalamnya, di suatu tempat di dekat akhir, baris berikut akan muncul:

Database system is ready to accept read only connections

psql -c 'select pg_is_in_recovery()' 

harus mengembalikan t



Sekarang mari kita buat pelat t1 di wizard:

srv_db1: psql -c 'create table t1()'

Mari kita periksa apakah itu muncul di replika.

srv_db2: psql -c '\d'

Pelat ada di tempatnya, maka replikasi berfungsi. Kami menghapus pelat di master.

srv_db1: psql -c 'drop table t1'

Tentu saja, pada database yang sebenarnya, Anda sekarang harus membuat slot replikasi pada master dan mengkonfigurasi replika sehingga replika tersebut masuk ke master melalui slot ini, tetapi topik artikel kami bukanlah replika, tetapi backup, jadi mari kita lanjutkan.



Jadi, replika berfungsi untuk kita, jika perlu, kita dapat beralih ke replika, tetapi mari tanyakan pada diri kita sendiri pertanyaan - dapatkah kita melakukannya lebih baik?

Tentu saja Anda bisa. Mengapa kita perlu mengambil cadangan dari master ketika kita dapat menghapus beban pembacaan dari master dan mentransfernya ke replika?



PERINGATAN! REPLIC LACK MONITORING HARUS DIMONITOR, LAINNYA DAPAT MENGAMBIL BAHWA ANDA TIDAK AKAN TAHU BAHWA REPLICA DILAGGASI DAN AKAN LANJUTKAN UNTUK BACKUP DARI REPLICA LAG.



Ayo lakukan itu!



Kami membuat perubahan dalam pengaturan cluster di server srv_db1 dan srv_db2:

alter system set archive_timeout=180;
select pg_reload_conf();

Buka srv_bkp dan ubah nilai parameter host jarak jauh:

pg_probackup set-config --instance db1 --remote-host=srv_db2

Kami membuat perubahan pada .pgpass di server srv_bkp - tambahkan string koneksi ke server srv_db2:

srv_db2:5432:replication:backup:Strong_PWD
srv_db2:5432:backupdb:backup:Strong_PWD

Dan mari kita coba mengambil cadangan lain.

srv_bkp: ./bkp_base.sh PAGE

Kami melihat bahwa cadangan telah berfungsi.



Masalah terpecahkan!



Bagian selanjutnya akan dikhususkan untuk memulihkan dari cadangan: kami akan mempertimbangkan berbagai opsi pemulihan, mempelajari cara memulihkan ke cadangan tertentu, ke suatu titik waktu, berkenalan dengan pemulihan parsial dan inkremental.