Maaf, saya merusak recovery.conf Anda

Dalam PostgreSQL sejak zaman dahulu sudah versi 8.0, dirilis kembali pada tahun 2005, file konfigurasi khusus recovery.conf digunakan untuk mengembalikan ke titik waktu tertentu. File yang sama kemudian mulai digunakan untuk mode siaga dan replikasi streaming.

Namun, sejak rilis PostgreSQL 12 berikutnya, recovery.conf tidak akan berfungsi lagi: Saya memecahkannya.
Tapi mengapa?

Recovery.conf memiliki satu fitur: itu hanya dibaca pada awal DBMS. Dan jika pemulihan point-in-time, yang dibutuhkan kurang dari setahun sekali, masih dapat direkonsiliasi, maka kebutuhan untuk me-restart seluruh database untuk mengubah alamat server replikasi hulu agak menyedihkan. Saya melihat berbagai cara penyimpangan untuk menghindari pembatasan ini, seperti menggunakan perutean L3, skema replikasi cascading (sehingga tidak semua replika, tetapi setidaknya hanya sebagian, secara berurutan ) dan bahkan (walaupun saya belum melihatnya dalam produksi) walbouncer .

Setelah dijadwalkan ulang berikutnya dari replika, hanya karena kebutuhan untuk mengubah parameter replikasi, saya memutuskan untuk mengambilnya, tetapi berapa biayanya untuk mengajar PostgreSQL untuk membaca kembali primary_conninfo di SIGHUP? Segalanya menjadi buruk. Pada prinsipnya, perlu untuk mengubah hanya satu variabel dalam proses startup dan dari sana meminta restart WalReceiver - dan hanya itu, replikasi akan melanjutkan dengan alamat baru dengan benar. Masih menerapkan ini dengan benar. Beberapa minggu kemudian saya menyelesaikan tambalan dengan implementasi membaca kembali recovery.conf pada sinyal SIGHUP, sementara tambalan itu tidak merusak perilaku database yang ada.

Kemudian, dengan keberanian, mengirimnya ke milis pengembang PostgreSQL. Apa yang Michael Paquier jawab dengan agak cepat:

Sebelum menjadikannya sebagai reloadable, mari kita beralih menjadi GUC terlebih dahulu dan tidak menemukan kembali penanganan parameter SIGHUP seperti yang dilakukan patch Anda.

Ups, ternyata saya salah bertanya ke mesin pencari. Pertanyaannya bukan tentang membaca kembali recovery.conf, tetapi tentang konversi parameter dari recovery.conf yang terpisah ke infrastruktur GUC (grand unified configuration) yang digunakan untuk semua parameter DBMS lainnya. Artinya, jelas tidak, kita tidak perlu tambalan seperti itu, kita tidak menginginkan ini. Pertama-tama mari kita transfer semua pengaturan ini dari recovery.conf ke infrastruktur pengaturan standar kami.

Pada berita suram ini, saya terbakar dan berpikir: "Tapi mari kita transfer!". Saya membaca diskusi yang diarsipkan pada permintaan pencarian yang benar, membuka diskusi terakhir yang ditemukan tentang mentransfer pengaturan (tautan disediakan oleh Michael Paquier dalam jawabannya, yang saya berterima kasih padanya secara terpisah, serta atas tanggapan cepatnya). Saat itu, pada Mei 2018, tambalan itu ditinggalkan selama lebih dari setahun. Jadi, di sini kita mulai. Atau lebih tepat mengatakan "lanjutkan"? Menurut rencana hiburan:

1. baca dan daftarkan perubahan pada versi tambalan terbaru yang diterbitkan
2. parsing perubahan dalam tambalan dan transfer yang diperlukan ke versi basis kode saat ini
3. perbaiki semua referensi ke recovery.conf dan parameternya dalam dokumentasi
4. tes perbaikan
5. kirim tambalan baru ke milis
6. dapatkan umpan balik
7. untuk memperbaiki sesuatu sesuai dengan keinginan dan kembali ke paragraf 5
8. untuk menerima penolakan untuk menerima tambalan lagi (dalam satu setengah tahun)

Kedengarannya seperti rencana aksi? Nah, ini dia!

Berapa lama, secara singkat, saya sampai di titik lima dan pada 21 Juni 2018 menerbitkan versi tambalan baru di utas diskusi baru . Kemudian 3 bulan dalam keheningan yang menindas dari keheningan dingin ikan Baskervilles. Pada akhir September, Peter Eisentraut, salah satu pengembang Core dengan hak untuk berkomitmen, tiba-tiba menunjukkan minat pada tambalan itu. Setelah beberapa kali koreksi, sementara saya diam-diam pergi selama beberapa hari untuk berjalan-jalan di Budapest dan melihat pemandangan, sebuah surat yang mengecewakan dari Peter Eisentraut tiba:

Saya pergi ke patch dan melakukan banyak perbaikan kecil. Saya juga memperbarui dokumentasi secara lebih luas. Patch yang terpasang cocok untuk saya.

Yaitu, Peter Eisentraut mengoreksi beberapa hal kecil lagi atas kebijakannya, memperbarui dokumentasinya, sepenuhnya membakar bagian recovery-config.sgml dan percaya bahwa dalam bentuk ini tambalan sudah dapat diterima. Oh, dan saya pikir itu akan terjadi hanya untuk postgresql 13, bahkan jika itu sangat beruntung bahwa tambalan pada umumnya akan mencapai tingkat kesiapan untuk melakukan.

Dan beberapa hari kemudian, yaitu pada tanggal 25 November 2018 ini, Peter Eisentraut benar-benar menerima tambalan ini :

pengaturan recovery.conf sekarang diatur dalam postgresql.conf (atau sumber GUC lainnya). Saat ini, semua pengaturan yang terpengaruh adalah PGC_POSTMASTER; ini bisa disempurnakan dalam kasus per kasus di masa depan.
Pemulihan sekarang dimulai oleh file recovery.signal. Mode siaga dimulai oleh file standby.signal. Pengaturan standby_mode hilang. Jika file recovery.conf ditemukan, kesalahan dikeluarkan.
Pengaturan trigger_file telah diubah namanya menjadi promot_trigger_file sebagai bagian dari langkah tersebut.
Bab dokumentasi "Konfigurasi Pemulihan" telah diintegrasikan ke dalam "Konfigurasi Server".
pg_basebackup -R sekarang menambahkan pengaturan ke postgresql.auto.conf dan membuat file standby.signal.
Penulis: Fujii Masao <masao (dot) fujii (at) gmail (dot) com>
Penulis: Simon Riggs <simon (at) 2ndquadrant (dot) com>
Penulis: Abhijit Menon-Sen <ams (at) 2ndquadrant (dot) com>
Penulis: Sergei Kornilov <sk (at) zsrv (dot) org>

Dua minggu telah berlalu dan komit ini belum dibatalkan. Luar biasa Dan sepertinya mereka bahkan tidak akan melakukannya. Luar biasa. Tidak diketahui apakah komunitas akan memutuskan untuk mengubah perilaku ke arah mana pun lagi, terutama karena masih ada sedikit waktu sebelum fitur membekukan rilis postgresql 12 pada bulan April. Tapi sepertinya kita tidak akan memiliki recovery.conf lagi.

Jadi apa yang berubah?

Pertama dan terutama, DBMS akan menolak untuk memulai jika menemukan file recovery.conf - ini dilakukan secara khusus sehingga pengguna, menggunakan salah satu dari banyak instruksi lama, tidak akan terkejut mengapa database mengabaikan konfigurasi dalam file ini.

Pengaturan standby_mode lama hilang. Sekarang, dan juga fakta keberadaan recovery.conf untuk mengaktifkan mode pemulihan, diganti oleh dua file (konten apa pun, biasanya kosong):

• $ PGDATA / recovery.signal - penerus ideologis standby_mode = off, pemulihan dari arsip akan dilakukan ke titik yang ditentukan dalam konfigurasi;
• $ PGDATA / standby.signal - masing-masing, standby_mode = aktif. Kami akan melihat file ini di semua replika.

Jika proses startup dari database menemukan kedua file, maka kami menganggap bahwa kami berada dalam mode siaga.

Jika, untuk kejelasan, untuk mengurangi perubahan parameter ke piring:

recovery.conf lama	PostgreSQL 12+ postgresql.conf
primary_conninfo	primary_conninfo
primary_slot_name	primary_slot_name
trigger_file	promot_trigger_file
recovery_min_apply_delay	recovery_min_apply_delay
recovery_target	recovery_target
recovery_target_name	recovery_target_name
recovery_target_time	recovery_target_time
recovery_target_xid	recovery_target_xid
recovery_target_lsn	recovery_target_lsn
recovery_target_inclusive	recovery_target_inclusive
recovery_target_timeline	recovery_target_timeline
recovery_target_action	recovery_target_action
restore_command	restore_command
archive_cleanup_command	archive_cleanup_command
recovery_end_command	recovery_end_command

Anda dapat melihat bahwa sedikit kurang dari tidak ada yang berubah. Saat ini (dengan satu-satunya pengecualian awalan promot_ untuk promot_trigger_file), semua parameter baru dinamai sama seperti yang lama dan mengambil nilai yang mungkin sama. Meskipun sebenarnya masih ada perubahan mengenai pengaturan target pemulihan. Saya tidak tahu apakah ada yang menggunakan ini sebelumnya, tetapi itu adalah perilaku yang terdokumentasi dan dimungkinkan untuk menentukan beberapa recovery_target, recovery_target_lsn, recovery_target_name, recovery_target_time atau recovery_target_xid secara bersamaan. Sebagai contoh

recovery_target_lsn = '1/1D9FEA00' recovery_target_xid = '5238954' 

Baris terakhir dari recovery.conf sebenarnya digunakan untuk pemulihan. Ini tidak lagi mungkin, tujuan pemulihan harus ditunjukkan oleh paling banyak satu. Namun, karena logika infrastruktur GUC, Anda masih dapat menentukan parameter dengan nama yang sama beberapa kali:

 recovery_target_lsn = '1/1D9FEA00' recovery_target_lsn = '1/16AC7D0' 

Ini dapat diterima, kami akan dikembalikan ke nilai pengaturan yang ditentukan terakhir.

Dan, secara umum, ini semua yang perlu dikatakan tentang perubahan yang terlihat dari luar PostgreSQL. pg_basebackup -R (--write-recovery-conf) tetap di tempatnya dan melakukan apa yang dimaksudkan, hanya sekarang ia akan menambahkan parameter ke postgresql.auto.conf alih-alih recovery.conf dan membuat file standby.signal

Sayangnya, ketika saya mengatakan bahwa ini semua perubahan yang saat ini terlihat, inilah yang saya maksud. Semua parameter baru masih ditetapkan sebagai PGC_POSTMASTER, yaitu, mereka hanya dapat diubah ketika PostgreSQL dimulai. Seperti yang telah disebutkan, ini adalah persyaratan dari komunitas pengembang: pertama, transfer semua pengaturan, dan baru kemudian lihat apakah mereka dapat diubah pada database yang sedang berjalan. Jadi sekarang PostgreSQL berada dalam tahap perkembangan yang menakjubkan, ketika perilaku lama telah rusak dan perubahan menjadi lebih baik belum dilakukan.

Saya sudah menerbitkan tambalan yang memungkinkan perubahan primary_conninfo dan primary_slot_name dengan cepat. Mari kita lihat apa yang terjadi.

Maaf, saya merusak recovery.conf Anda

UPD 7 April 2019

Di hari terakhir sebelum fitur membekukan versi 12, Anda dapat meringkas. Mengubah pengaturan replikasi tidak termasuk dalam rilis. Tentu saja, ini juga kisah yang aneh. Sekali waktu, Simon Riggs patch yang saya ambil sebagai dasar sudah berisi suntingan untuk me-restart walreceiver ketika mengubah pengaturan koneksi. Saya memilih mereka dalam tambalan terpisah yang dilengkapi dengan dokumentasi dan tes. Dan setelah 6 pembaruan patch dan beberapa bulan diskusi, fakta yang jelas muncul bahwa jika Anda me-restart walreceiver, database akan mencoba untuk beralih untuk mengembalikan file dari restore_command. Perilaku mesin negara yang cukup sederhana, dipicu dengan mematikan walreceiver karena alasan apa pun. Tetapi ini ternyata menjadi "sesuatu yang tidak kita inginkan." Nah, sebelumnya itu tidak mungkin dikatakan? Ok, saya redidkan dalam beberapa cara, tetapi kalender sudah memiliki commitfest terakhir untuk versi 12 dan tidak ada yang melihat di sini. Secara umum, ini bukan hal yang cepat, tambalan di PostgreSQL lakukan. Tetapi saya memiliki hak untuk memasukkan diri saya ke dalam daftar orang, terima kasih kepada siapa REINDEX yang belum selesai yang belum selesai dengan CONCURRENTLY dimasukkan dalam versi 12!

Perlu disebutkan pada akhirnya bahwa sejumlah pengaturan memiliki kesempatan untuk berubah dengan cepat: archive_cleanup_command, promot_trigger_file, recovery_end_command, recovery_min_apply_delay