Streaming PostgreSQL versus replikasi berbasis file (Dalam hal perilaku & konfigurasi server)

Saya mencoba memahami penggunaan terbaik dari replikasi PostgreSQL dan bagaimana cara kerjanya sehingga saya dapat memecahkan masalah di lingkungan produksi.

Saya mengalami kesulitan memahami perbedaan antara 2 jenis replikasi ini dalam hal (1) Konfigurasi (2) Bagaimana kinerja 2 server Master / Slave dalam setiap skenario

Replikasi pada PostgreSQL (9.2+) pada dasarnya adalah file XLOG berukuran 16MB (tergantung pada pengaturan frekuensi untuk membuat setiap file) sedang dibuat pada Master dan dikirim dengan beberapa metode ke Slave.

Pengaturan Saya (untuk keperluan pertanyaan ini)

Konfigurasi Postgresql.conf pada Master
archive_command = 'rsync -av% p postgres @ [SlaveIP]: [wal_archive_folder] /% f'

Konfigurasi Recovery.conf pada Slave untuk membaca file log
restore_command = 'cp [wal_archive_folder] /% f \ "% p \"'
primary_conninfo = 'host = [MasterIP] port = 5432 pengguna = postgres'

Pertanyaan saya adalah bagian apa dari konfigurasi ini yang membuat replikasi "streaming" ini versus "pengiriman log"? Master saya dikonfigurasi untuk menggunakan rsync untuk mengirim log ke slave (apakah ini pengiriman log?) Slave saya dikonfigurasi untuk dapat terhubung ke master dalam recovery.conf (apakah ini streaming?)

Bagian kedua dari pertanyaan: Apa yang terjadi? Saya mengerti ada protokol lain pada PostgreSQL via WAL_sender & WAL_receiver. Tetapi saya tidak jelas apakah ini digunakan untuk streaming saja dan jika demikian, bagaimana rsync digunakan dalam Master?

:) Terima kasih!! Dan maaf jika ini pertanyaan yang jelas. Saya telah melakukan banyak membaca blog / buku tetapi mengalami kesulitan memahami. Postgres wiki sangat mendalam sehingga butuh waktu lama untuk menyelesaikan semuanya (dan saya punya tenggat waktu)

"Streaming replikasi" mengacu pada pengiriman terus-menerus catatan WAL melalui koneksi TCP / IP antara master dan replika, menggunakan protokol walsender melalui replicationkoneksi. Master membaca WAL sendiri pg_xlogdan mengirimkannya ke replika sesuai permintaan. Ini dikonfigurasikan dengan primary_conninfoarahan recovery.confdan pg_hba.confentri pada master untuk mengizinkan replicationkoneksi. Anda juga perlu wal_keep_segmentsdan beberapa opsi lain yang tercakup dalam dokumen.

"Pengiriman log" mengacu pada pengiriman catatan WAL secara berkala sebagai seluruh arsip WAL melalui protokol transfer file ke lokasi arsip tempat replika kemudian dapat mengambilnya. Ini dikonfigurasi dengan restore_commandarahan di recovery.confdan archive_commanddi master. PostgreSQL tidak peduli di mana file-file itu atau bagaimana mereka ditransfer, hanya saja archive_commandmenempatkannya di sana dan restore_commandmengambil arsip yang diperlukan; ini memungkinkan pembangunan sistem seperti PgBarman dan WAL-E.

Replikasi streaming tidak memiliki banyak lag, karena catatan dikirim saat dihasilkan. Namun, diperlukan master dan replika untuk online dan dapat berkomunikasi secara langsung. Ini juga membutuhkan replika untuk menjaga dengan cukup baik sehingga master masih memiliki salinan WAL pada salinan kebutuhan WAL, dan umumnya mengharuskan Anda untuk menghabiskan pg_xlogruang ekstra untuk mempertahankan WAL tambahan untuk replika.

Replikasi pengiriman log memiliki lebih banyak lag karena replika hanya melihat WAL setelah seluruh arsip dikirim. Namun, ini dapat bekerja bahkan ketika master dan replika tidak dapat berkomunikasi secara langsung melalui TCP / IP dengan menggunakan lokasi penyimpanan bersama. Itu terus bekerja bahkan jika replika turun untuk sementara waktu, karena master akan membuang WAL pg_xloghanya setelah pengarsipan, sehingga WAL masih dalam arsip dan dapat digunakan oleh replika meskipun master tidak dapat mengirimnya dengan streaming lagi. Catatan yang archive_commandtidak pernah menyerah, jadi pg_xlogbisa mengisi jika pengarsipan gagal; untuk alasan itu lebih baik mengarsipkan ke lokasi yang dapat diandalkan dan kemudian mengambil server replika dari lokasi itu.

Secara umum Anda benar-benar menggabungkan keduanya, yaitu menggunakan keduanya. Dalam hal itu, replikasi streaming akan digunakan ketika semuanya berjalan dengan baik. Jika replika terlalu jauh di belakang dan master telah membuang xlog yang dibutuhkannya, masalah konektivitas muncul, dll, maka replika akan beralih ke membaca WAL yang diarsipkan sampai tertangkap. Ini akan secara berkala mencoba kembali beralih ke streaming sampai berhasil.

Jika Anda hanya akan menggunakannya, gunakan pengiriman log, karena replikasi streaming tanpa fallback pengiriman log (hingga PostgreSQL 9.4) berpotensi rawan penundaan replikasi yang menyebabkan kegagalan yang memaksa replika untuk dibangun kembali.

PostgreSQL 9.4 sedikit mengubah ini, karena streaming replikasi sekarang dapat menggunakan "slot replikasi". Itu memungkinkan master melacak berapa banyak WAL yang dibutuhkan replika, dan menghindari membuangnya sampai replika mengulangnya. Jadi tidak perlu lagi wal_keep_segmentsjika Anda menggunakan slot replikasi (bukan default).

Lihat slot replikasi streaming artikel saya di PostgreSQL 9.4 .

9.4 juga memperkenalkan dasar untuk streaming replikasi logis , yang merupakan mekanisme lain , yang dirancang untuk digunakan oleh sistem replikasi logis seperti Londiste, Slony-I, dan fitur replikasi multi-master multi-master async bi-directional baru .