voretaq7 's jawabannya mencakup poin-poin penting, termasuk cara yang benar untuk mengakhiri backends tapi saya ingin menambahkan sedikit penjelasan lebih.
kill -9
(Yaitu SIGKILL
) seharusnya tidak pernah, menjadi default pilihan pertama Anda . Ini harus menjadi pilihan terakhir Anda ketika proses tidak menanggapi permintaan penutupan normal dan a SIGTERM
( kill -15
) tidak berpengaruh. Itu berlaku untuk Pg dan hampir semuanya.
kill -9
memberi proses membunuh tidak ada kesempatan untuk melakukan pembersihan sama sekali.
Ketika datang ke PostgreSQL, Pg melihat cadangan yang diakhiri oleh kill -9
sebagai macet yang didukung . Ia tahu bahwa backend mungkin telah merusak memori bersama - karena Anda bisa menginterupsi setengah jalan dengan menulis halaman ke shm atau memodifikasi satu, misalnya - jadi itu mengakhiri dan me-restart semua backend lainnya ketika mengetahui bahwa backend tiba-tiba menghilang dan keluar dengan kode kesalahan non-nol.
Anda akan melihat ini dilaporkan dalam log.
Jika tampaknya tidak ada salahnya, itu karena Pg me-restart semuanya setelah crash dan aplikasi Anda pulih dari koneksi yang hilang dengan bersih. Itu tidak membuatnya menjadi ide yang bagus. Jika tidak ada crash backend yang kurang teruji dengan baik daripada bagian Pg yang berfungsi normal dan jauh lebih rumit / bervariasi, sehingga kemungkinan bug yang bersembunyi dalam penanganan crash backend dan pemulihan lebih tinggi.
BTW, jika Anda kill -9
kepala kantor kemudian menghapus postmaster.pid
dan mulai lagi tanpa memastikan setiap postgres
backend hilang, hal-hal yang sangat buruk dapat terjadi . Ini dapat dengan mudah terjadi jika Anda secara tidak sengaja membunuh kepala kantor alih-alih backend, melihat database telah turun, mencoba me-restart itu, menghapus file .pid "basi" ketika restart gagal, dan mencoba untuk me-restart lagi. Itulah salah satu alasan Anda harus menghindari melambaikan kill -9
Pg, dan tidak boleh menghapus postmaster.pid
.
Demonstrasi:
Untuk melihat apa yang terjadi ketika Anda kill -9
menjadi backend, coba langkah-langkah sederhana ini. Buka dua terminal, buka psql di masing-masing, dan di setiap jalankan SELECT pg_backend_pid();
. Di terminal lain kill -9
salah satu PID. Sekarang jalankan SELECT pg_backend_pid();
di kedua sesi psql lagi. Perhatikan bagaimana mereka berdua kehilangan koneksi?
Sesi 1, yang kami bunuh:
$ psql regress
psql (9.1.4)
Type "help" for help.
regress=# select pg_backend_pid();
pg_backend_pid
----------------
6357
(1 row)
[kill -9 of session one happens at this point]
regress=# select pg_backend_pid();
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.
regress=# select pg_backend_pid();
pg_backend_pid
----------------
6463
(1 row)
Sesi 2, yang merupakan kerusakan jaminan:
$ psql regress
psql (9.1.4)
Type "help" for help.
regress=# select pg_backend_pid();
pg_backend_pid
----------------
6283
(1 row)
[kill -9 of session one happens at this point]
regress=# select pg_backend_pid();
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and repeat your command.
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.
regress=# select pg_backend_pid();
pg_backend_pid
----------------
6464
(1 row)
Lihat bagaimana kedua sesi rusak? Itu sebabnya Anda bukan kill -9
backend.