Replikasi Streaming PostgreSQL - Penyelaman Mendalam

Pengetahuan tentang replikasi adalah suatu keharusan bagi siapa saja yang mengelola database. Ini adalah topik yang mungkin telah Anda lihat berulang kali tetapi tidak pernah ketinggalan zaman. Di blog ini, kami akan meninjau sedikit sejarah fitur replikasi bawaan PostgreSQL dan mempelajari lebih dalam cara kerja replikasi streaming.

Ketika berbicara tentang replikasi, kita akan berbicara banyak tentang WAL. Jadi, mari kita tinjau sedikit tentang log write-ahead.

Log Tulis Sebelumnya (WAL)

A Write-Ahead Log adalah metode standar untuk memastikan integritas data, dan secara otomatis diaktifkan secara default.

WAL adalah log REDO di PostgreSQL. Tapi apa sebenarnya log REDO itu?

REDO log berisi semua perubahan yang dibuat dalam database, dan digunakan untuk replikasi, pemulihan, pencadangan online, dan pemulihan point-in-time (PITR). Setiap perubahan yang belum diterapkan pada halaman data dapat dilakukan kembali dari log REDO.

Menggunakan WAL menghasilkan pengurangan jumlah penulisan disk yang signifikan karena hanya file log yang perlu di-flush ke disk untuk menjamin bahwa transaksi dilakukan, daripada setiap file data diubah oleh transaksi.

Catatan WAL akan menentukan perubahan yang dibuat pada data, sedikit demi sedikit. Setiap catatan WAL akan ditambahkan ke dalam file WAL. Posisi insert adalah Log Sequence Number (LSN), offset byte ke dalam log, meningkat dengan setiap record baru.

WAL disimpan di direktori pg_wal (atau pg_xlog dalam versi PostgreSQL <10) di bawah direktori data. File-file ini memiliki ukuran default 16MB (Anda dapat mengubah ukurannya dengan mengubah opsi konfigurasi --with-wal-segsize saat membangun server). Mereka memiliki nama tambahan yang unik dalam format berikut:"00000001 00000000 00000000".

Jumlah file WAL yang terdapat dalam pg_wal akan bergantung pada nilai yang ditetapkan ke parameter checkpoint_segments (atau min_wal_size dan max_wal_size, tergantung pada versinya) dalam file konfigurasi postgresql.conf.

Salah satu parameter yang perlu Anda siapkan saat mengonfigurasi semua instalasi PostgreSQL Anda adalah wal_level. Wal_level menentukan berapa banyak informasi yang ditulis ke WAL. Nilai defaultnya minimal, yang hanya menulis informasi yang diperlukan untuk memulihkan dari crash atau shutdown langsung. Arsip menambahkan pencatatan yang diperlukan untuk pengarsipan WAL; hot_standby selanjutnya menambahkan informasi yang diperlukan untuk menjalankan kueri hanya-baca di server siaga; logis menambahkan informasi yang diperlukan untuk mendukung decoding logis. Parameter ini memerlukan restart, sehingga akan sulit untuk mengubah database produksi yang sedang berjalan jika Anda lupa akan hal itu.

Untuk informasi lebih lanjut, Anda dapat memeriksa dokumentasi resmi di sini atau di sini. Sekarang setelah kita membahas WAL, mari kita tinjau riwayat replikasi di PostgreSQL.

Riwayat Replikasi di PostgreSQL

Metode replikasi pertama (warm standby) yang diterapkan PostgreSQL (versi 8.2, pada tahun 2006) didasarkan pada metode pengiriman log.

Ini berarti bahwa catatan WAL dipindahkan secara langsung dari satu server database ke server database lainnya untuk diterapkan. Kita dapat mengatakan bahwa itu adalah PITR berkelanjutan.

PostgreSQL mengimplementasikan pengiriman log berbasis file dengan mentransfer catatan WAL satu file (segmen WAL) pada satu waktu.

Implementasi replikasi ini memiliki kelemahan:jika ada kegagalan besar pada server utama, transaksi yang belum dikirimkan akan hilang. Jadi, ada jendela untuk kehilangan data (Anda dapat menyetelnya dengan menggunakan parameter archive_timeout, yang dapat disetel serendah beberapa detik. Namun, setelan rendah seperti itu akan secara substansial meningkatkan bandwidth yang diperlukan untuk pengiriman file).

Kami dapat merepresentasikan metode pengiriman log berbasis file ini dengan gambar di bawah ini:

Pengiriman log berbasis file PostgreSQL

Kemudian, di versi 9.0 (di tahun 2010) ), replikasi streaming diperkenalkan.

Replikasi streaming memungkinkan Anda untuk tetap lebih up-to-date daripada yang mungkin dilakukan dengan pengiriman log berbasis file. Ini bekerja dengan mentransfer catatan WAL (file WAL terdiri dari catatan WAL) dengan cepat (pengiriman log berbasis catatan) antara server utama dan satu atau beberapa 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.

Diagram berikut menunjukkan replikasi streaming:

Replikasi streaming PostgreSQL

Melihat diagram di atas, Anda mungkin bertanya-tanya, apa yang terjadi ketika komunikasi antara pengirim WAL dan penerima WAL gagal?

Saat mengonfigurasi replikasi streaming, Anda memiliki opsi untuk mengaktifkan pengarsipan WAL.

Langkah ini tidak wajib tetapi sangat penting untuk penyiapan replikasi yang kuat. Penting untuk menghindari server utama mendaur ulang file WAL lama yang belum diterapkan ke server siaga. Jika ini terjadi, Anda harus membuat ulang replika dari awal.

Saat mengonfigurasi replikasi dengan pengarsipan berkelanjutan, itu dimulai dari cadangan. Untuk mencapai status sinkron dengan yang utama, perlu menerapkan semua perubahan yang dihosting di WAL yang terjadi setelah pencadangan. Selama proses ini, standby terlebih dahulu akan mengembalikan semua WAL yang tersedia di lokasi arsip (dilakukan dengan memanggil restore_command). Restore_command akan gagal ketika mencapai catatan WAL terakhir yang diarsipkan, jadi setelah itu, standby akan melihat pada direktori pg_wal untuk melihat apakah ada perubahan di sana (ini berfungsi untuk menghindari kehilangan data saat server utama crash dan beberapa perubahan yang telah dipindahkan dan diterapkan ke replika belum diarsipkan).

Jika itu gagal dan catatan yang diminta tidak ada di sana, itu akan mulai berkomunikasi dengan server utama melalui replikasi streaming.

Setiap kali streaming replikasi gagal, itu akan kembali ke langkah 1 dan memulihkan catatan dari arsip lagi. Loop percobaan ulang ini dari arsip, pg_wal, dan melalui streaming replikasi berlanjut hingga server berhenti, atau failover dipicu oleh file pemicu.

Diagram berikut menunjukkan konfigurasi replikasi streaming dengan pengarsipan berkelanjutan:

Replikasi streaming PostgreSQL dengan pengarsipan berkelanjutan

Replikasi streaming tidak sinkron secara default, jadi pada setiap saat, Anda dapat memiliki beberapa transaksi yang dapat dilakukan ke server utama dan belum direplikasi ke server siaga. Ini menyiratkan beberapa potensi kehilangan data.

Namun, penundaan antara komit dan dampak perubahan pada replika ini seharusnya sangat kecil (beberapa milidetik), dengan asumsi, tentu saja, bahwa server replika cukup kuat untuk mengikuti beban.

Untuk kasus ketika risiko kehilangan data sedikit pun tidak dapat diterima, versi 9.1 memperkenalkan fitur replikasi sinkron.

Dalam replikasi sinkron, setiap komit dari transaksi tulis menunggu hingga konfirmasi diterima bahwa komit ditulis ke log tulis-depan pada disk dari server utama dan server siaga.

Metode ini meminimalkan kemungkinan kehilangan data; agar hal itu terjadi, Anda memerlukan primer dan siaga untuk gagal secara bersamaan.

Kelemahan yang jelas dari konfigurasi ini adalah waktu respons untuk setiap transaksi tulis meningkat, karena perlu menunggu hingga semua pihak merespons. Jadi, waktu untuk komit adalah, minimal, perjalanan pulang pergi antara primer dan replika. Transaksi read-only tidak akan terpengaruh oleh ini.

Untuk menyiapkan replikasi sinkron, Anda perlu menentukan application_name di primary_conninfo pemulihan untuk setiap file standby server.conf:primary_conninfo ='...aplication_name=standbyX' .

Anda juga perlu menentukan daftar server siaga yang akan mengambil bagian dalam replikasi sinkron:synchronous_standby_name ='standbyX,standbyY'.

Anda dapat menyiapkan satu atau beberapa server sinkron, dan parameter ini juga menentukan metode mana (PERTAMA dan APAPUN) untuk memilih siaga sinkron dari yang terdaftar. Untuk informasi selengkapnya tentang menyiapkan mode replikasi sinkron, lihat blog ini. Dimungkinkan juga untuk menyiapkan replikasi sinkron saat menerapkan melalui ClusterControl.

Setelah Anda mengonfigurasi replikasi dan sudah aktif serta berjalan, Anda perlu menerapkan pemantauan

Memantau Replikasi PostgreSQL

Tampilan pg_stat_replication di server master memiliki banyak informasi yang relevan:

postgres=# SELECT * FROM pg_stat_replication;
-[ RECORD 1 ]----+------------------------------
pid              | 756
usesysid         | 16385
usename          | cmon_replication
application_name | pgsql_0_node_0
client_addr      | 10.10.10.137
client_hostname  |
client_port      | 36684
backend_start    | 2022-04-13 17:45:56.517518+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/400001C0
write_lsn        | 0/400001C0
flush_lsn        | 0/400001C0
replay_lsn       | 0/400001C0
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 0
sync_state       | async
reply_time       | 2022-04-13 17:53:03.454864+00

Mari kita lihat detailnya:

pid:ID proses dari proses walsender.
usesysid:OID pengguna yang digunakan untuk replikasi streaming.
namapengguna:Nama pengguna yang digunakan untuk replikasi streaming.
application_name:Nama aplikasi terhubung ke master.
client_addr:Alamat replikasi standby/streaming.
client_hostname:Nama host standby.
client_port:nomor port TCP yang standby berkomunikasi dengan pengirim WAL.
backend_start:Waktu mulai saat PL terhubung ke Primer.
status:Status pengirim WAL saat ini, yaitu streaming.
sent_lsn:Lokasi transaksi terakhir dikirim ke standby.
write_lsn:Transaksi terakhir yang ditulis pada disk saat standby.
flush_lsn:Transaksi terakhir flush pada disk saat standby.
replay_lsn:Transaksi terakhir flush pada disk saat standby.
sync_priority:Prioritas server siaga yang dipilih sebagai siaga sinkron.
sync_state:Sinkronisasi Status siaga (apakah asinkron atau sinkron).

Anda juga dapat melihat proses pengirim/penerima WAL yang berjalan di server.

Pengirim (Node Utama):

[[email protected] ~]# ps aux |grep postgres
postgres     727  0.0  2.2 917060 47936 ?        Ss   17:45   0:00 /usr/pgsql-14/bin/postmaster -D /var/lib/pgsql/14/data/
postgres     732  0.0  0.2 351904  5280 ?        Ss   17:45   0:00 postgres: 14/main: logger
postgres     734  0.0  0.5 917188 10560 ?        Ss   17:45   0:00 postgres: 14/main: checkpointer
postgres     735  0.0  0.4 917208  9908 ?        Ss   17:45   0:00 postgres: 14/main: background writer
postgres     736  0.0  1.0 917060 22928 ?        Ss   17:45   0:00 postgres: 14/main: walwriter
postgres     737  0.0  0.4 917748  9128 ?        Ss   17:45   0:00 postgres: 14/main: autovacuum launcher
postgres     738  0.0  0.3 917060  6320 ?        Ss   17:45   0:00 postgres: 14/main: archiver last was 00000001000000000000003F
postgres     739  0.0  0.2 354160  5340 ?        Ss   17:45   0:00 postgres: 14/main: stats collector
postgres     740  0.0  0.3 917632  6892 ?        Ss   17:45   0:00 postgres: 14/main: logical replication launcher
postgres     756  0.0  0.6 918252 13124 ?        Ss   17:45   0:00 postgres: 14/main: walsender cmon_replication 10.10.10.137(36684) streaming 0/400001C0

Penerima (Simpul Siaga):

[[email protected] ~]# ps aux |grep postgres
postgres     727  0.0  2.2 917060 47576 ?        Ss   17:45   0:00 /usr/pgsql-14/bin/postmaster -D /var/lib/pgsql/14/data/
postgres     732  0.0  0.2 351904  5396 ?        Ss   17:45   0:00 postgres: 14/main: logger
postgres     733  0.0  0.3 917196  6360 ?        Ss   17:45   0:00 postgres: 14/main: startup recovering 000000010000000000000040
postgres     734  0.0  0.4 917060 10056 ?        Ss   17:45   0:00 postgres: 14/main: checkpointer
postgres     735  0.0  0.3 917060  6304 ?        Ss   17:45   0:00 postgres: 14/main: background writer
postgres     736  0.0  0.2 354160  5456 ?        Ss   17:45   0:00 postgres: 14/main: stats collector
postgres     737  0.0  0.6 924532 12948 ?        Ss   17:45   0:00 postgres: 14/main: walreceiver streaming 0/400001C0

Salah satu cara untuk memeriksa seberapa mutakhir replikasi Anda, adalah dengan memeriksa jumlah catatan WAL yang dihasilkan di server utama, tetapi belum diterapkan di server siaga.

Utama:

postgres=# SELECT pg_current_wal_lsn();
 pg_current_wal_lsn
--------------------
 0/400001C0
(1 row)

Siaga:

postgres=# SELECT pg_last_wal_receive_lsn();
 pg_last_wal_receive_lsn
-------------------------
 0/400001C0
(1 row)
postgres=# SELECT pg_last_wal_replay_lsn();
 pg_last_wal_replay_lsn
------------------------
 0/400001C0
(1 row)

Anda dapat menggunakan kueri berikut di node siaga untuk mendapatkan jeda dalam hitungan detik:

postgres=# SELECT CASE WHEN pg_last_wal_receive_lsn() = pg_last_wal_replay_lsn()
THEN 0
ELSE EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp())
END AS log_delay;
 log_delay
-----------
         0
(1 row)

Dan Anda juga dapat melihat pesan terakhir yang diterima:

postgres=# SELECT status, last_msg_receipt_time FROM pg_stat_wal_receiver;
  status   |    last_msg_receipt_time
-----------+------------------------------
 streaming | 2022-04-13 18:32:39.83118+00
(1 row)

Memantau Replikasi PostgreSQL dengan ClusterControl

Untuk memantau klaster PostgreSQL, Anda dapat menggunakan ClusterControl, yang memungkinkan Anda memantau dan melakukan beberapa tugas pengelolaan tambahan seperti penerapan, pencadangan, penskalaan, dan banyak lagi.

Di bagian ikhtisar, Anda akan memiliki gambaran lengkap tentang cluster database Anda status terkini. Untuk melihat detail lebih lanjut, Anda dapat mengakses bagian dasbor, tempat Anda akan melihat banyak informasi bermanfaat yang dipisahkan ke dalam grafik yang berbeda.

Di bagian topologi, Anda dapat melihat topologi Anda saat ini di pengguna- cara yang ramah, dan Anda juga dapat melakukan tugas yang berbeda pada node dengan menggunakan tombol Node Action.

Replikasi streaming didasarkan pada pengiriman data WAL dan menerapkannya ke standby server, itu menentukan byte apa yang akan ditambahkan atau diubah dalam file apa. Akibatnya, server siaga sebenarnya adalah salinan sedikit demi sedikit dari server utama. Namun, ada beberapa batasan yang terkenal di sini:

Anda tidak dapat mereplikasi ke versi atau arsitektur yang berbeda.
Anda tidak dapat mengubah apa pun di server siaga.
Anda tidak memiliki banyak rincian tentang apa yang Anda tiru.

Jadi, untuk mengatasi keterbatasan ini, PostgreSQL 10 telah menambahkan dukungan untuk replikasi logis

Replikasi Logis

Replikasi logis juga akan menggunakan informasi dalam file WAL, tetapi akan mendekodekannya menjadi perubahan logis. Alih-alih mengetahui byte mana yang berubah, ia akan mengetahui dengan tepat data apa yang telah dimasukkan ke dalam tabel mana.

Ini didasarkan pada model "terbitkan" dan "berlangganan" dengan satu atau lebih pelanggan berlangganan satu atau lebih publikasi pada simpul penerbit yang terlihat seperti ini:

Replikasi Logis PostgreSQL

Menutup

Dengan replikasi streaming, Anda dapat terus mengirimkan dan menerapkan catatan WAL ke server siaga Anda, memastikan bahwa informasi yang diperbarui di server utama ditransfer ke server siaga secara real-time, memungkinkan keduanya tetap sinkron .

ClusterControl mempermudah penyiapan replikasi streaming, dan Anda dapat mengevaluasinya secara gratis selama 30 hari.

Jika Anda ingin mempelajari lebih lanjut tentang replikasi logis di PostgreSQL, pastikan untuk membaca ikhtisar replikasi logis ini dan pos ini tentang praktik terbaik replikasi PostgreSQL.

Untuk kiat dan praktik terbaik lainnya untuk mengelola basis data berbasis sumber terbuka Anda, ikuti kami di Twitter dan LinkedIn, dan berlangganan buletin kami untuk pembaruan rutin.