Fitur Hot Standby baru di PostgreSQL 9.0 yang akan datang memungkinkan menjalankan kueri terhadap node siaga yang sebelumnya tidak melakukan apa pun selain menjalankan proses pemulihan. Dua harapan umum yang saya dengar dari pengguna yang mengantisipasi fitur ini adalah bahwa fitur ini akan memungkinkan mendistribusikan kueri singkat di kedua node, atau memungkinkan menjalankan laporan panjang terhadap standby tanpa menggunakan sumber daya pada master. Keduanya dapat dilakukan saat ini, tetapi kecuali Anda memahami kompromi yang terlibat dalam cara kerja Hot Standby, mungkin ada beberapa perilaku yang tidak terduga di sini.
Kueri Standar yang Berjalan Lama
Salah satu masalah tradisional dalam database yang menggunakan MVCC, seperti PostgreSQL, adalah bahwa kueri yang berjalan lama harus tetap membuka sumber daya—disebut sebagai snapshot dalam implementasi Postgres saat ini—untuk mencegah database menghapus data yang dibutuhkan kueri beroperasi. Misalnya, hanya karena klien lain telah menghapus baris dan melakukan, jika kueri yang sudah berjalan membutuhkan baris itu untuk diselesaikan, Anda belum bisa menghapus blok disk fisik yang terkait dengan baris itu dulu. Anda harus menunggu hingga tidak ada kueri terbuka yang mengharapkan baris tersebut terlihat masih ada.
Batasan Siaga Panas
Jika Anda memiliki kueri lama yang ingin Anda jalankan Hot Standby, ada beberapa jenis hal buruk yang dapat terjadi saat proses pemulihan menerapkan pembaruan. Ini dijelaskan secara rinci dalam Dokumentasi Hot Standby. Beberapa hal buruk ini akan menyebabkan kueri yang berjalan di standby dibatalkan karena alasan yang mungkin tidak jelas secara intuitif:
- Pembaruan PANAS atau pembaruan terkait VAKUM tiba untuk menghapus sesuatu yang menurut kueri akan terlihat
- Penghapusan B-tree muncul
- Ada masalah penguncian antara kueri yang Anda jalankan dan kunci apa yang diperlukan agar pembaruan dapat diproses.
Situasi penguncian sulit untuk ditangani, tetapi kemungkinan besar tidak akan terjadi dalam praktik selama itu jika Anda hanya menjalankan kueri baca-saja di standby, karena itu akan diisolasi melalui MVCC. Dua lainnya tidak sulit untuk dihadapi. Hal dasar yang harus dipahami adalah apa saja UPDATE atau DELETE pada master dapat menyebabkan interupsi permintaan apa pun pada standby; tidak masalah jika perubahan tersebut terkait dengan apa yang dilakukan kueri.
Bagus, cepat, murah:pilih dua
Pada dasarnya, ada tiga hal yang mungkin ingin diprioritaskan orang:
- Hindari pembatasan master:Izinkan xids dan snapshot terkait untuk maju tanpa batas pada master, sehingga VACUUM dan pembersihan serupa tidak terhambat oleh apa yang dilakukan standby
- Kueri tak terbatas:Jalankan kueri di standby untuk jangka waktu yang berubah-ubah
- Pemulihan saat ini:Tetap perbarui proses pemulihan di standby dengan apa yang terjadi pada master, memungkinkan fail-over cepat untuk HA
Dalam situasi apa pun dengan Hot Standby, benar-benar tidak mungkin untuk memiliki ketiganya sekaligus. Anda hanya dapat memilih trade-off Anda. Parameter merdu yang tersedia memungkinkan Anda mengoptimalkan beberapa cara:
- Menonaktifkan semua setelan penundaan/penundaan ini akan mengoptimalkan pemulihan saat ini, tetapi kemudian Anda akan menemukan bahwa kueri lebih cenderung dibatalkan daripada yang Anda harapkan.
- max_standby_delay mengoptimalkan untuk kueri yang lebih panjang, dengan mengorbankan pemulihan saat ini. Penundaan ini menerapkan pembaruan ke standby setelah salah satu yang akan menyebabkan masalah (PANAS, VACUUM, penghapusan B-tree, dll.) muncul.
- vacuum_defer_cleanup_age dan beberapa peretasan snapshot dapat memperkenalkan beberapa batasan master untuk memperbaiki dua masalah lainnya, tetapi dengan UI yang lemah untuk melakukan itu. vacuum_defer_cleanup_age dalam satuan ID transaksi. Anda perlu memiliki beberapa gagasan tentang jumlah rata-rata churn xid pada sistem Anda per unit waktu untuk mengubah cara orang berpikir tentang masalah ini ("tunda setidaknya 1 jam sehingga laporan saya akan berjalan") menjadi pengaturan untuk nilai ini. tingkat konsumsi xid bukanlah hal yang umum atau bahkan wajar untuk diukur/diprediksi. Sebagai alternatif, Anda dapat membuka snapshot di primer sebelum memulai kueri yang berjalan lama di standby. dblink disarankan dalam dokumentasi Hot Standby sebagai cara untuk mencapainya. Secara teoritis daemon di standby dapat ditulis di user-land, tinggal di primer, untuk mengatasi masalah ini juga (Simon memiliki desain dasar untuk satu). Pada dasarnya, Anda memulai serangkaian proses yang masing-masing memperoleh snapshot dan kemudian tidur selama beberapa waktu sebelum melepaskannya. Dengan menentukan berapa lama mereka masing-masing tidur, Anda dapat memastikan snapshot xid tidak pernah maju terlalu cepat pada master. Seharusnya sudah terdengar jelas betapa mengerikan peretasan ini.
Peningkatan Potensial
Satu-satunya yang benar-benar dapat Anda lakukan dengan bersih adalah mengencangkan dan meningkatkan UI untuk pembatasan master. Itu mengubah ini menjadi masalah tradisional yang sudah ada dalam database:kueri yang sudah berjalan lama menahan snapshot terbuka (atau setidaknya membatasi kemajuan ID transaksi terkait visibilitas) pada master, mencegah master menghapus hal-hal yang diperlukan untuk kueri itu. menyelesaikan. Anda mungkin secara bergantian menganggap ini sebagai penyetelan otomatis vacuum_defer_cleanup_age.
Pertanyaannya adalah bagaimana membuat utama hormati kebutuhan kueri yang berjalan lama di siaga . Ini mungkin terjadi jika informasi lebih lanjut tentang persyaratan visibilitas transaksi dari standby dibagikan dengan master. Melakukan pertukaran semacam itu benar-benar akan menjadi sesuatu yang lebih tepat untuk dibagikan oleh implementasi Replikasi Streaming baru. Cara server Hot Standby sederhana disediakan tidak memberikan umpan balik apa pun terhadap master yang cocok untuk pertukaran data ini, selain pendekatan seperti peretasan dblink yang telah disebutkan.
Dengan PostgreSQL 9.0 yang baru mencapai rilis alfa keempat, mungkin ada masih ada waktu untuk melihat beberapa peningkatan di area ini sebelum rilis 9.0. Akan menyenangkan untuk melihat Hot Standby dan Replikasi Streaming benar-benar terintegrasi bersama dengan cara yang menyelesaikan hal-hal yang tidak dapat dilakukan oleh keduanya sendiri sebelum pengkodean pada rilis ini benar-benar terhenti.
