Menggunakan replikasi untuk database PostgreSQL Anda dapat berguna tidak hanya untuk memiliki ketersediaan tinggi dan lingkungan yang toleran terhadap kesalahan, tetapi juga untuk meningkatkan kinerja pada sistem Anda dengan menyeimbangkan lalu lintas antara node siaga. Di bagian pertama dari blog dua bagian ini, kita akan melihat beberapa konsep yang terkait dengan replikasi PostgreSQL.
Metode Replikasi di PostgreSQL
Ada berbagai metode untuk mereplikasi data di PostgreSQL, tetapi di sini kita akan fokus pada dua metode utama:Replikasi Streaming dan Replikasi Logis.
Replikasi Streaming
Replikasi Streaming PostgreSQL, Replikasi PostgreSQL yang paling umum, adalah replikasi fisik yang mereplikasi perubahan pada tingkat byte demi byte, membuat salinan database yang identik di server lain. Ini didasarkan pada metode pengiriman log. Catatan WAL langsung dipindahkan dari satu server database ke server lain untuk diterapkan. Kita dapat mengatakan bahwa ini adalah semacam PITR berkelanjutan.
Transfer WAL ini dilakukan dengan dua cara berbeda, dengan mentransfer catatan WAL satu file (segmen WAL) pada satu waktu (pengiriman log berbasis file) dan dengan mentransfer catatan WAL (file WAL terdiri dari Catatan WAL) dengan cepat (pengiriman log berbasis catatan), antara server utama dan satu atau lebih dari pada server siaga, tanpa menunggu file WAL diisi.
Dalam praktiknya, proses yang disebut penerima WAL, yang berjalan di server siaga, akan terhubung ke server utama menggunakan koneksi TCP/IP. Di server utama, ada proses lain, bernama pengirim WAL, dan bertanggung jawab mengirimkan pendaftar WAL ke server siaga saat terjadi.
Replikasi streaming dasar dapat direpresentasikan sebagai berikut:
Saat mengonfigurasi replikasi streaming, Anda memiliki opsi untuk mengaktifkan pengarsipan WAL. Ini tidak wajib, tetapi sangat penting untuk penyetelan replikasi yang kuat, karena server utama harus menghindari mendaur ulang file WAL lama yang belum diterapkan ke server siaga. Jika ini terjadi, Anda harus membuat ulang replika dari awal.
Replikasi Logis
Replikasi Logis PostgreSQL adalah metode mereplikasi objek data dan perubahannya, berdasarkan identitas replikasinya (biasanya kunci utama). Ini didasarkan pada mode terbitkan dan berlangganan, di mana satu atau lebih pelanggan berlangganan satu atau lebih publikasi pada simpul penerbit.
Publikasi adalah kumpulan perubahan yang dihasilkan dari tabel atau grup tabel. Node tempat publikasi didefinisikan disebut sebagai penerbit. Langganan adalah sisi hilir dari replikasi logis. Node di mana langganan didefinisikan disebut sebagai pelanggan, dan mendefinisikan koneksi ke database lain dan set publikasi (satu atau lebih) yang ingin berlangganan. Pelanggan mengambil data dari publikasi tempat mereka berlangganan.
Replikasi logis dibuat dengan arsitektur yang mirip dengan replikasi streaming fisik. Ini diimplementasikan oleh proses "walsender" dan "apply". Proses walsender memulai decoding logis dari WAL dan memuat plugin decoding logis standar. Plugin mengubah perubahan yang dibaca dari WAL ke protokol replikasi logis dan memfilter data sesuai dengan spesifikasi publikasi. Data kemudian terus ditransfer menggunakan protokol replikasi streaming ke pekerja yang menerapkan, yang memetakan data ke tabel lokal dan menerapkan perubahan individual saat diterima, dalam urutan transaksional yang benar.
Replikasi logis dimulai dengan mengambil snapshot data pada database penerbit dan menyalinnya ke pelanggan. Data awal dalam tabel langganan yang ada di-snapshot dan disalin dalam contoh paralel dari jenis proses penerapan khusus. Proses ini akan membuat slot replikasi sementara sendiri dan menyalin data yang ada. Setelah data yang ada disalin, pekerja memasuki mode sinkronisasi, yang memastikan bahwa tabel dibawa ke keadaan tersinkronisasi dengan proses penerapan utama dengan mengalirkan setiap perubahan yang terjadi selama penyalinan data awal menggunakan replikasi logis standar. Setelah sinkronisasi selesai, kontrol replikasi tabel diberikan kembali ke proses penerapan utama di mana replikasi berlanjut seperti biasa. Perubahan pada penerbit dikirim ke pelanggan saat terjadi secara real-time.
Mode Replikasi di PostgreSQL
Replikasi di PostgreSQL bisa sinkron atau asinkron.
Replikasi Asinkron
Ini adalah mode default. Di sini dimungkinkan untuk melakukan beberapa transaksi di node utama yang belum direplikasi ke server siaga. Ini berarti ada kemungkinan beberapa potensi kehilangan data. Penundaan dalam proses komit ini seharusnya sangat kecil jika server siaga cukup kuat untuk mengimbangi beban. Jika risiko kehilangan data kecil ini tidak dapat diterima di perusahaan, Anda dapat menggunakan replikasi sinkron.
Replikasi Sinkron
Setiap komit dari transaksi tulis akan menunggu hingga konfirmasi bahwa komit telah ditulis ke log di disk dari server utama dan server siaga. Metode ini meminimalkan kemungkinan kehilangan data. Agar kehilangan data terjadi, Anda memerlukan primer dan siaga agar gagal pada saat yang bersamaan.
Kerugian metode ini sama untuk semua metode sinkron karena dengan metode ini waktu respons untuk setiap transaksi tulis meningkat. Ini karena kebutuhan untuk menunggu sampai semua konfirmasi bahwa transaksi telah dilakukan. Untungnya, transaksi read-only tidak akan terpengaruh oleh hal ini, tetapi; hanya transaksi tulis.
Ketersediaan Tinggi untuk Replikasi PostgreSQL
Ketersediaan tinggi merupakan persyaratan bagi banyak sistem, apa pun teknologi yang kami gunakan, dan ada berbagai pendekatan untuk mencapainya dengan menggunakan alat yang berbeda.
Keseimbangan Beban
Load balancers adalah alat yang dapat digunakan untuk mengelola lalu lintas dari aplikasi Anda untuk mendapatkan hasil maksimal dari arsitektur database Anda. Tidak hanya berguna untuk menyeimbangkan beban database kami, ini juga membantu aplikasi dialihkan ke node yang tersedia/sehat dan bahkan menentukan port dengan peran berbeda.
HAProxy adalah penyeimbang beban yang mendistribusikan lalu lintas dari satu asal ke satu atau beberapa tujuan dan dapat menentukan aturan dan/atau protokol khusus untuk tugas ini. Jika salah satu tujuan berhenti merespons, itu ditandai sebagai offline, dan lalu lintas dikirim ke tujuan lain yang tersedia. Hanya memiliki satu node Load Balancer akan menghasilkan Satu Titik Kegagalan, jadi untuk menghindarinya, Anda harus menerapkan setidaknya dua node HAProxy dan mengonfigurasi Keepalive di antara keduanya.
Keepalived adalah layanan yang memungkinkan kita mengonfigurasi IP virtual dalam grup server aktif/pasif. IP virtual ini ditetapkan ke server aktif. Jika server ini gagal, IP secara otomatis dimigrasikan ke server pasif “Sekunder”, memungkinkannya untuk terus bekerja dengan IP yang sama secara transparan untuk sistem.
Meningkatkan Kinerja Pada Replikasi PostgreSQL
Kinerja selalu penting dalam sistem apa pun. Anda perlu memanfaatkan sumber daya yang tersedia dengan baik untuk memastikan waktu respons terbaik dan ada berbagai cara untuk melakukannya. Setiap koneksi ke database menghabiskan sumber daya sehingga salah satu cara untuk meningkatkan kinerja database PostgreSQL Anda adalah dengan memiliki penyatuan koneksi yang baik antara aplikasi Anda dan server database.
Pengumpul Koneksi
Pengumpulan koneksi adalah metode untuk membuat kumpulan koneksi dan menggunakannya kembali, menghindari membuka koneksi baru ke database sepanjang waktu, yang akan meningkatkan kinerja aplikasi Anda secara signifikan. PgBouncer adalah kumpulan koneksi populer yang dirancang untuk PostgreSQL.
PgBouncer bertindak sebagai server PostgreSQL, jadi Anda hanya perlu mengakses database Anda menggunakan informasi PgBouncer (Alamat IP/Nama Host dan Port), dan PgBouncer akan membuat koneksi ke server PostgreSQL, atau akan menggunakan kembali jika ada.
Saat PgBouncer menerima koneksi, ia melakukan otentikasi, yang bergantung pada metode yang ditentukan dalam file konfigurasi. PgBouncer mendukung semua mekanisme otentikasi yang didukung oleh server PostgreSQL. Setelah ini, PgBouncer memeriksa koneksi yang di-cache, dengan kombinasi nama pengguna+database yang sama. Jika koneksi cache ditemukan, itu mengembalikan koneksi ke klien, jika tidak, itu membuat koneksi baru. Bergantung pada konfigurasi PgBouncer dan jumlah koneksi yang aktif, koneksi baru mungkin saja diantrekan hingga dapat dibuat, atau bahkan dibatalkan.
Dengan semua konsep yang disebutkan, di bagian kedua blog ini, kita akan melihat bagaimana Anda dapat menggabungkannya untuk memiliki lingkungan replikasi yang baik di PostgreSQL.
