Dalam entri blog ini, kita akan membahas lebih dalam tentang penyiapan Streaming Replication (SR) di PostgreSQL. Replikasi streaming adalah elemen dasar untuk mencapai ketersediaan tinggi di hosting PostgreSQL Anda, dan dihasilkan dengan menjalankan konfigurasi master-slave.

Terminologi Master-Slave

Server Utama/Primer

• Server yang dapat melakukan penulisan.
• Juga disebut server baca/tulis.

Server Budak/Siaga

• Server tempat data tetap sinkron dengan master terus menerus.
• Juga disebut server cadangan atau replika.
• Server siaga hangat adalah server yang tidak dapat dihubungkan sampai dipromosikan menjadi server master.
• Sebaliknya, server siaga panas dapat menerima koneksi dan melayani kueri hanya-baca. Untuk sisa diskusi ini, kami hanya akan fokus pada server siaga panas.

Data ditulis ke server master dan disebarkan ke server slave. Jika ada masalah dengan server master yang ada, salah satu server slave akan mengambil alih dan terus melakukan penulisan untuk memastikan ketersediaan sistem.

Replikasi Berbasis Pengiriman WAL

Apa itu WAL?

• WAL adalah singkatan dari Write-Ahead Logging.
• Ini adalah file log tempat semua modifikasi database ditulis sebelum diterapkan/ditulis ke file data.
• WAL digunakan untuk pemulihan setelah database crash, memastikan integritas data.
• WAL digunakan dalam sistem database untuk mencapai atomisitas dan daya tahan.

Bagaimana WAL Digunakan Untuk Replikasi?

Catatan log write-ahead digunakan untuk menjaga agar data tetap sinkron antara server database. Ini dicapai dengan dua cara:

Pengiriman Log Berbasis File

• File log WAL dikirimkan dari master ke server standby untuk menjaga sinkronisasi data.
• Master dapat langsung menyalin log ke penyimpanan server siaga atau dapat berbagi penyimpanan dengan server siaga.
• Satu file log WAL dapat berisi hingga 16 MB data.
• File WAL dikirim hanya setelah mencapai ambang batas tersebut.
• Ini akan menyebabkan penundaan replikasi dan juga meningkatkan kemungkinan kehilangan data jika master mogok dan log tidak diarsipkan

Streaming Rekaman WAL

• Potongan catatan WAL dialirkan oleh server database untuk menjaga sinkronisasi data.
• Server siaga terhubung ke master untuk menerima potongan WAL.
• Data WAL dialirkan saat dibuat.
• Streaming catatan WAL tidak perlu menunggu file WAL diisi.
• Ini memungkinkan server siaga untuk tetap lebih mutakhir daripada yang dimungkinkan dengan pengiriman log berbasis file.
• Secara default, replikasi streaming tidak sinkron meskipun juga mendukung replikasi sinkron.

Kedua metode tersebut memiliki kelebihan dan kekurangannya masing-masing. Menggunakan pengiriman berbasis file memungkinkan pemulihan tepat waktu dan pengarsipan berkelanjutan, sementara streaming memastikan ketersediaan data langsung di server siaga. Namun, Anda dapat mengonfigurasi PostgreSQL untuk menggunakan kedua metode secara bersamaan dan menikmati manfaatnya. Di blog ini, kami berkonsentrasi terutama pada replikasi streaming untuk mencapai ketersediaan tinggi PostgreSQL.

Bagaimana Cara Mengatur Replikasi Streaming?

Menyiapkan replikasi streaming di PostgreSQL sangat sederhana. Dengan asumsi PostgreSQL sudah terinstal di semua server, Anda dapat mengikuti langkah-langkah berikut untuk memulai:

Konfigurasi pada Master Node

• Inisialisasi database pada master node menggunakan utilitas initdb.
• Buat peran/pengguna dengan hak replikasi dengan menjalankan perintah di bawah ini. Setelah menjalankan perintah, Anda dapat memverifikasinya dengan menjalankan \du untuk mencantumkannya di psql.
  •   BUAT PENGGUNA REPLICATION LOGIN PASSWORD '';
• Konfigurasikan properti yang terkait dengan replikasi streaming di file master konfigurasi PostgreSQL (postgresql.conf):
  

  # Nilai yang mungkin adalah replika|minimal|logis wal_level =replica# diperlukan untuk kemampuan pg_rewind saat standby tidak sinkron dengan master wal_log_hints =on# menyetel jumlah maksimum koneksi serentak dari server siaga. max_wal_senders =3 # Parameter di bawah ini digunakan untuk memberitahu master untuk menyimpan jumlah minimum # segmen log WAL sehingga tidak terhapus sebelum standby mengkonsumsinya. # setiap segmen 16 MB wal_keep_segments =8 # Parameter di bawah ini memungkinkan koneksi hanya baca pada node saat berada dalam # peran standby. Ini diabaikan saat server berjalan sebagai master. hot_standby =pada

• Tambahkan entri replikasi dalam file pg_hba.conf untuk mengizinkan koneksi replikasi antara server:
  

  # Izinkan koneksi replikasi dari localhost, # oleh pengguna dengan hak istimewa replikasi. # TYPE    DATABASE    USER    ALAMAT    METODE host    replikasi    repl_user    IPaddress(CIDR)    md5

• Mulai ulang layanan PostgreSQL pada master node agar perubahan diterapkan.

Konfigurasi pada Simpul Siaga

• Buat cadangan dasar node master menggunakan utilitas pg_basebackup dan gunakan sebagai titik awal untuk standby.
  

  # Menjelaskan beberapa opsi yang digunakan untuk utilitas pg_basebackup # Opsi -X digunakan untuk menyertakan file log transaksi yang diperlukan (file WAL) di # backup. Saat Anda menentukan aliran, ini akan membuka koneksi kedua ke server # dan mulai mengalirkan log transaksi pada saat yang sama saat menjalankan pencadangan. # -c adalah opsi pos pemeriksaan. Menyetelnya ke fast akan memaksa checkpoint untuk # segera dibuat. # -W memaksa pg_basebackup untuk meminta kata sandi sebelum menghubungkan # ke database. pg_basebackup -D  -h -X stream -c fast -U repl_user -W

• Buat file konfigurasi replikasi jika tidak ada (dibuat secara otomatis jika opsi -R disediakan di pg_basebackup):
  

  # Menentukan apakah akan memulai server sebagai sebuah siaga. Dalam replikasi streaming, # parameter ini harus disetel ke aktif. standby_mode ='on'# Menentukan string koneksi yang digunakan untuk server siaga untuk terhubung # dengan primer/master. primary_conninfo =‘host= port= user= password= application_name=”host_name”’# Menentukan pemulihan ke timeline tertentu. Standarnya adalah memulihkan di sepanjang # garis waktu yang sama dengan saat ini saat pencadangan dasar diambil. # Menyetel ini ke pemulihan terbaru ke garis waktu terbaru yang ditemukan # di arsip, yaitu berguna di server siaga. recovery_target_timeline ='terbaru'

• Mulai siaga.

Konfigurasi standby harus dilakukan di semua server standby. Setelah konfigurasi selesai dan standby dimulai, itu akan terhubung ke master dan memulai streaming log. Ini akan mengatur replikasi dan dapat diverifikasi dengan menjalankan pernyataan SQL “SELECT * FROM pg_stat_replication; “.

Secara default, replikasi streaming tidak sinkron. Jika Anda ingin membuatnya sinkron, Anda dapat mengonfigurasinya menggunakan parameter berikut:

Synchronous_commit harus disetel ke aktif untuk replikasi sinkron dan ini adalah default. PostgreSQL menyediakan opsi yang sangat fleksibel untuk komit sinkron dan dapat dikonfigurasi pada tingkat pengguna/database. Nilai yang valid adalah sebagai berikut:

• Nonaktif – Komitmen transaksi diakui ke klien bahkan sebelum catatan transaksi tersebut benar-benar di-flush ke file log WAL pada node tersebut.
• Lokal –  Komit transaksi diakui ke klien hanya setelah catatan transaksi tersebut dimasukkan ke dalam file log WAL pada node tersebut.
• Tulis_Jarak Jauh – Komit transaksi diakui ke klien hanya setelah server yang ditentukan oleh synchronous_standby_names mengonfirmasi bahwa catatan transaksi ditulis ke cache disk, tetapi tidak harus setelah di-flush ke file log WAL.
• Aktif – Komit transaksi diakui ke klien hanya setelah server yang ditentukan oleh synchronous_standby_names mengonfirmasi bahwa catatan transaksi di-flush ke file log WAL.
• Remote_apply – Komit transaksi diakui ke klien hanya setelah server yang ditentukan oleh synchronous_standby_names mengonfirmasi bahwa catatan transaksi di-flush ke file log WAL dan diterapkan ke database.

Menyetel synchronous_commit ke nonaktif atau lokal dalam mode replikasi sinkron akan membuatnya berfungsi seperti asinkron, dan dapat membantu Anda mencapai performa tulis yang lebih baik. Namun, ini akan memiliki risiko kehilangan data dan penundaan baca yang lebih tinggi di server siaga. Jika disetel ke remote_apply, ini akan memastikan ketersediaan data langsung di server siaga, tetapi kinerja tulis mungkin menurun karena harus diterapkan pada semua/yang disebutkan server siaga.

Anda dapat mengaktifkan mode arsip jika Anda berencana untuk menggunakan pengarsipan berkelanjutan dan pemulihan tepat waktu. Meskipun tidak wajib untuk replikasi streaming, mengaktifkan mode arsip memiliki manfaat tambahan. Jika mode arsip tidak aktif, maka kita perlu menggunakan slot replikasi menampilkan atau memastikan bahwa wal_keep_segments nilai ditetapkan cukup tinggi berdasarkan beban.

Lihat presentasi yang luar biasa ini untuk mengetahui detail lebih lanjut tentang ketersediaan tinggi di PostgreSQL. Dalam postingan blog kami berikutnya, kami akan memperkenalkan Anda ke dunia alat yang digunakan untuk mengelola ketersediaan tinggi untuk PostgreSQL menggunakan replikasi streaming.