"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 .