Replikasi Streaming PostgreSQL vs Replikasi Logis

Saya menganggap diri saya sedikit penjelajah. Dalam hal-hal tertentu itu. Biasanya saya akan selalu memesan makanan yang sama dari restoran yang sudah dikenal karena rasa takut akan kekecewaan melebihi ketakutan saya untuk mencoba sesuatu yang baru.

Dan tentu saja, manusia yang lapar cenderung hanya makan kan?

Namun, ketika berbicara tentang teknologi, khususnya SQL (PostgreSQL), saya cenderung tersandung dengan kecepatan penuh (definisi saya tentang penjelajahan) ke dalam area yang seringkali tidak dikenal, dengan harapan untuk belajar. Apa cara yang lebih baik untuk belajar selain pengalaman?

Jadi apa hubungannya ocehan ini dengan replikasi Logis dan Streaming di PostgreSQL?

Saya seorang pemula yang lengkap di bidang ini dengan pengetahuan nol. Ya, saya memiliki pemahaman yang sama dalam bidang Postgres ini seperti halnya saya dalam astrofisika.

Apakah saya menyebutkan bahwa saya tidak memiliki pengetahuan?

Oleh karena itu, dalam posting blog ini, saya akan mencoba mencerna perbedaan jenis replikasi ini. Tanpa pengalaman langsung di dunia nyata, saya tidak bisa menjanjikan Anda 'Jadilah segalanya ' manuskrip untuk direplikasi.

Kemungkinan, orang lain yang kurang berpengalaman di bidang tertentu (seperti saya) akan mendapat manfaat dari entri blog ini.

Pengguna dan pengembang yang berpengalaman selama perjalanan, saya berharap dapat melihat Anda di komentar di bawah.

Beberapa Definisi Dasar

Dalam arti luas, apa yang dimaksud dengan Replikasi?

Replikasi seperti yang didefinisikan di Wiktionary mengatakan ini:

"Proses di mana objek, orang, tempat, atau ide dapat disalin, ditiru atau direproduksi."

Namun, item ke-5 yang terdaftar di sana lebih dapat diterapkan pada posting blog ini dan saya rasa kita harus melihatnya juga:

"(komputasi) Proses seringnya penyalinan data elektronik satu database di satu komputer atau server ke database di komputer lain sehingga semua pengguna berbagi tingkat informasi yang sama. Digunakan untuk meningkatkan toleransi kesalahan sistem."

Sekarang ada sesuatu yang bisa kita masuki. Penyebutan menyalin data dari satu server atau database ke yang lain? Kami berada di wilayah yang akrab sekarang...

Jadi, menambahkan apa yang kita ketahui dari definisi itu, apa definisi Replikasi Streaming dan Replikasi Logis?

Mari kita lihat apa yang ditawarkan Wiki PostgreSQL:

Streaming Replication:"menyediakan kemampuan untuk terus mengirimkan dan menerapkan catatan WAL XLOG ke beberapa server siaga agar tetap terkini.

Dan Dokumentasi PostgreSQL memiliki definisi ini untuk Replikasi Logis:

"Replikasi logis adalah metode mereplikasi objek data dan perubahannya, berdasarkan identitas replikasinya (biasanya kunci utama). Kami menggunakan istilah logis berbeda dengan replikasi fisik, yang menggunakan alamat blok yang tepat dan replikasi byte demi byte. "

Bab 19.6 Replikasi dari dokumentasi resmi juga penuh dengan barang jadi pastikan dan kunjungi sumbernya.

Di bawah ini, saya akan mencoba menyampaikan perbedaan istilah awam. (Ingat, jika saya tersandung, saya seorang pemula.) Ini adalah ikhtisar 'tingkat tinggi' yang ekstrem.

Replikasi Logis

Basis data "sumber" membuat PUBLICATION menggunakan perintah CREATE PUBLICATION. (Saya menganggap ini secara sederhana sebagai 'pengirim'.)

Dokumentasi menyebutnya sebagai penerbit.

Basis data penerbit ini memiliki data yang ingin kami tiru. Namun, kita harus memiliki sesuatu untuk ditiru dan di sinilah mitra penerbit masuk. 'Pelanggan'. Perhatikan bahwa saya memasukkan bentuk jamak alternatif karena dari apa yang saya temukan melalui pencarian online, ini adalah pengaturan praktis untuk memiliki banyak pelanggan.

'Pelanggan' (bisa juga dianggap sebagai database replika) membuat BERLANGGANAN ke database "sumber" (penerbit) yang menentukan informasi koneksi, dan publikasi apa pun yang menjadi langganannya.

Pelanggan dapat juga menjadi penerbit, membuat PUBLIKASInya sendiri yang dapat dilanggani oleh pelanggan lain.

Apa yang terjadi sekarang?

Setiap perubahan data yang terjadi pada penerbit dikirim ke pelanggan. Yang di luar kotak, adalah segalanya, tetapi dapat dikonfigurasi atau terbatas pada operasi tertentu (mis., INSERT, UPDATE, atau DELETE).

Contoh tingkat tinggi:

Misalkan kita memperbarui satu atau beberapa baris pada tabel tertentu di penerbit, pembaruan dan perubahan tersebut direplikasi, pada instance pelanggan atau beberapa pelanggan jika jenis konfigurasi tersebut diterapkan.

Berikut adalah beberapa hal yang perlu diingat yang saya rasa layak untuk disebutkan:

• Konfigurasi wal_level database penerbit harus disetel ke logikal.
• Replikasi logis tidak memiliki perintah DDL (Data Definition Language).
• Dari halaman Konflik dalam dokumentasi:"Replikasi logis berperilaku serupa dengan operasi DML normal di mana data akan diperbarui meskipun diubah secara lokal pada node pelanggan. Jika data yang masuk melanggar batasan apa pun, replikasi akan berhenti. Ini disebut sebagai konflik. Saat mereplikasi operasi UPDATE atau DELETE, data yang hilang tidak akan menghasilkan konflik dan operasi tersebut akan dilewati begitu saja."
• Tabel penerbit, harus memiliki cara untuk mengidentifikasi dirinya sendiri (disebut "identitas replika") untuk mereplikasi operasi DML (PERBARUI dan HAPUS) dengan benar di replika apa pun untuk baris yang terpengaruh tersebut. Jika tabel memiliki kunci utama, ini adalah default (sepertinya pilihan suara bagi saya), tetapi tanpa kunci utama, opsi konfigurasi lain tersedia. Seluruh baris dapat digunakan jika tidak ada kunci kandidat lain (disebut "penuh"), meskipun dokumentasi menyebutkan ini biasanya bukan solusi yang efisien. (Lihat bagian IDENTITAS REPLIKA dalam dokumen untuk deskripsi tingkat lebih rendah tentang cara menyetelnya)

Pembatasan

Dokumentasi di bagian 31.4. Pembatasan memiliki beberapa pengingat utama tentang batasan yang akan saya abaikan. Pastikan dan tinjau halaman tertaut di atas untuk kata-kata yang tepat.

• Skema database dan perintah DDL apa pun tidak didukung dalam replikasi. Disarankan bahwa mungkin pg_dump dapat digunakan pada awalnya, tetapi tetap saja, Anda perlu memperbarui sendiri perubahan dan kemajuan lebih lanjut dalam skema ke semua replika.
• Data dalam kolom urutan akan direplikasi. Tapi, urutan itu sendiri hanya akan mencerminkan nilai awal. Untuk bacaan, tidak apa-apa. Tetapi jika ini adalah tujuan Anda untuk failover, Anda sendiri harus MEMPERBARUI ke nilai saat ini. Dokumen menyarankan pg_dump di sini.
• Truncate belum didukung.
• Replikasi objek besar tidak didukung.
• Tampilan, tampilan terwujud, tabel akar partisi, atau tabel asing tidak didukung baik pada penerbit maupun pelanggan.

Kasus Penggunaan Umum yang Dilaporkan

• Anda hanya tertarik pada data dan perubahan data tertentu yang benar-benar Anda tiru versus hanya mereplikasi seluruh database.
• Saat Anda membutuhkan replika untuk operasi hanya-baca, seperti skenario analitik.
• Mengizinkan pengguna atau subkumpulan pengguna yang berbeda membatasi atau memantau akses ke data.
• Mendistribusikan data.
• Kompatibilitas dengan versi PostgreSQL lainnya.

Replikasi Streaming

Dari meneliti, membaca, dan mempelajari Replikasi Streaming, satu hal yang saya kumpulkan di awal, adalah memilih untuk menyiapkan replikasi asinkron (default) atau sinkron.

Ah, istilah yang lebih asing ya?

Inilah definisi 'tingkat tinggi' saya untuk keduanya:

Dengan replikasi asinkron, setelah transaksi dilakukan pada primer, ada sedikit penundaan ketika transaksi yang sama dilakukan, dan ditulis pada replika. Ada potensi kehilangan data dengan jenis konfigurasi ini.

• Satu, misalkan master mogok.
• Dua, replika sangat jauh di belakang master, telah membuang data dan informasi yang diperlukan untuk replika bahkan menjadi 'saat ini'.

Namun, dalam replikasi sinkron, tidak ada transaksi yang dianggap selesai, hingga dikonfirmasi oleh master dan server replika. Yang akan menulis komit ke WAL kedua server.

Dalam istilah yang saya mengerti, ini berarti tulisan di master juga telah dikonfirmasi dan ditulis di replika.

Berikut adalah penjelasan resmi dari bagian 26.2.8. Replikasi Sinkron dalam dokumentasi resmi:

“Saat meminta replikasi sinkron, setiap komit dari transaksi tulis akan menunggu hingga konfirmasi diterima bahwa komit telah ditulis ke log di disk write-ahead dari server utama dan server siaga. “

Bagian lain dari dokumentasi memiliki ikhtisar yang bagus tentang apa yang seharusnya (menurut saya), manfaat besar:"Satu-satunya kemungkinan bahwa data dapat hilang adalah jika primer dan siaga mengalami crash pada saat yang sama."

Meskipun tidak ada yang tidak mungkin, itu masih merupakan jaminan yang cukup baik bahwa Anda tidak akan dibiarkan tanpa salinan data Anda.

Oke, kami tahu kami harus memilih salah satu dari konfigurasi penyiapan ini, tetapi apa inti keseluruhannya?

Singkatnya, Streaming Replication mengirim dan menerapkan file WAL (Write Ahead Log) dari satu server database (master atau utama), ke 'replika' (database penerima).

Tapi ada peringatan di sini yang perlu diingat. Berpotensi, file WAL dari master dapat didaur ulang sebelum standy mendapatkannya. Salah satu cara untuk menguranginya adalah dengan meningkatkan setelan wal_keep_segments ke nilai yang lebih tinggi.

Poin pada Replikasi Streaming

• Secara default, replikasi Streaming adalah asinkron yang berarti ada penundaan (mungkin kecil) antara transaksi yang dilakukan pada master, dan visibilitasnya pada replika.
• Replika terhubung ke master melalui koneksi jaringan.
• Berhati-hatilah dengan autentikasi. Lihat di sini dari dokumentasi:"Sangat penting bahwa hak akses untuk replikasi diatur sehingga hanya pengguna tepercaya yang dapat membaca aliran WAL karena mudah untuk mengekstrak informasi istimewa darinya"

Kapan Menggunakan Replikasi Streaming

• Penggunaan umum (terutama dalam analitik) menyediakan replika 'hanya-baca' untuk melepaskan beban dari server utama.
• Anda memerlukan lingkungan ketersediaan tinggi.
• Pengaturan yang berguna untuk failover ke server siaga panas jika server utama mati.