Perbedaan antara Replikasi Aliran dan replikasi logis

TL;DR :Replikasi logis mengirimkan perubahan baris demi baris, replikasi fisik mengirimkan perubahan blok disk. Replikasi logis lebih baik untuk beberapa tugas, replikasi fisik untuk yang lain.

Perhatikan bahwa di PostgreSQL 12 (saat ini pada saat pembaruan) replikasi logis stabil dan dapat diandalkan, tetapi cukup terbatas. Gunakan replikasi fisik jika Anda menanyakan pertanyaan ini.

Replikasi streaming bisa replikasi logis. Semuanya agak rumit.

Pengiriman WAL vs streaming

Ada dua cara utama untuk mengirim data dari master ke replika di PostgreSQL:

pengiriman WAL atau pengarsipan berkelanjutan , di mana masing-masing file write-ahead-log disalin dari pg_xlog oleh archive_command berjalan pada master ke beberapa lokasi lain. Sebuah restore_command dikonfigurasi di recovery.conf replika berjalan pada replika untuk mengambil arsip sehingga replika dapat memutar ulang WAL.

Inilah yang digunakan untuk replikasi point-in-time (PITR), yang digunakan sebagai metode pencadangan berkelanjutan.

Tidak diperlukan koneksi jaringan langsung ke server master. Replikasi dapat memiliki penundaan yang lama, terutama tanpa archive_timeout mengatur. Pengiriman WAL tidak dapat digunakan untuk replikasi sinkron.
replikasi streaming , di mana setiap perubahan dikirim ke satu atau beberapa server replika langsung melalui koneksi TCP/IP saat itu terjadi. Replika harus memiliki koneksi jaringan langsung yang dikonfigurasi master di recovery.conf primary_conninfo pilihan.

Replikasi streaming memiliki sedikit atau tidak ada penundaan selama replika cukup cepat untuk mengikutinya. Ini dapat digunakan untuk replikasi sinkron . Anda tidak dapat menggunakan replikasi streaming untuk PITR sehingga tidak banyak digunakan untuk pencadangan berkelanjutan. Jika Anda menjatuhkan meja di master, oops, itu juga jatuh di replika.

Dengan demikian, kedua metode tersebut memiliki tujuan yang berbeda.

Streaming asinkron vs sinkron

Selain itu, ada sinkron dan asinkron replikasi streaming:

Dalam replikasi streaming asinkron replika diizinkan untuk tertinggal di belakang master pada saat master lebih cepat/sibuk. Jika master mogok, Anda mungkin kehilangan data yang belum direplikasi.

Jika replika asinkron berada terlalu jauh di belakang master, master mungkin membuang informasi yang dibutuhkan replika jika max_wal_size (sebelumnya disebut wal_keep_segments) is too low and no slot is used, meaning you have to re-create the replica from scratch. Or the master's . master pg_wal(was pg_xlog) mungkin mengisi dan menghentikan master dari bekerja sampai ruang disk dibebaskan jika max_wal_size terlalu tinggi atau slot digunakan.
Dalam replikasi sinkron master tidak selesai melakukan sampai replika telah mengkonfirmasi menerima transaksi. Anda tidak pernah kehilangan data jika master crash dan Anda harus gagal ke replika. Master tidak akan pernah membuang data yang dibutuhkan replika atau mengisi xlognya dan kehabisan ruang disk karena penundaan replika. Sebagai gantinya, ini dapat menyebabkan master melambat atau bahkan berhenti bekerja jika replika mengalami masalah, dan selalu berdampak pada kinerja master karena latensi jaringan.

Ketika ada beberapa replika, hanya satu yang sinkron pada satu waktu. Lihat synchronous_standby_names .

Anda tidak dapat memiliki pengiriman log sinkron.

Anda sebenarnya dapat menggabungkan pengiriman log dan replikasi asinkron untuk melindungi dari keharusan membuat ulang replika jika tertinggal terlalu jauh, tanpa risiko memengaruhi master. Ini adalah konfigurasi ideal untuk banyak penerapan, dikombinasikan dengan pemantauan seberapa jauh replika berada di belakang master untuk memastikannya berada dalam batas pemulihan bencana yang dapat diterima.

Logis vs fisik

Di atas itu kami memiliki logis vs fisik replikasi streaming, seperti yang diperkenalkan di PostgreSQL 9.4:

Dalam replikasi streaming fisik perubahan dikirim pada hampir level blok disk, seperti "pada offset 14 halaman disk 18 relasi 12311, tulis tuple dengan nilai hex 0x2342beef1222....".

Replikasi fisik mengirimkan segalanya :isi setiap database dalam instalasi PostgreSQL, semua tabel di setiap database. Ia mengirimkan entri indeks, ia mengirimkan seluruh data tabel baru ketika Anda VACUUM FULL , ia mengirimkan data untuk transaksi yang dibatalkan, dll. Sehingga menghasilkan banyak "noise" dan mengirimkan banyak data berlebih. Ini juga membutuhkan replika yang benar-benar identik, jadi Anda tidak dapat melakukan apa pun yang memerlukan transaksi, seperti membuat tabel sementara atau tidak masuk log. Mengkueri replika akan menunda replikasi, sehingga kueri yang lama pada replika harus dibatalkan.

Sebagai gantinya, mudah dan efisien untuk menerapkan perubahan pada replika, dan replikanya sama persis dengan masternya. DDL direplikasi secara transparan, sama seperti yang lainnya, sehingga tidak memerlukan penanganan khusus. Itu juga dapat mengalirkan transaksi besar saat terjadi, jadi ada sedikit penundaan antara komit pada master dan komit pada replika bahkan untuk perubahan besar.

Replikasi fisik sudah matang, teruji dengan baik, dan diadopsi secara luas.

replikasi streaming logis , baru di 9.4, mengirimkan perubahan pada tingkat yang lebih tinggi, dan jauh lebih selektif.

Ini hanya mereplikasi satu database pada satu waktu. Ia hanya mengirimkan perubahan baris dan hanya untuk transaksi yang dilakukan, dan tidak harus mengirim data vakum, perubahan indeks, dll. Ia dapat secara selektif mengirim data hanya untuk beberapa tabel dalam database. Ini membuat replikasi logis banyak lebih hemat bandwidth.

Beroperasi pada tingkat yang lebih tinggi juga berarti Anda dapat melakukan transaksi pada database replika. Anda dapat membuat tabel sementara dan tidak masuk log. Bahkan meja biasa, jika Anda mau. Anda dapat menggunakan pembungkus data asing, tampilan, membuat fungsi, apa pun yang Anda suka. Tidak perlu membatalkan kueri jika berjalan terlalu lama.

Replikasi logis juga dapat digunakan untuk membuat replikasi multi-master di PostgreSQL, yang tidak mungkin dilakukan menggunakan replikasi fisik.

Namun, sebagai gantinya, itu tidak dapat (saat ini) mengalirkan transaksi besar saat terjadi. Itu harus menunggu sampai mereka berkomitmen. Jadi bisa ada penundaan yang lama antara transaksi besar yang dilakukan pada master dan diterapkan pada replika.

Ini memutar ulang transaksi secara ketat dalam urutan komit, sehingga transaksi kecil yang cepat dapat terhenti di belakang transaksi besar dan tertunda cukup lama.

DDL tidak ditangani secara otomatis. Anda harus menjaga agar definisi tabel tetap sinkron antara master dan replika sendiri, atau aplikasi yang menggunakan replikasi logis harus memiliki fasilitas sendiri untuk melakukan ini. Bisa jadi rumit untuk melakukannya dengan benar.

Proses penerapannya sendiri lebih rumit daripada "menulis beberapa byte di mana saya disuruh" juga. Replika juga membutuhkan lebih banyak sumber daya daripada replikasi fisik.

Implementasi replikasi logis saat ini belum matang atau diadopsi secara luas, atau sangat mudah digunakan.

Terlalu banyak pilihan, beri tahu saya apa yang harus dilakukan

Fiuh. Rumit, ya? Dan saya bahkan belum masuk ke detail replikasi tertunda, slot, max_wal_size , garis waktu, cara kerja promosi, Postgres-XL, BDR dan multimaster, dll.

Jadi apa yang harus Anda lakukan ?

Tidak ada satu jawaban yang benar. Kalau tidak, PostgreSQL hanya akan mendukung satu cara itu. Namun ada beberapa kasus penggunaan umum:

Untuk pencadangan dan pemulihan bencana gunakan pgbarman untuk membuat pencadangan dasar dan mempertahankan WAL untuk Anda, memberikan kemudahan untuk mengelola pencadangan berkelanjutan. Anda tetap harus mengambil pg_dump secara berkala cadangan sebagai asuransi tambahan.

Untuk ketersediaan tinggi tanpa risiko kehilangan data gunakan replikasi streaming sinkron.

Untuk ketersediaan tinggi dengan risiko kehilangan data rendah dan kinerja lebih baik Anda harus menggunakan replikasi streaming asinkron. Aktifkan pengarsipan WAL untuk fallback atau gunakan slot replikasi. Pantau seberapa jauh replika berada di belakang master menggunakan alat eksternal seperti Icinga.

Perbedaan antara Replikasi Aliran dan replikasi logis

Pengiriman WAL vs streaming

Streaming asinkron vs sinkron

Logis vs fisik

Terlalu banyak pilihan, beri tahu saya apa yang harus dilakukan

Referensi