Streaming PostgreSQL vs Replikasi Logis – Perbandingan

Mereplikasi informasi yang disimpan di database Anda sangat penting untuk mendistribusikan data dan memastikan Anda memiliki cadangan yang dapat digunakan untuk pemulihan bencana, jika terjadi kesalahan.

Replikasi PostgreSQL hadir dalam dua bentuk, dan keduanya memiliki kegunaan khusus. Memahami cara menerapkan salah satu atau kedua metode replikasi data ini dapat menyederhanakan proses distribusi data Anda. Hal terakhir yang Anda inginkan adalah kehilangan pekerjaan penting yang telah Anda lakukan pada database.

Mari kita lihat pro, kontra, dan kasus penggunaan replikasi streaming dan logika di PostgreSQL.

Mendefinisikan Replikasi Data di PostgreSQL

Jika Anda sudah terbiasa dengan apa itu replikasi data, Anda dapat melanjutkan dan menggulir ke bawah ke bagian berikutnya. Namun jika Anda baru mengenal teknik database, kami ingin menetapkan fondasinya dengan sangat cepat.

Seperti namanya, replikasi adalah proses sering menyalin data dari satu database di server komputer ke database lain di server yang berbeda, sehingga semua pengguna memiliki akses ke tingkat informasi yang sama. Dalam komputasi, replikasi digunakan untuk menghilangkan kesalahan dalam sistem digital.

Replikasi menghilangkan silo data, melindungi informasi berharga, dan menyederhanakan pengembangan.

Di PostgreSQL, ada dua opsi untuk replikasi:replikasi logis &streaming. Metode-metode ini bagus untuk kasus penggunaan yang berbeda, dan sebagai pengembang, Anda mungkin lebih cenderung menggunakan satu dari yang lain. Namun ada baiknya untuk memahami cara menggunakan keduanya sehingga Anda dapat memutuskan mana yang akan diterapkan dalam skenario yang berbeda.

Replikasi Logis di PostgreSQL

Replikasi streaming diperkenalkan untuk digunakan dengan PostgreSQL v10.0. Replikasi logis bekerja dengan menyalin/menggandakan objek data dan perubahannya berdasarkan identitas replikasinya.

Dalam banyak kasus, identitas data adalah kunci utama. Di PostgreSQL, ini memberi pengguna kontrol mendetail atas keamanan data dan informasi yang direplikasi.

Istilah logis digunakan untuk membedakannya dari replikasi fisik, yang menggunakan replikasi byte demi byte dan alamat blok yang tepat. Baca selengkapnya di dokumentasi PostgreSQL resmi di sini.

Melalui model terbitkan dan berlangganan, ia bekerja dengan memungkinkan satu atau lebih pelanggan untuk berlangganan satu atau lebih publikasi pada simpul penerbit. Pelanggan dapat mengambil informasi dari publikasi dan memublikasikan ulang data untuk replikasi berjenjang atau konfigurasi yang lebih kompleks.

Replikasi data logis juga dapat berbentuk replikasi transaksional. Jika engineer ingin menyalin tabel, mereka dapat menggunakan metode replikasi ini untuk mengambil snapshot data di sisi penerbit dan mengirimkannya ke database pelanggan.

Saat pelanggan membuat perubahan pada data asli, database penerbit menerima pembaruan secara real-time. Untuk memastikan konsistensi transaksional dalam publikasi dengan satu langganan, pelanggan harus menerapkan data dalam urutan yang sama dengan penerbit.

Kelebihan Replikasi Logis di PostgreSQL

Replikasi logis memungkinkan pengguna untuk menggunakan server tujuan untuk menulis dan memungkinkan pengembang untuk memiliki indeks dan definisi keamanan yang berbeda. Ini memberikan peningkatan fleksibilitas untuk transfer data antara penerbit dan pelanggan.

Dukungan lintas versi

Selain itu, ia hadir dengan dukungan lintas versi dan dapat diatur di antara berbagai versi PostgreSQL. Ini juga menyediakan penyaringan berbasis acara. Publikasi dapat memiliki beberapa langganan, sehingga memudahkan berbagi data di seluruh jaringan yang luas.

Minimum beban server

Dibandingkan dengan solusi berbasis pemicu, ini memiliki beban server minimum sambil memberikan fleksibilitas penyimpanan melalui mereplikasi set yang lebih kecil. Seperti disebutkan di atas, replikasi data logis bahkan dapat menyalin data yang terdapat dalam tabel yang dipartisi dasar.

Penting juga untuk disebutkan bahwa replikasi data logis memungkinkan transformasi data meskipun sedang disiapkan dan memungkinkan streaming paralel di seluruh penerbit.

Kontra Replikasi Logis di PostgreSQL

Replikasi logis tidak akan menyalin urutan, objek besar, tampilan terwujud, tabel root partisi, dan tabel asing.

Di PostgreSQL, replikasi data logis hanya didukung oleh operasi DML. Pengembang tidak dapat menggunakan DDL atau memotong, dan skema harus ditentukan sebelumnya. Selain itu, tidak mendukung replikasi timbal balik (dua arah).

Jika pengguna mengalami konflik dengan kendala pada data yang direplikasi dalam tabel, replikasi akan berhenti. Satu-satunya cara agar replikasi dapat dilanjutkan adalah jika penyebab konflik telah diselesaikan.

Konflik yang tidak disengaja dapat menghentikan momentum tim Anda, jadi Anda harus memahami cara menyelesaikan masalah dengan cepat.

Jika konflik tidak ditangani dengan cepat, slot replikasi akan membeku dalam kondisi saat ini, node penerbit akan mulai mengakumulasi Write-Ahead Logs (WAL), dan node pada akhirnya akan kehabisan ruang disk.

Gunakan Kasus untuk Replikasi Logis di PostgreSQL

Banyak insinyur akan menggunakan replikasi logis untuk:

• Mendistribusikan perubahan dalam satu database atau subset database ke pelanggan secara real-time
• Menggabungkan beberapa database menjadi satu database pusat (seringkali untuk penggunaan analitik)
• Membuat replikasi di berbagai versi PostgreSQL
• Menyebarkan replikasi antara instance PostgreSQL di berbagai platform, seperti Linux ke Windows
• Berbagi data yang direplikasi dengan pengguna atau grup lain
• Mendistribusikan subset database di antara beberapa database

Replikasi Streaming di PostgreSQL

Replikasi streaming diperkenalkan untuk digunakan dengan PostgreSQL 9.0. Proses mengirim dan menerapkan file Write-Ahead Logging (WAL) dari master atau server database utama ke replika atau database penerima. WAL digunakan untuk replikasi dan untuk memastikan integritas data.

Cara kerja replikasi streaming

Replikasi streaming berfungsi untuk menjembatani kesenjangan antara transfer data yang melekat dalam pengiriman log berbasis file, yang menunggu hingga WAL mencapai kapasitas maksimal untuk mengirimkan data.

Dengan mengalirkan catatan WAL, server database mengalirkan catatan WAL dalam potongan untuk menyinkronkan data. Server siaga terhubung ke replika dan menerima potongan WAL saat dikirim.

Dengan replikasi streaming, pengguna harus memutuskan apakah akan menyiapkan replikasi asinkron atau sinkron. Saat replikasi streaming pertama kali diterapkan, replikasi asinkron akan menjadi default.

Ini menunjukkan bahwa ada penundaan antara perubahan awal pada primer dan refleksi dari perubahan tersebut pada replika. Asinkronisasi membuka pintu untuk potensi kehilangan data jika master mogok sebelum perubahan disalin atau jika replika sangat tidak sinkron dengan aslinya sehingga sudah membuang data terkait untuk membuat perubahan.

Replikasi sinkron adalah pilihan yang jauh lebih aman karena membuat perubahan secara real-time. Transfer dari master ke replika dianggap tidak lengkap sampai kedua server memverifikasi informasi. Setelah perubahan data dikonfirmasi, transfer dicatat di WAL kedua server.

Baik Anda menggunakan replikasi asinkron atau sinkron, replika harus terhubung ke master melalui koneksi jaringan. Selain itu, penting bagi pengguna untuk menyiapkan hak akses untuk aliran WAL replika, sehingga informasinya tidak disusupi.

Kelebihan Replikasi Streaming di PostgreSQL

Salah satu keuntungan paling signifikan dalam menggunakan replikasi streaming adalah bahwa satu-satunya cara untuk kehilangan data adalah jika server utama dan server penerima mogok pada saat yang bersamaan. Jika Anda memberikan informasi penting, replikasi streaming akan menjamin bahwa salinan pekerjaan Anda akan disimpan.

Pengguna dapat menghubungkan lebih dari satu server siaga ke server utama, dan log akan dialirkan dari server utama ke setiap siaga yang terhubung. Jika salah satu replika tertunda atau terputus, streaming akan dilanjutkan ke replika lainnya.

Menyiapkan pengiriman log melalui replikasi streaming tidak akan mengganggu apa pun yang sedang dijalankan pengguna di database utama. Jika server data utama harus dimatikan, server akan menunggu hingga catatan yang diperbarui dikirim ke replika sebelum dimatikan.

Kontra Replikasi Streaming di PostgreSQL

Replikasi streaming tidak akan menyalin informasi ke versi atau arsitektur yang berbeda, mengubah informasi server siaga, dan tidak menawarkan replikasi granular.

Khususnya dengan replikasi data streaming asinkron, file WAL lama yang belum disalin ke replika dapat didaur ulang saat pengguna membuat perubahan pada master. Untuk memastikan bahwa file penting tidak hilang, pengguna dapat menyetel wal_keep_segments ke nilai yang lebih tinggi.

Tanpa kredensial otentikasi pengguna yang disiapkan untuk server replika, data sensitif dapat dengan mudah diekstraksi. Agar pembaruan waktu nyata terjadi antara master dan replika, pengguna harus mengubah metode replikasi dari replikasi asinkron default menjadi replikasi sinkron.

Kasus Penggunaan untuk Replikasi Streaming di PostgreSQL

Banyak insinyur akan menggunakan replikasi streaming untuk:

• Membuat cadangan untuk database utama mereka jika terjadi kegagalan server atau kehilangan data
• Menumbuhkan solusi ketersediaan tinggi dengan penundaan replikasi sesedikit mungkin
• Melakukan pertanyaan besar untuk menghilangkan beberapa tekanan pada sistem utama
• Mendistribusikan beban kerja database ke beberapa mesin, terutama untuk format hanya-baca

Apa yang Tersedia untuk Masa Depan?

PostgreSQL Global Development Group mengumumkan rilis PostgreSQL 14 pada 30 September 2021. Versi baru ini hadir dengan peningkatan baik streaming maupun replikasi logis melalui platform.

Untuk replikasi streaming, versi 14 memungkinkan pengguna untuk:

• Setel parameter server log_recovery_conflict_waits untuk melaporkan konflik pemulihan yang lama, waktu tunggu secara otomatis
• Jeda pemulihan di server siaga panas saat mengubah parameter di server utama (bukan langsung mematikan siaga)
• Gunakan fungsi pg_get_wal_replay_pause_state() untuk melaporkan status pemulihan lebih detail
• Berikan parameter server hanya-baca in_hot_standby
• Memotong tabel kecil dengan cepat selama pemulihan pada kluster yang memiliki banyak buffer bersama
• Izinkan sinkronisasi sistem file pada awal pemulihan kerusakan melalui Linux
• Gunakan fungsi pg_xact_commit_timestamp_origin() pada transaksi tertentu untuk mengembalikan stempel waktu komit dan asal replikasi
• Gunakan fungsi pg_last_committed_xact() untuk menambahkan asal replikasi pada catatan yang dikembalikan
• Gunakan kontrol izin fungsi standar untuk mengubah fungsi asal replikasi (default masih membatasi akses ke pengguna super)

Untuk replikasi logis, versi 14 memungkinkan pengguna untuk:

• Alirkan transaksi panjang yang sedang berlangsung ke pelanggan dengan API replikasi logis
• Izinkan beberapa transaksi selama replikasi tabel
• Hasilkan subtransaksi WAL-log langsung dan asosiasi XID tingkat atas
• Gunakan fungsi pg_create_logical_replication_slot() untuk meningkatkan API decoding logis untuk komitmen dua fase
• Tambahkan pesan pembatalan cache ke WAL selama penyelesaian perintah untuk memungkinkan streaming logis dari transaksi yang sedang berlangsung
• Mengontrol pesan decoding logis mana yang dikirim ke aliran replikasi
• Gunakan mode transfer biner untuk replikasi lebih cepat
• Filter dekode menurut XID

PostgreSQL sudah bekerja menuju versi 15, yang akan dirilis pada kuartal ketiga tahun 2022. Salah satu masalah terkait replikasi yang akan ditangani dalam versi terbaru termasuk mencegah penggunaan variabel yang diwarisi dari lingkungan server dalam replikasi streaming. Namun karena semakin banyak pengguna yang beradaptasi dengan versi 14, PostgreSQL kemungkinan akan menambahkan lebih banyak tugas untuk meningkatkan fungsi replikasi.

Perbandingan Replikasi PostgreSQL Cepat:Replikasi Logis vs. Streaming

Kesimpulan

Kami berharap panduan ini berguna saat Anda mengatur fungsi replikasi Anda. Jika Anda memiliki pertanyaan atau ada hal lain yang ingin Anda ketahui tentang bagaimana ScaleGrid dapat membantu Anda dengan penerapan PostgreSQL, hubungi salah satu dari banyak pakar database kami.