Cara Mengoptimalkan Replikasi Logis PostgreSQL

Replikasi Logis atau Pglogical adalah level tabel, mekanisme replikasi berbasis WAL yang mereplikasi data Tabel tertentu antara dua instance PostgreSQL. Tampaknya ada kebingungan antara "pglogical" dan "Logical Replication". Keduanya menyediakan mekanisme replikasi yang sama dengan beberapa perbedaan dalam fitur dan kemampuan. Replikasi Logis diperkenalkan di PostgreSQL-10 sebagai fitur bawaan tidak seperti pglogical yang merupakan ekstensi. "Pglogical" dengan perkembangan berkelanjutan yang berkelanjutan, tetap sebagai satu-satunya pilihan untuk menerapkan Replikasi Logis untuk lingkungan tersebut menggunakan versi PostgreSQL sebelum 10. Akhirnya, semua fitur bagian dari pglogical akan menjadi bagian dari Replikasi Logis. Dengan kata lain, pglogical (ekstensi) menjadi Logical Replication (fitur bawaan). Keuntungan dasar dari Replikasi Logis adalah tidak memerlukan ekstensi apa pun untuk dipasang / dibuat yang pada gilirannya bermanfaat bagi lingkungan di mana pemasangan ekstensi dibatasi.

Blog ini akan fokus pada optimasi Replikasi Logis. Artinya, tips dan teknik pengoptimalan yang disorot dalam blog ini akan berlaku untuk Replikasi pglogical dan Logical.

Replikasi Logis adalah replikasi berbasis WAL yang pertama dari jenisnya. Sebagai DBA, ini akan menjadi mekanisme replikasi yang jauh lebih andal dan berkinerja baik jika dibandingkan dengan solusi replikasi berbasis pemicu lainnya. Perubahan yang dibuat pada tabel bagian dari replikasi pglogical direplikasi secara real-time melalui catatan WAL yang membuatnya sangat efisien dan tidak rumit. Semua mekanisme replikasi lain di pasar berbasis pemicu yang dapat menimbulkan tantangan kinerja dan pemeliharaan. Dengan masuknya Replikasi Logis, ketergantungan pada replikasi berbasis pemicu hampir hilang.

Ada blog lain yang menjelaskan cara mengkonfigurasi Replikasi Logis dengan cukup detail.

Di blog ini, fokusnya adalah bagaimana mengoptimalkan Replikasi Logis.

Mengoptimalkan Replikasi Logis

Untuk memulainya, perilaku "Replikasi Logis" sangat mirip dengan "Replikasi Streaming", satu-satunya perbedaan adalah bahwa replikasi streaming mereplikasi database lengkap sedangkan Replikasi Logis hanya mereplikasi tabel individual. Saat memilih tabel individu tertentu untuk direplikasi, ada faktor / tantangan yang harus diantisipasi.

Mari kita lihat faktor-faktor yang mempengaruhi replikasi Logis.

Faktor-Faktor yang Mempengaruhi Kinerja Replikasi Logika

Mengoptimalkan Replikasi Logis penting untuk memastikan data direplikasi dengan mulus tanpa gangguan. Ada faktor-faktor yang harus diramalkan sebelum menyiapkannya. Mari kita lihat mereka:

• Jenis data yang disimpan dalam Tabel yang akan direplikasi
• Seberapa aktif tabel secara transaksional (bagian dari replikasi)
• Kapasitas infrastruktur harus diantisipasi
• Konfigurasi parameter harus dilakukan secara optimal

Semua faktor di atas mempengaruhi Replikasi Logis ke tingkat yang lebih besar. Mari kita lihat secara detail.

Tipe Data Replikasi Logis PostgreSQL

Memahami jenis data yang disimpan dalam tabel adalah penting. Jika bagian tabel replikasi menyimpan teks besar atau objek Biner dan mengalami banyak transaksi, maka, replikasi mungkin melambat karena penggunaan sumber daya infrastruktur yang tinggi. Kapasitas infrastruktur harus memadai untuk menangani replikasi data yang kompleks dan berukuran besar tersebut.

Bagaimana Tabel Aktif Secara Transaksional Bagian dari Replikasi

Saat mereplikasi tabel yang sangat aktif secara transaksional, Replikasi mungkin tertinggal dalam sinkronisasi karena masalah kinerja I/O, kebuntuan, dll, yang perlu dipertimbangkan. Ini mungkin tidak membuat lingkungan database produksi terlihat lebih sehat. Jika jumlah tabel yang direplikasi tinggi dan data direplikasi ke beberapa situs, mungkin ada penggunaan CPU yang tinggi dan jumlah CPU (atau inti CPU) yang diperlukan lebih banyak.

Kapasitas Infrastruktur

Sebelum mempertimbangkan Replikasi Logis sebagai solusi, penting untuk memastikan kapasitas Infrastruktur server database cukup memadai. Jika ada banyak tabel yang direplikasi, maka harus ada cukup CPU yang tersedia untuk melakukan tugas replikasi.

Saat mereplikasi tabel dalam jumlah besar, pertimbangkan untuk membaginya menjadi beberapa kelompok dan mereplikasi secara paralel. Sekali lagi, ini akan membutuhkan beberapa CPU agar tersedia untuk replikasi. Jika perubahan data pada tabel yang direplikasi sering terjadi dan tinggi, hal ini dapat memengaruhi kinerja replikasi juga.

Mengoptimalkan Parameter untuk Replikasi Logis

Parameter yang dikonfigurasi untuk fungsi Replikasi Logis harus disetel secara optimal untuk memastikan replikasi tidak rusak.

Mari kita lihat terlebih dahulu parameter yang diperlukan untuk mengonfigurasinya:

wal_level=’logical’
max_wal_senders=10                     # greater than number of subscribers (or replicas)
max_replication_slots=10              # greater than number of subscribers (or replicas)
max_worker_processes=10           # greater than number of subscribers (or replicas)
max_logical_replication_workers  # greater than number of subscribers (or replicas)
max_sync_workers_per_subscription # depends on number of tables being replicated

Menyetel max_wal_senders

max_wal_senders harus selalu lebih besar dari jumlah replika. Jika data direplikasi ke beberapa situs, maka beberapa max_wal_senders ikut bermain. Jadi, penting untuk memastikan parameter ini disetel ke angka optimal.

Menyetel max_replication_slots

Secara umum, semua perubahan data yang terjadi pada tabel ditulis ke file WAL di pg_xlog / pg_wal yang disebut sebagai catatan WAL. Proses pengirim wal akan mengambil catatan WAL tersebut (milik tabel yang direplikasi) dan mengirimkan ke replika dan proses wal_receiver di situs replika akan menerapkan perubahan tersebut di node pelanggan.

File WAL dihapus dari lokasi pg_xlog/pg_wal setiap kali pos pemeriksaan terjadi. Jika file WAL dihapus bahkan sebelum perubahan diterapkan ke node pelanggan, replikasi akan rusak dan tertinggal. Jika node pelanggan tertinggal, slot replikasi akan memastikan semua file WAL yang diperlukan pelanggan untuk sinkron dengan penyedia dipertahankan. Disarankan untuk mengonfigurasi satu slot replikasi ke setiap node pelanggan.

Menyetel max_worker_processes

Penting untuk mengonfigurasi jumlah prosesor pekerja yang optimal. Ini tergantung pada berapa banyak jumlah proses maksimum yang dapat dimiliki server. Ini hanya mungkin di lingkungan multi-CPU. Max_worker_processes akan memastikan beberapa proses muncul untuk menyelesaikan pekerjaan dengan cara yang lebih cepat dengan memanfaatkan beberapa inti CPU. Saat mereplikasi data menggunakan Replikasi Logis, parameter ini dapat membantu menghasilkan beberapa proses pekerja untuk mereplikasi data lebih cepat. Ada parameter khusus yang disebut max_logical_worker_processes yang akan memastikan beberapa proses digunakan untuk menyalin data.

Menyetel max_logical_worker_processes

Parameter ini menentukan jumlah maksimum proses pekerja logis yang diperlukan untuk melakukan replikasi dan sinkronisasi data tabel. Nilai ini diambil dari max_worker_processes yang seharusnya lebih tinggi dari nilai parameter ini. Parameter ini sangat bermanfaat saat mereplikasi data ke beberapa situs di lingkungan multi-CPU. Standarnya adalah 4. Nilai maksimal bergantung pada berapa banyak pekerja yang mendukung sistem proses.

Menyetel max_sync_workers_per_subscription

Parameter ini menentukan jumlah maksimum proses sinkronisasi yang diperlukan per langganan. Proses sinkronisasi berlangsung selama sinkronisasi data awal dan untuk memastikan itu terjadi lebih cepat, parameter ini dapat digunakan. Saat ini, hanya satu proses sinkronisasi yang dapat dikonfigurasi per tabel yang berarti, beberapa tabel awalnya dapat disinkronkan secara paralel. Nilai defaultnya adalah 2. Nilai ini diambil dari nilai max_logical_worker_processes.

Itulah parameter-parameter yang harus disetel untuk memastikan Replikasi Logis efisien dan lebih cepat. Parameter lain yang juga mempengaruhi Replikasi Logis adalah sebagai berikut.

wal_receiver_timeout, wal_receiver_status_interval and wal_retrieve_retry_interval.

Parameter ini tidak berpengaruh pada node penyedia.

Kesimpulan

Tabel khusus replikasi adalah persyaratan umum yang muncul dalam sistem basis data yang besar dan kompleks. Ini bisa untuk tujuan pelaporan bisnis atau Data Warehousing. Sebagai DBA, saya percaya Replikasi Logis sangat memenuhi tujuan seperti itu karena implementasinya yang mudah dengan lebih sedikit kerumitan. Mengonfigurasi dan menyetel Replikasi Logis membutuhkan perencanaan, perancangan, dan pengujian yang baik. Jumlah data yang direplikasi secara real-time harus dievaluasi untuk memastikan sistem replikasi yang efisien dan tidak terlihat ada di tempatnya. Sebagai kesimpulan, Database yang berjalan di PostgreSQL-10, Logical Replication adalah cara yang harus dilakukan dan untuk database yang berjalan di PostgreSQL versi <10, pglogical adalah pilihannya.