Apakah produksi replikasi PostgreSQL siap?


16

Bagaimana replikasi asli PostgreSQL dibandingkan dengan MySQL?

Saya tahu replikasi asinkron telah didukung lebih dari sinkronisasi, yang baru-baru ini. Apakah sinkron dapat diandalkan untuk digunakan dalam proyek nyata?

Jawaban:


31

Produksi siap?

Ya, sudah siap produksi dan banyak digunakan. Pengikut Heroku didasarkan pada replikasi async bawaan PostgreSQL misalnya, seperti halnya AWS RDS standbys dan membaca replika. Replikasi streaming digunakan hampir secara universal dengan PostgreSQL.

Pengaturan replikasi tidak terlalu bagus, tetapi alat seperti repmgr sedikit membantu dengan itu, dan itu membaik perlahan dengan setiap rilis utama. Kemampuan pg_basebackup untuk mengambil salinan sistem menggunakan replikasi streaming (dan melakukannya dari standby lain) sangat membantu.

Secara umum, fitur tidak akan dirilis di PostgreSQL sampai produksinya siap. Bug terjadi, seperti pada perangkat lunak apa pun, tetapi biasanya diperbaiki segera setelah diidentifikasi. Fitur-fitur baru yang benar-benar besar terkadang memiliki bug dan masalah yang ditemukan setelah rilis .0, tetapi jika memperbaikinya adalah prioritas tinggi; bug tidak hanya tersisa.

Saya tidak mengetahui adanya masalah serius dengan replikasi streaming - sinkronisasi atau async - juga saya tidak melihat ada yang dilaporkan cukup lama. Mereka kurang stabil dari standar Pg dalam rilis .0 versi utama yang mereka perkenalkan, tetapi keduanya matang dengan cepat dan sepenuhnya siap diproduksi.

(Pembaruan: Ada bug khusus di versi 9.3 baru sebelum 9.3.4 yang memang menyebabkan masalah replikasi dalam beberapa kasus; pengguna 9.3 harus segera memperbarui ke 9.3.4. Versi yang lebih lama tidak terpengaruh.)

Satu-satunya peringatan yang ingin saya sebutkan adalah detail kecil dengan replikasi sinkron: Jika Anda komit pada master, maka batalkan kueri setelah melakukan sementara menunggu replika untuk mengkonfirmasi, itu diperlakukan sebagai komit pada master bahkan sebelum itu direplikasi. Anda mendapatkan efek yang sama dengan me-restart master sambil menunggu replika untuk membalas. Dalam praktiknya ini tidak relevan, tetapi ini satu-satunya masalah yang bisa saya pikirkan.

Bandingkan dengan MySQL?

Replikasi asli Pg sangat berbeda dengan MySQL.

MySQL menggunakan replikasi logis di mana ia mengirimkan perubahan logis yang dibuat untuk data tabel, struktur tabel, dll, dan replika menerapkan perubahan itu.

Replikasi PostgreSQL adalah level yang lebih rendah (di 9,5 dan di bawah; versi masa depan juga dapat menambahkan replikasi logis). Mengirim blok yang berubah dalam tabel. Lebih sederhana, lebih mudah untuk mendapatkan yang benar, dan memaksakan beban yang lebih rendah pada server replika, tetapi mengkonsumsi lebih banyak bandwidth jaringan dan membutuhkan lebih banyak penyimpanan pada master untuk menahan perubahan yang belum direplikasi. Paling baik dikonfigurasi untuk menggunakan replikasi streaming dengan fallback pengarsipan WAL, membuatnya lebih kompleks untuk dikonfigurasi daripada MySQL. Ini mereplikasi perubahan tingkat rendah seperti aktivitas VACUUM, bukan hanya tuple perubahan, menjaga status di disk dari replika sama seperti master. Itu tidak mampu mereplikasi hanya satu database; keseluruhan sistem harus direplikasi, yang bisa membuat frustasi jika Anda memiliki satu database besar, churn tinggi dan tidak penting dan satu database kecil, churn rendah dan vital.

Secara keseluruhan, itu tergantung pada apa yang ingin Anda lakukan dengannya.

Saya melihat replikasi PostgreSQL sebagai jauh lebih baik untuk replika yang digunakan untuk cadangan, ketersediaan tinggi dan pemulihan bencana. Terutama jika dikombinasikan dengan point in time recovery (PITR) .

Di sisi lain, itu tidak baik untuk replika pelaporan read-only karena kebutuhan untuk menunda aplikasi data yang direplikasi saat menjalankan transaksi lama berarti Anda harus membiarkannya membatalkan permintaan yang berjalan sangat lama atau jauh di belakang master, mengkonsumsi lebih banyak ruang disk pada master dan memaksanya bekerja lebih keras untuk mengikuti.

Ada pekerjaan yang sedang berlangsung untuk mengaktifkan replikasi logis di PostgreSQL , di mana perubahan logis pada struktur tabel, isi tabel, dll direplikasi, daripada keadaan di-disk. Desain katalog Pg dan dukungan untuk segala sesuatu yang ditentukan pengguna menjadikan ini tugas yang cukup kompleks. Beberapa dasar telah diterapkan untuk 9,4, tetapi replikasi logis penuh tidak mungkin dapat digunakan sebelum 9,6 atau lebih baru.


Jawaban yang bagus untuk pertanyaan saya juga. Terima kasih Craig.
swasheck

6
Ada satu hal tentang rep sinkronisasi yang mengejutkan beberapa pengguna, tetapi benar-benar masuk akal jika Anda memikirkannya: komit transaksi yang tunduk pada replikasi sinkron tidak akan kembali sampai transaksi telah bertahan pada setidaknya satu klaster di samping master . Orang-orang yang datang dari beberapa sistem lain merasa bahwa hal itu seharusnya terjadi kecuali upaya replikasi terlalu lama , yang berarti "itu sinkron kecuali tidak," yang bukan jaminan yang dapat diterima oleh komunitas PostgreSQL. Gunakan beberapa target sinkronisasi untuk menghindari kemacetan jika replika gagal, atau gunakan asinkron.
kgrittn

1
@ kgrittn Poin bagus adalah beberapa target. Saya agak ngeri bahwa ada yang ingin / mengharapkan komitmen untuk kembali sebelum transaksi direplikasi dalam replikasi sinkron ; Kedengarannya mereka benar-benar ingin replikasi async dengan batas celah pengikut maksimum yang berhenti menulis pada master sampai pengikut cukup mengejar? Suatu hal yang sangat masuk akal untuk diinginkan, tetapi tidak menyelaraskan rep.
Craig Ringer

1
@CraigRinger: Apa yang saya lihat orang minta tidak seperti yang Anda nyatakan, mereka kadang-kadang meminta "Gunakan rep sinkronisasi tetapi secara otomatis kembali ke rep async jika sinkronisasi terlalu lama." Jadi mereka tidak ingin menjeda master jika itu jatuh terlalu jauh di belakang replika - itulah tepatnya di mana mereka ingin itu mengkonfirmasi komitmen dengan cepat , tanpa menulis ke situs lain. Bagi saya itu kedengarannya seperti kasus menjanjikan lebih dari yang disampaikan. Mereka ingin di muka "Ya, Anda memiliki rep sinkronisasi; Anda aman." dan setelah crash, "Data komitmen itu hilang; itu tidak benar-benar ditulis di tempat lain."
kgrittn

@CraigRinger mungkin memperbaruinya dengan pg10 / logis?
Evan Carroll
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.