Cara Mereplikasi Data PostgreSQL ke Situs Jarak Jauh

Dalam lingkungan database yang sibuk dengan ukuran database yang lebih besar, kebutuhan akan replikasi data waktu nyata adalah hal yang umum. Aplikasi sering kali membutuhkan data produksi untuk direplikasi secara real-time ke situs jarak jauh untuk analisis dan kebutuhan operasi bisnis penting lainnya.

DBA juga perlu memastikan bahwa data direplikasi secara terus menerus ke lokasi terpencil untuk memenuhi berbagai persyaratan. Persyaratan ini, bagaimanapun, mungkin tidak selalu untuk mereplikasi seluruh database; mungkin juga ada kebutuhan untuk mereplikasi hanya sebagian data (seperti Tabel atau kumpulan Tabel atau data dari beberapa tabel menggunakan SQL untuk analitik, pelaporan, dll.)

Di blog ini, kami akan fokus pada cara mereplikasi tabel ke database jarak jauh secara real-time.

Apa itu Replikasi Tingkat Tabel?

Replikasi tingkat tabel adalah mekanisme mereplikasi data dari tabel atau kumpulan tabel tertentu dari satu database (sumber) ke database lain (target) yang dihosting dari jarak jauh di lingkungan terdistribusi. Replikasi tingkat tabel memastikan data tabel didistribusikan secara terus menerus dan tetap konsisten di seluruh situs (target) yang direplikasi.

Mengapa Menggunakan Replikasi Tingkat Tabel?

Replikasi tingkat tabel adalah kebutuhan penting dalam lingkungan yang lebih besar, kompleks, dan sangat terdistribusi. Dalam pengalaman saya, selalu ada kebutuhan untuk mereplikasi satu set tabel dari database produksi ke gudang data untuk tujuan pelaporan. Data harus direplikasi terus menerus untuk memastikan laporan mendapatkan data terbaru. Dalam lingkungan kritis, kedaluwarsa data tidak dapat ditoleransi, sehingga perubahan data yang terjadi pada produksi harus segera direplikasi ke situs target. Ini bisa menjadi tantangan nyata bagi DBA karena harus memperkirakan berbagai faktor untuk memastikan replikasi tabel yang efisien dan lancar.

Mari kita lihat beberapa persyaratan yang diselesaikan oleh replikasi tingkat tabel:

• Laporan dapat berjalan di database di lingkungan selain produksi, seperti data warehousing
• Lingkungan database terdistribusi dengan aplikasi terdistribusi yang mengekstrak data dari beberapa situs. Dalam hal aplikasi web atau seluler terdistribusi, salinan data yang sama harus tersedia di beberapa lokasi untuk melayani berbagai kebutuhan aplikasi yang mana, replikasi tingkat tabel dapat menjadi solusi yang baik
• Aplikasi penggajian yang membutuhkan data dari berbagai basis data yang terletak di pusat data atau cloud yang terdistribusi secara geografis berbeda agar tersedia di basis data terpusat

Berbagai Faktor yang Mempengaruhi Replikasi Tingkat Tabel - Yang Harus Diperhatikan

Seperti yang kami sebutkan di atas, DBA perlu mempertimbangkan berbagai komponen dan faktor waktu nyata untuk merancang dan mengimplementasikan sistem replikasi tingkat tabel yang efektif.

Struktur Tabel

Jenis tabel data yang diakomodasi memiliki dampak besar pada kinerja replikasi. Jika tabel mengakomodasi kolom BYTEA dengan data biner ukuran lebih besar, maka kinerja replikasi dapat terpukul. Dampak replikasi pada jaringan, CPU, dan Disk harus dinilai dengan cermat.

Ukuran Data

Jika tabel yang akan dimigrasikan terlalu besar, maka migrasi data awal akan memakan sumber daya dan waktu, DBA harus memastikan database produksi tidak terpengaruh.

Sumber Daya Infrastruktur

Infrastruktur harus memiliki sumber daya yang memadai untuk memastikan sistem replikasi yang andal dan stabil dapat dibangun. Komponen infrastruktur apa yang harus diperhatikan?

CPU

Replikasi data sangat bergantung pada CPU. Saat mereplikasi dari produksi, CPU tidak boleh kehabisan tenaga yang dapat memengaruhi kinerja produksi.

Jaringan

Sangat penting untuk kinerja replikasi. Latensi jaringan antara basis data Sumber dan Target harus dinilai dengan uji stres untuk memastikan ada cukup bandwidth agar replikasi menjadi lebih cepat. Juga, jaringan yang sama dapat digunakan oleh proses atau aplikasi lain. Jadi, perencanaan kapasitas harus dilakukan di sini.

Memori

Harus ada cukup memori yang tersedia untuk memastikan data yang cukup di-cache untuk replikasi lebih cepat.

Pembaruan Tabel Sumber

Jika perubahan data pada tabel sumber berat, maka, sistem replikasi harus memiliki kemampuan untuk menyinkronkan perubahan ke situs jarak jauh sesegera mungkin. Replikasi akan berakhir dengan mengirimkan sejumlah besar permintaan sinkronisasi ke database target yang dapat menghabiskan banyak sumber daya.

Jenis Infrastruktur (pusat data atau cloud) juga dapat memengaruhi kinerja replikasi dan dapat menimbulkan tantangan. Menerapkan pemantauan juga bisa menjadi tantangan. Jika ada lag dan ada data tertentu yang hilang di database target, maka bisa jadi sulit untuk dipantau dan tidak bisa sinkron

Cara Menerapkan Replikasi Tabel

Replikasi tingkat tabel di PostgreSQL dapat diimplementasikan menggunakan berbagai alat eksternal (komersial atau sumber terbuka) yang tersedia di pasar atau dengan menggunakan aliran data yang dibuat khusus.

Mari kita lihat beberapa alat ini, fitur dan kemampuannya...

Slony

Slony adalah salah satu alat paling populer yang digunakan untuk mereplikasi tabel atau tabel individu tertentu secara asinkron secara real-time dari satu database PostgreSQL ke database lainnya. Ini adalah alat berbasis Perl yang melakukan replikasi berbasis pemicu perubahan data tabel (atau kumpulan tabel) dari database di satu situs ke situs lainnya. Ini cukup andal dan memiliki sejarah pengembangan selama bertahun-tahun. Meskipun sangat andal, sebagai alat berbasis pemicu, pengelolaan penyiapan replikasi dapat menjadi rumit.

Mari kita lihat beberapa kemampuan Slony...

Keuntungan Menggunakan Slony

• Mendukung metodologi replikasi master ke slave atau multiple slave yang membantu meningkatkan skalabilitas pembacaan horizontal. Dengan kata lain, budak tidak dapat ditulis
• Mengonfigurasi beberapa slave ke satu master dimungkinkan dan juga mendukung metodologi replikasi Cascading
• Mendukung mekanisme peralihan dan kegagalan
• Sejumlah besar tabel dapat direplikasi dalam kelompok, secara paralel
• Kami dapat mereplikasi di antara berbagai versi utama instance PostgreSQL yang menjadikan Slony pilihan yang bagus untuk peningkatan basis data
• Mudah dipasang

Kerugian Menggunakan Slony

• Tidak mendukung replikasi DDL
• Perubahan skema tertentu dapat merusak replikasi
• Kejadian replikasi dicatat dalam database di tabel log khusus Slony yang dapat menimbulkan biaya pemeliharaan.
• Jika sejumlah besar tabel dengan kumpulan data besar akan direplikasi, kinerja dan pemeliharaan dapat menimbulkan tantangan serius
• Menjadi replikasi berbasis pemicu, kinerja dapat terpengaruh

Bucardo

Bucardo adalah sistem replikasi berbasis perl open-source lainnya untuk PostgreSQL yang mendukung replikasi asinkron dari data Tabel tertentu antara dua atau lebih instance PostgreSQL. Apa yang membuat Bucardo berbeda dari Slony adalah ia juga mendukung replikasi multi-master.

Mari kita lihat berbagai jenis mekanisme replikasi yang bucardo bantu implementasikan...

• Replikasi multi-master:Tabel dapat direplikasi di kedua arah antara dua atau lebih instance PostgreSQL dan data transaksional akan disinkronkan dua arah
• Master-slave:Data dari tabel di master akan direplikasi ke slave secara asinkron dan slave tersedia untuk operasi membaca
• Mode salinan penuh (Master-slave):Bucardo -/menggandakan seluruh data dari master ke node slave dengan menghapus semua data dari slave

Keuntungan Menggunakan Bucardo

• Mudah dipasang
• Mendukung mode replikasi multi-master, master-slave, dan salinan penuh
• Dapat digunakan untuk mengupgrade database
• Replikasi dapat dilakukan di antara versi PostgreSQL yang berbeda

Kerugian Menggunakan Bucardo

• Menjadi replikasi berbasis pemicu, kinerjanya bisa menjadi tantangan
• Perubahan skema seperti DDL dapat merusak replikasi
• Mereplikasi tabel dalam jumlah besar dapat menimbulkan biaya pemeliharaan
• Sumber daya infrastruktur harus dioptimalkan untuk replikasi berkinerja baik, jika tidak, konsistensi tidak dapat dicapai.

Replikasi Logis PostgreSQL

Replikasi logis adalah fitur bawaan PostgreSQL yang revolusioner yang membantu mereplikasi tabel individual melalui catatan WAL. Menjadi replikasi berbasis WAL (mirip dengan Replikasi Streaming) pg logis menonjol jika dibandingkan dengan alat replikasi tabel lainnya. Mereplikasi data melalui catatan WAL selalu merupakan cara yang paling andal dan berkinerja tinggi untuk mereplikasi data di jaringan. Hampir semua alat di pasar menyediakan replikasi berbasis pemicu kecuali Replikasi Logis.

Keuntungan Menggunakan Replikasi Logis PostgreSQL

• Opsi terbaik saat Anda ingin mereplikasi satu Tabel atau kumpulan tabel
• Ini adalah opsi yang baik Jika persyaratannya adalah untuk memigrasikan tabel tertentu dari berbagai database ke satu database tunggal (seperti pergudangan data atau database pelaporan) untuk tujuan pelaporan atau analisis
• Tidak ada pemicu yang merepotkan

Kerugian Menggunakan Replikasi Logis PostgreSQL

• Pengelolaan file WAL yang salah / file arsip WAL dapat menimbulkan tantangan bagi Replikasi Logis
• Kami tidak dapat mereplikasi tabel tanpa kunci Utama atau Unik
• DDL dan TRUNCATE tidak direplikasi
• Lag Replikasi dapat meningkat jika WAL dihapus. Artinya, replikasi dan pengelolaan WAL harus saling melengkapi untuk memastikan replikasi tidak terputus
• Objek besar tidak dapat direplikasi

Berikut adalah beberapa referensi lainnya untuk membantu Anda lebih memahami Replikasi Logis PostgreSQL dan perbedaan antara replikasi dan streaming streaming.

Pembungkus Data Asing

Sementara Pembungkus Data Asing tidak benar-benar mereplikasi data, saya ingin menyoroti fitur PostgreSQL ini karena dapat membantu DBA mencapai sesuatu yang mirip dengan replikasi tanpa benar-benar mereplikasi data. Ini berarti data tidak direplikasi dari sumber ke target dan data dapat diakses oleh aplikasi dari database target. Basis data target hanya memiliki struktur tabel dengan tautan yang berisi Host dan detail basis data dari tabel sumber dan ketika aplikasi meminta tabel target, kemudian, data ditarik dari basis data sumber ke basis data target yang mirip dengan Tautan Basis Data. Jika PLRT Asing dapat membantu, maka Anda dapat sepenuhnya menghindari biaya replikasi data melalui jaringan. Sering kali kita mengalami situasi di mana laporan dapat dieksekusi pada basis data target jarak jauh tanpa memerlukan data yang ada secara fisik.

PLRT Asing adalah pilihan yang bagus dalam situasi berikut -

• Jika Anda memiliki tabel kecil dan statis di database sumber, maka, tidak ada gunanya mereplikasi data di atas
• Dapat sangat bermanfaat, Jika Anda memiliki tabel yang sangat besar di database sumber dan Anda menjalankan kueri agregat pada database target.

Keuntungan Menggunakan Pembungkus Data Asing

• Replikasi data dapat dihindari sepenuhnya yang dapat menghemat waktu dan sumber daya
• Mudah diterapkan
• Data yang ditarik selalu yang terbaru
• Tidak ada pemeliharaan di atas kepala

Kerugian Menggunakan Pembungkus Data Asing

• Perubahan struktural pada tabel sumber dapat memengaruhi fungsionalitas aplikasi pada database target
• Sangat bergantung pada jaringan dan dapat memiliki overhead jaringan yang signifikan bergantung pada jenis laporan yang dijalankan
• Overhead kinerja diharapkan ketika kueri dijalankan beberapa kali karena setiap kali kueri dieksekusi, data harus ditarik melalui jaringan dari basis data sumber dan juga dapat menimbulkan overhead kinerja pada basis data sumber
• Semua beban pada sumber dapat memengaruhi kinerja aplikasi pada database target

Kesimpulan

• Mereplikasi tabel dapat melayani berbagai tujuan penting untuk bisnis
• Dapat mendukung kueri paralel terdistribusi di lingkungan terdistribusi
• Menerapkan sinkron hampir tidak mungkin
• Infrastruktur harus memiliki kapasitas yang memadai yang melibatkan biaya
• Pilihan bagus untuk membangun database terpusat yang terintegrasi untuk tujuan pelaporan dan analisis