Pertanyaan PostgreSQL ERROR: membatalkan pernyataan karena konflik dengan pemulihan


Saya mendapatkan kesalahan berikut saat menjalankan kueri pada db PostgreSQL dalam mode siaga. Kueri yang menyebabkan kesalahan berfungsi dengan baik selama 1 bulan tetapi ketika Anda meminta lebih dari 1 bulan, hasil kesalahan.

ERROR: canceling statement due to conflict with recovery
Detail: User query might have needed to see row versions that must be removed

Ada saran tentang cara mengatasinya? Terima kasih


76
2018-01-29 21:15


asal


Jawaban:


Menjalankan kueri di server hot-standby agak sulit - ini dapat gagal, karena selama kueri beberapa baris yang diperlukan mungkin diperbarui atau dihapus pada primer. Sebagai primer tidak tahu bahwa permintaan dimulai pada sekunder yang dianggapnya dapat membersihkan (vakum) versi lama dari barisnya. Kemudian sekunder harus memutar ulang pembersihan ini, dan harus membatalkan semua kueri secara paksa yang dapat menggunakan baris ini.

Kueri yang lebih lama akan dibatalkan lebih sering.

Anda dapat mengatasi ini dengan memulai transaksi baca berulang pada primer yang melakukan kueri dummy dan kemudian diam saat kueri real dijalankan pada sekunder. Kehadirannya akan mencegah penyedotan versi baris lama pada primer.

Lebih lanjut tentang hal ini dan penyelesaian lainnya dijelaskan di Hot Standby - Menangani Konflik Permintaan bagian dalam dokumentasi.


48
2018-01-29 23:51



Tidak perlu memulai transaksi tidak aktif di master. Dalam postgresql-9.1 itu cara paling langsung untuk memecahkan masalah ini adalah dengan pengaturan

hot_standby_feedback = on

Ini akan membuat master menyadari kueri yang berjalan lama. Dari dokumen:

Opsi pertama adalah mengatur parameter hot_standby_feedback, yang mencegah   VACUUM dari menghapus baris yang baru saja mati dan jadi konflik pembersihan tidak terjadi.

Mengapa ini bukan standarnya? Parameter ini ditambahkan setelah awal Implementasi dan itu satu-satunya cara agar seorang standby dapat mempengaruhi seorang master.


56
2018-02-10 19:34



Sebagaimana dinyatakan sini tentang hot_standby_feedback = on :

Nah, kerugiannya adalah bahwa siaga dapat mengasapi tuannya,   yang mungkin mengejutkan bagi sebagian orang juga

Dan sini:

Dengan pengaturan apa max_standby_streaming_delay? aku lebih memilih   default itu untuk -1 dari default hot_standby_feedback. Dengan cara itu   yang Anda lakukan saat siaga hanya mempengaruhi siaga


Jadi saya menambahkan

max_standby_streaming_delay = -1

Dan tidak lagi pg_dump kesalahan bagi kami, atau tuan kembung :)


37
2017-10-22 13:58



Tidak perlu disentuh hot_standby_feedback. Seperti yang telah disebutkan orang lain, mengaturnya on bisa mengasah guru. Bayangkan membuka transaksi pada budak dan tidak menutupnya.

Sebaliknya, atur max_standby_archive_delay dan max_standby_streaming_delay untuk beberapa nilai waras:

# /etc/postgresql/10/main/postgresql.conf on a slave
max_standby_archive_delay = 900s
max_standby_streaming_delay = 900s

Dengan cara ini permintaan pada budak dengan durasi kurang dari 900 detik tidak akan dibatalkan. Jika beban kerja Anda memerlukan kueri yang lebih lama, cukup setel opsi ini ke nilai yang lebih tinggi.


15
2017-12-05 19:33



Data tabel pada server slave siaga panas dimodifikasi sementara permintaan berjalan lama berjalan. Solusi (PostgreSQL 9.1+) untuk memastikan data tabel tidak diubah adalah untuk menangguhkan replikasi dan melanjutkan setelah kueri:

select pg_xlog_replay_pause(); -- suspend
select * from foo; -- your query
select pg_xlog_replay_resume(); --resume

4
2017-10-05 08:56