Ketersediaan Tinggi untuk postgresql

Saya baru dalam database PostgreSQL. Baru-baru ini pengembang kami perlu melakukan beberapa peningkatan dalam sistem kami.

Karena itu kami berencana untuk mengimplementasikan beberapa metode untuk mengimplementasikan failover database.

Berdasarkan bacaan saya dari wiki postgresql di sini , kami mencoba menerapkan siaga hangat atau siaga panas. Jadi pertanyaan saya adalah:

Apa perbedaan utama di antara mereka?
Mana yang lebih baik?
Apakah ada metode lain yang dapat kita pertimbangkan untuk membuat ketersediaan tinggi di database Postgres kita?

postgresql linux high-availability

— pengguna119720
sumber

Pengaturan detak jantung + STONITH yang tepat adalah kunci jika Anda berencana untuk menggunakan failover otomatis. Kegagalan otomatis dengan pemicu manual mungkin lebih aman. Lihat juga wiki.postgresql.org/wiki/High_Availility

— Craig Ringer

@CraigRinger terima kasih. Saya akan memeriksa itu. Tapi apa sebenarnya siaga hangat dan panas? Bisakah Anda memberikan beberapa detail?

— user119720

Jawaban:

1a. Siaga hangat adalah "langsung", cadangan tambahan yang ditambahkan dengan blok perubahan lengkap (segmen wal) masing-masing 16 mb, yang dikirim ke simpul siaga begitu terisi. Anda tidak dapat meminta node siaga hangat. Perubahan 16 mb (secara default) dapat berarti banyak transaksi, jika master gagal, mereka akan hilang.

1b. Siaga Panas . (juga cadangan inkremental "langsung"). Perubahan kecil dikirim ke slave (catatan wal, yang merupakan bagian kecil dari segmen wal). Anda dapat meminta (baca saja) node siaga panas. Jendela untuk transaksi yang hilang jika master gagal sangat kecil. Ada hot siaga node sinkron dan asinkron, node sinkron akan memaksa master untuk menunggu untuk mengkonfirmasi aplikasi perubahan dan kemudian master akan melakukan transaksi. Dalam replikasi asinkron master mengirim catatan wal dan tidak menunggu konfirmasi . Yang pertama membutuhkan tautan yang sangat andal dan cepat antara master dan slave, juga menambahkan overhead ke master tetapi tidak menjamin kehilangan data.

Mengenai cadangan tambahan: 1. Anda mengambil salinan dasar dari seluruh instalasi basis data Anda. 2. Kirimkan ke budak. 3. Konfigurasikan untuk mengejar perubahan.

Replikasi Streaming (siaga panas) adalah pemenangnya di sini. Saya pribadi lebih suka replikasi asinkron karena tidak membebani master dan lag replikasi sangat kecil (beberapa detik dalam banyak kasus)

Satu pelengkap untuk pengaturan ini adalah pg-pool. Ini bertindak sebagai proksi antara aplikasi dan server yang berpartisipasi dalam konfigurasi replikasi seperti yang dijelaskan di atas, ia memiliki load balancing dan kemampuan permintaan paralel. Itu juga dapat memberikan failover otomatis. http://www.pgpool.net/pgpool-web/contrib_docs/simple_sr_setting/index.html

— Rene Romero Benavides
sumber

Saya sangat menghargai balasan cepat Anda yang sangat membantu persyaratan saya. Dapatkah Anda juga merekomendasikan saya tautan yang tepat untuk mencapai pengaturan ini?

— user119720

tentu, lihat di sini: [tautan] pgpool.net/pgpool-web/contrib_docs/simple_sr_setting/index.html

— Rene Romero Benavides

Sama-sama. Kurva pembelajaran dalam hal ini agak curam, bersabarlah. Selamat malam (siang atau apapun) salam dari Mexico City.

— Rene Romero Benavides

Saya telah melakukan riset berdasarkan tautan Anda dan ada pertanyaan yang muncul di benak saya. 1. Apakah siaga hangat dapat dikonfigurasikan untuk replikasi streaming? 2. Apakah pg-pool dapat dikonfigurasi untuk siaga hangat? 3. Jika kita telah mengonfigurasi server aplikasi kita mengarah ke basis data utama kita selama failover, apakah kita perlu mengubah konfigurasi basis data server aplikasi menjadi basis data budak atau pg-pool itu sendiri akan bertindak sebagai proksi ke budak? Maaf atas masalahnya. Semoga Anda tidak keberatan.

— user119720

Jawaban yang sudah Anda dapatkan sangat berguna tetapi sedikit membingungkan di sini. Semua solusi replikasi built-in menggunakan mekanisme dasar yang sama: menyalin data log write-ahead ke server siaga.

Anda dapat memindahkan data WAL untuk replikasi baik file 16MB sekaligus, menggunakan fasilitas archive_command, atau menggunakan Streaming Replication (SR). Jika menggunakan SR, Anda benar-benar harus mengatur pengarsipan juga, dan server akan beralih di antara mereka yang sesuai.

Anda dapat memiliki server siaga yang hangat, yang tidak dapat menjawab pertanyaan. Atau Anda dapat memiliki server siaga yang panas, yang dapat menjawab yang hanya baca. Ini tidak terkait dengan bagaimana data masuk ke siaga.

Masing-masing dari dua pilihan ini bergabung dengan yang lainnya, dan Anda dapat memiliki keempat kombinasi. Anda dapat memiliki permintaan Siaga Hot saat menjawab sedang diumpankan dengan file pada saat segmen WAL. Anda dapat memiliki server Replikasi Streaming yang tidak mengaktifkan Hot Standby, sehingga tidak akan menjawab pertanyaan. Hanya saja kasus yang paling umum, saat ini, adalah Replikasi Streaming plus Siaga Panas. Itu set fitur lengkap. Sekali lagi, jangan abaikan mekanisme archive_command yang lama hanya karena itu mungkin untuk dihindari sekarang. Itu masih bisa menyelamatkan Anda dari kegagalan streaming yang sulit untuk dipulihkan.

— Greg Smith
sumber