Ketersediaan Tinggi PostgreSQL dengan Arsitektur Master-Slave &Master-Master

Di bawah ini adalah kutipan dari whitepaper kami “PostgreSQL Management and Automation with ClusterControl” yang dapat diunduh secara gratis.

Catatan Revisi: Perlu diingat bahwa istilah yang digunakan di blog ini Master-Slave sama dengan istilah Master-Standby yang digunakan oleh PostgreSQL. Kami menggunakan Master-Slave untuk menjaga paralelisme dengan teknologi lain.

Untuk konfigurasi HA kita dapat memiliki beberapa arsitektur, tetapi arsitektur dasarnya adalah arsitektur master-slave dan master-master. Server database dapat bekerja sama untuk memungkinkan server kedua mengambil alih dengan cepat jika server utama gagal (ketersediaan tinggi ), atau untuk mengizinkan beberapa komputer menyajikan data yang sama (penyeimbangan beban).

Arsitektur Master-Slave PostgreSQL

Arsitektur ini memungkinkan kami untuk memelihara database master dengan satu atau lebih server siaga yang siap mengambil alih operasi jika server utama gagal. Basis data siaga ini akan tetap tersinkronisasi (atau hampir tersinkronisasi) dengan master.

Replikasi antara master dan slave dapat dilakukan melalui pernyataan SQL (logical standbys) atau melalui modifikasi struktur data internal (physical standbys). PostgreSQL menggunakan aliran catatan write-ahead log (WAL) untuk menjaga sinkronisasi database siaga. Jika server utama gagal, standby berisi hampir semua data dari server utama, dan dapat dengan cepat membuat server database master baru. Ini bisa sinkron atau asinkron dan hanya dapat dilakukan untuk seluruh database Server.

Menyiapkan replikasi streaming adalah tugas yang memerlukan beberapa langkah yang harus diikuti secara menyeluruh. Untuk langkah-langkah tersebut dan beberapa latar belakang lainnya tentang subjek ini, silakan lihat:Menjadi DBA PostgreSQL - Cara Mengatur Replikasi Streaming untuk Ketersediaan Tinggi.

Dari versi 10, PostgreSQL menyertakan opsi untuk menyiapkan replikasi logis.

Replikasi logis memungkinkan server database untuk mengirim aliran modifikasi data ke server lain. Replikasi logis PostgreSQL membangun aliran modifikasi data logis dari WAL. Replikasi logis memungkinkan perubahan data dari tabel individu untuk direplikasi. Itu tidak memerlukan server tertentu untuk ditetapkan sebagai master atau replika tetapi memungkinkan data mengalir ke berbagai arah.

Anda dapat menemukan informasi lebih lanjut mengenai replikasi logis:Blog:Tinjauan Replikasi Logis di PostgreSQL.

Untuk memastikan ketersediaan tinggi secara efektif, tidak cukup hanya memiliki arsitektur master-slave. Kita juga perlu mengaktifkan beberapa bentuk failover otomatis, jadi jika ada yang gagal, kita dapat memiliki penundaan sekecil mungkin dalam melanjutkan fungsi normal. PostgreSQL tidak menyertakan mekanisme failover otomatis untuk mengidentifikasi kegagalan pada database master dan memberi tahu salep untuk mengambil kepemilikan, sehingga akan memerlukan sedikit pekerjaan di sisi DBA. Anda harus mengerjakan skrip yang menyertakan perintah pg_ctl promote, yang akan mempromosikan slave sebagai master baru. Ada juga beberapa alat pihak ketiga untuk otomatisasi ini. Banyak alat seperti itu ada dan terintegrasi dengan baik dengan fasilitas sistem operasi yang diperlukan untuk keberhasilan failover, seperti Migrasi alamat IP.

Setelah failover terjadi, Anda perlu memodifikasi aplikasi Anda agar dapat bekerja dengan master baru. Anda juga hanya akan memiliki satu server yang berfungsi, jadi pembuatan ulang arsitektur master-slave perlu dilakukan, jadi kami kembali ke situasi normal yang sama seperti sebelum masalah.

Arsitektur Master-Master PostgreSQL

Arsitektur ini menyediakan cara untuk meminimalkan dampak kesalahan di salah satu node, karena node lain dapat menangani semua lalu lintas, mungkin sedikit memengaruhi kinerja, tetapi tidak pernah kehilangan fungsionalitas. Ini juga digunakan untuk mencapai (dan mungkin ini adalah poin yang lebih menarik) skalabilitas horizontal (peningkatan skala), berlawanan dengan konsep skalabilitas vertikal di mana kita menambahkan lebih banyak sumber daya ke server (peningkatan skala).

Untuk mengimplementasikan arsitektur ini, Anda perlu menggunakan alat eksternal, karena fitur ini (belum) didukung secara asli oleh PostgreSQL.

Anda harus sangat berhati-hati saat memilih solusi untuk menerapkan master-master, karena ada banyak produk yang berbeda. Banyak dari mereka masih "hijau", dengan beberapa pengguna serius atau kasus sukses. Beberapa proyek lain, di sisi lain, telah ditinggalkan, karena tidak ada pengelola yang aktif.

Untuk informasi lebih lanjut tentang alat yang tersedia, silakan merujuk ke:Blog:Solusi HA Pengelompokan PG Teratas untuk PostgreSQL.

Penyeimbangan Beban dan Penyatuan Koneksi

Ada beberapa alat penyeimbang beban yang dapat digunakan untuk mengelola lalu lintas dari aplikasi Anda untuk mendapatkan hasil maksimal dari arsitektur database Anda. Dengan cara yang sama, ada beberapa lainnya yang dapat membantu Anda mengelola cara aplikasi terhubung ke database, dengan menggabungkan koneksi ini dan menggunakannya kembali di antara permintaan yang berbeda.

Ada beberapa produk yang digunakan untuk kedua tujuan tersebut, seperti pgpool yang terkenal, dan beberapa lainnya yang hanya akan fokus pada salah satu fitur ini, seperti pgbouncer (pengumpulan koneksi) dan HAProxy (digunakan untuk penyeimbangan beban).