Postgres hadir dengan fitur replikasi fisik dan logis. Baca terus untuk mempelajari lebih lanjut tentang berbagai aspek replikasi fisik.
Replikasi Fisik
Metode replikasi fisik digunakan untuk memelihara salinan lengkap dari seluruh data dari satu cluster (di Postgres, cluster adalah sekumpulan database yang dikelola oleh satu proses server Postgres utama yang disebut postmaster ), biasanya di mesin lain. Mesin sumber disebut primer dalam jargon Postgres, dan tujuannya disebut siaga .
Siaga Panas, Hangat, dan “Dingin”
Server siaga yang dijaga se-up-to-date mungkin dengan waktu-nyata utama dan memungkinkan klien untuk mengeksekusi transaksi hanya-baca disebut apanas standby, atau lebih populer replika baca . Siaga panas ditambahkan ke Postgres di versi 9, yang sebelumnya hanya ada hangat siaga. Warmstandby mirip dengan hot standby, kecuali bahwa itu tidak memungkinkan klien terhubung ke sana.
(Selain:Siaga panas tidak dapat menjalankan kueri yang membuat tabel sementara. Ini adalah batasan Postgres.)
Siaga "dingin" (bukan istilah resmi) biasanya merupakan server siaga yang tidak mulai hingga failover. Karena cold standby tidak aktif dan berjalan, mungkin pada saat startup aplikasi harus menerapkan perubahan tertunda terlebih dahulu sebelum dapat mulai menerima koneksi klien.
File WAL
Dalam operasi normal, server PostgreSQL menghasilkan serangkaian catatan WAL (write forward log) yang terurut. Ini pada dasarnya adalah log perubahan, mirip dengan AOF Redis atau binlog MySQL. Pada intinya, replikasi fisik adalah pengangkutan catatan-catatan ini ke komputer lain, dan membuat postmaster lain yang berjalan di sana untuk menerima dan menerapkan catatan-catatan ini ke dalam database lokalnya.
Catatan WAL dipotong menjadi file berukuran sama (biasanya 16 MB) yang disebutsegmen WAL atau hanya file WAL . File-file ini dibuat dalam direktori bernama pg_wal di bawah direktori data cluster (pg_wal disebut pg_xlog dalam versi Postgres sebelum 10). File WAL lama dibuang saat tidak diperlukan lagi (dan juga berdasarkan beberapa parameter konfigurasi).
Mode Pemulihan
Postmaster dapat dijalankan dalam mode yang disebut mode pemulihan , dengan menempatkan file konfigurasi yang tidak valid bernama recovery.conf di direktori data cluster. Dalam mode pemulihan, Postgres hanya akan mengimpor dan menerapkan file WAL yang dihasilkan oleh server utama, dan dengan sendirinya tidak akan menghasilkan file WAL apa pun. Server yang hangat dan siaga berjalan dalam mode pemulihan.
Saat memulai dalam mode pemulihan, Postgres pertama-tama akan mencoba mengimpor semua file WAL yang tersedia di arsip (lebih dari ini di bawah). Ketika arsip tidak memiliki file WAL lagi untuk ditawarkan, ia mencoba mengimpor file apa pun yang ada di sekitar pg_wal ini direktori. Ketika itu juga selesai, jika koneksi utama dikonfigurasi dan mode_siaga disetel ke on di recovery.conf, Postgres akan terhubung ke primer dan menarik serta menerapkan catatan WAL baru saat dibuat di primer.
Log Pengiriman
Bayangkan memiliki pemicu yang akan dipanggil di server utama setiap kali file WAL baru dibuat. Pemicu ini kemudian dapat menyalin file WAL baru ke mesin lain menggunakan katakanlah rsync , dan letakkan di pg_wal direktori postmaster yang berjalan dalam mode pemulihan. Bisakah kamu membuat standby seperti ini?
Jawabannya adalah ya, dan memang ini adalah praktik standar sebelum streamingreplikasi ditambahkan di Postgres v9. Praktik ini disebut pengiriman log .
Pemicunya adalah skrip shell, yang dapat dikonfigurasi menggunakan archive_command. Nama dan jalur file WAL dapat diteruskan ke skrip.
Pengarsipan WAL
Alih-alih menyinkronkan file WAL, katakanlah kita menyalinnya ke bucket S3 atau direktori terpasang NFS yang juga dapat diakses dari mesin siaga. Lokasi bersama ini sekarang akan berisi semua file WAL yang dihasilkan oleh primer. Ini sekarang menjadi arsip , dan proses menyimpan file WAL ke dalam arsip disebut pengarsipan berkelanjutan atau cukup pengarsipan WAL .
Kebalikan dari operasi ini – mengambil file WAL dari arsip ke dalam mode pemulihan Postgres – dapat dikonfigurasi menggunakan restore_command. Mirip dengan archive_command , ini juga merupakan jalur ke skrip shell. Postmaster yang berjalan dalam mode pemulihan, mengetahui file WAL mana yang diinginkannya. Nama file dapat diteruskan ke skrip.
Sebagai contoh, berikut adalah perintah arsip dan pemulihan untuk menyimpan dan mengambil file WAL ke dan dari bucket S3:
archive_command = 's3cmd put %p s3://BUCKET/path/%f' # in postgresql.conf
restore_command = 's3cmd get s3://BUCKET/path/%f %p' # in recovery.conf
Saat memulai dalam mode pemulihan, jika restore_command dikonfigurasi, Postgres akan mencoba mengambil file WAL dari arsip terlebih dahulu.
pg_standby
Dalam mode pemulihan, Postgres tidak, dan tidak dapat, mengetahui sebelumnya berapa banyak file WAL yang telah dihasilkan sejauh ini. Jika restore_command dikonfigurasi, Postgres akan berulang kali memanggilnya dengan nama file WAL progresif (nama berada dalam urutan yang dapat diprediksi) hingga perintah mengembalikan kesalahan.
Misalnya, perintah pemulihan dapat memenuhi permintaan untuk file WAL000000010000000000000001 melalui 00000001000000000000001A tetapi gagal untuk00000001000000000000001B karena tidak ditemukan di lokasi arsip. Dengan tidak adanya file WAL dari sumber lain, Postgres akan menganggap bahwa file WAL 00000001000000000000001B belum dihasilkan oleh primer, dan akan menyelesaikan pemulihan setelah menerapkan 00000001000000000000001A .
Pertimbangkan apa yang terjadi jika perintah pemulihan menunggu file00000001000000000000001B tersedia, daripada keluar dengan kesalahan karena tidak ditemukan. Postgres akan terus menunggu perintah pemulihan, dan oleh karena itu akan terus berada dalam mode pemulihan.
Ini adalah konfigurasi yang valid, dan cara yang valid untuk menyiapkan warm standby.
Postgres dikirimkan dengan perintah yang disebut pg_standby, yang dapat digunakan untuk menyiapkan warm standby dengan cara ini, selama arsipnya adalah direktori.pg_standby akan menunggu file tersedia, jika tidak dapat ditemukan.
Perintah arsip dan pulihkan menggunakan pg_standby akan terlihat seperti ini:
archive_command = 'cp %p /some/path/%f' # in postgresql.conf
restore_command = 'pg_standby /some/path %f %p' # in recovery.confReplikasi Streaming
Setelah memproses file WAL yang diarsipkan serta file di pg_wal direktori, Postgres dapat terhubung ke server utama melalui jaringan dan berulang kali mengambil dan menerapkan file WAL baru saat dibuat. Fitur ini, ditambahkan di Postgres 9, disebut replikasi streaming .
Server utama untuk terhubung dapat ditentukan dalam file recovery.conf:
# recovery.conf
standby_mode = on
primary_conninfo = 'host=10.0.1.10 user=repl password=p@ssw0rd'Siaga Panas
Secara default, ketika dalam mode pemulihan, Postgres tidak akan menerima koneksi klien, menolaknya dengan pesan kesalahan "sistem database dalam mode pemulihan". Dengan menambahkan baris hot_standby = on di recovery.conf, Anda dapat membuat koneksi klien Postgresaccept dan mengizinkan mereka untuk mengeksekusi transaksi hanya-baca:
# recovery.conf
hot_standby = onBiasanya tidak ada alasan untuk menonaktifkan hot_standby.
Dokumen PostgreSQL memiliki info lebih lanjut tentang menyiapkan dan menjalankan standby dalam mode “hot standby”.
Slot Replikasi
Slot replikasi diperkenalkan di Postgres 9.4. Mereka adalah mekanisme untuk secara akurat dan tahan lama melacak seberapa jauh siaga tertinggal di belakang utama. Ini memungkinkan yang utama untuk memastikan bahwa file WAL yang masih diperlukan untuk siaga untuk mengejar tidak dihapus.
Sebelum slot replikasi, primer tidak dapat menentukan ini, dan Anda akan berakhir dalam situasi di mana standby dibiarkan terdampar karena file WAL yang diperlukan telah dihapus oleh primer. Tentu saja, arsip WAL dapat memperbaiki masalah ini. Namun, tanpa arsip WAL, satu-satunya pilihan adalah membangun kembali siaga dari cadangan baru.
Anda dapat membaca lebih lanjut tentang slot replikasi di sini.
Langkah-langkah untuk Menyiapkan Siaga Panas
Mari kita lihat langkah-langkah yang diperlukan untuk menyiapkan hot standby untuk primer yang sudah ada.
1. Buat Pengguna Replikasi
Pertama, kita membutuhkan pengguna untuk standby untuk terhubung sebagai:
$ psql -p 6000
psql (11.2 (Debian 11.2-1.pgdg90+1))
Type "help" for help.
postgres=# CREATE USER repluser REPLICATION PASSWORD 'p@ssw0rd';
CREATE USER
Dan perubahan yang sesuai di pg_hba.conf :
# TYPE DATABASE USER ADDRESS METHOD
host replication repluser standby-ip/32 md5
# (replace standby-ip)Anda tentu saja dapat menggunakan mekanisme otentikasi standar PostgreSQL. Pengguna harus memiliki hak replikasi dan login dan tidak memerlukan akses ke database tertentu.
Pastikan untuk memuat ulang server utama agar perubahan pada pg_hba.conf dapat diterapkan.
2. Ambil Cadangan
Siaga harus dimulai dari cadangan primer. Anda dapat, dan harus, melakukan ini menggunakan pg_basebackup dengan slot replikasi baru:
pg_basebackup -h primary-ip -p 6000 -U repluser -C -S slot_standby1 -R -D standby
Ini terhubung ke primer di primary-ip:6000 dengan pengguna yang baru saja kita buat dan mengambil cadangannya ke dalam direktori standby . Slot replikasi baruslot_standby1 dibuat.
3. Tambahkan recovery.conf Dalam Siaga
Kami akan menggunakan slot ini sebagai slot replikasi siaga kami, sehingga ada kesinambungan dari cadangan.
Kami telah meminta pg_basebackup untuk membuat recovery.conf untuk kita di atas ("-R"option). Mari kita lihat itu:
$ cat standby/recovery.conf
standby_mode = 'on'
primary_conninfo = 'user=repluser password=''p@ssw0rd'' host=primary-ip port=6000 sslmode=prefer sslcompression=0 krbsrvname=postgres target_session_attrs=any'
primary_slot_name = 'slot_standby1'Itu sebenarnya cukup bagus, dan kita tidak perlu memodifikasinya lebih jauh. Mari kita siapkan standby sekarang:
o$ pg_ctl -D standby -l log_standby -o --port=6001 start
waiting for server to start.... done
server started
postgres@stg1:/tmp/demo$ cat log_standby
2019-06-19 09:17:50.032 UTC [21733] LOG: listening on IPv4 address "127.0.0.1", port 6001
2019-06-19 09:17:50.034 UTC [21733] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.6001"
2019-06-19 09:17:50.067 UTC [21734] LOG: database system was interrupted; last known up at 2019-06-19 09:12:05 UTC
2019-06-19 09:17:50.111 UTC [21734] LOG: entering standby mode
2019-06-19 09:17:50.119 UTC [21734] LOG: redo starts at 0/2000028
2019-06-19 09:17:50.120 UTC [21734] LOG: consistent recovery state reached at 0/20000F8
2019-06-19 09:17:50.120 UTC [21733] LOG: database system is ready to accept read only connections
2019-06-19 09:17:50.138 UTC [21739] LOG: started streaming WAL from primary at 0/3000000 on timeline 1Dan itu saja! File log menunjukkan bahwa replikasi streaming aktif dan berjalan. Anda sekarang seharusnya dapat terhubung ke standby di port 6001, kueri runread-only dan melihat perubahan direplikasi dari yang utama lebih atau kurang secara real-time.
Langkah Selanjutnya
PostgreSQLdocs adalah tempat yang tepat untuk mulai menggali lebih jauh ke dalam semua fitur Postgres yang terkait dengan replikasi. Anda sebaiknya mempelajari topik-topik seperti replikasi tertunda, replikasi berjenjang, siaga sinkron, dan banyak lagi.
Meskipun Postgres hadir dengan serangkaian fitur yang mengesankan, masih ada kasus penggunaan yang tidak didukung. Halaman wiki Postgres ini memiliki daftar alat pihak ketiga yang menyediakan fungsionalitas terkait replikasi tambahan.
