KAL
Menu

Pengenalan replikasi

Memahami streaming replication dan posisi PITR pada strategi ketersediaan.

Daftar isi

Topik ini memperkenalkan replikasi sebagai fondasi ketersediaan, yaitu penyalinan perubahan dari satu server utama ke server penggantinya secara terus-menerus. Pembahasan mencakup streaming replication fisik, perannya dalam pemulihan titik waktu, dan batas yang membuat keputusannya disengaja, tanpa menyiapkan kluster sungguhan.

Blok penyiapan dataset#

bash 
# server tunggal yang diamati untuk tanda-tanda replikasi
PGOPTIONS='-c client_min_messages=warning' psql -q -U postgres -d perpustakaan <<'SQL'
DROP TABLE IF EXISTS peminjaman, buku, anggota, kategori CASCADE;
CREATE TABLE kategori (id SERIAL PRIMARY KEY, nama TEXT NOT NULL UNIQUE);
CREATE TABLE anggota (id SERIAL PRIMARY KEY, nama TEXT NOT NULL, email TEXT UNIQUE, bergabung DATE NOT NULL, aktif BOOLEAN NOT NULL DEFAULT TRUE);
CREATE TABLE buku (id SERIAL PRIMARY KEY, judul TEXT NOT NULL, penulis TEXT NOT NULL, tahun INTEGER NOT NULL, kategori_id INTEGER REFERENCES kategori(id));
CREATE TABLE peminjaman (id SERIAL PRIMARY KEY, anggota_id INTEGER NOT NULL REFERENCES anggota(id), buku_id INTEGER NOT NULL REFERENCES buku(id), tanggal_pinjam DATE NOT NULL, tanggal_kembali DATE);
INSERT INTO kategori (nama) VALUES ('Pemrograman'), ('Sains'), ('Sejarah'), ('Fiksi'), ('Statistika');
INSERT INTO anggota (nama, email, bergabung, aktif) VALUES ('Ali Rahman', '[email protected]', '2024-01-15', TRUE), ('Budi Santoso', '[email protected]', '2024-03-02', TRUE), ('Citra Kirana', '[email protected]', '2024-05-20', FALSE), ('Dewi Lestari', '[email protected]', '2024-08-11', TRUE), ('Eka Pratama', NULL, '2025-01-30', TRUE);
INSERT INTO buku (judul, penulis, tahun, kategori_id) VALUES ('Dasar Basis Data', 'Sari Wulandari', 2021, 1), ('Jaringan Komputer', 'Ahmad Fauzi', 2019, 1), ('Fisika untuk Pemula', 'Rina Marlina', 2020, 2), ('Kimia Organik', 'Rina Marlina', 2022, 2), ('Sejarah Nusantara', 'Bambang Wijaya', 2018, 3), ('Cerita Kota Lama', 'Nur Aisyah', 2023, 4), ('Statistika Terapan', 'Sari Wulandari', 2022, 5), ('Algoritma dan Struktur Data', 'Ahmad Fauzi', 2021, 1);
INSERT INTO peminjaman (anggota_id, buku_id, tanggal_pinjam, tanggal_kembali) VALUES (1, 1, '2025-03-01', '2025-03-15'), (1, 7, '2025-03-05', '2025-03-20'), (2, 3, '2025-03-10', NULL), (3, 5, '2025-02-20', '2025-03-01'), (2, 1, '2025-04-02', NULL), (4, 6, '2025-04-07', NULL), (5, 8, '2025-04-09', '2025-04-25'), (4, 2, '2025-05-01', NULL);
SQL

Server tunggal pada latihan ini cukup untuk membaca penanda arsitekturnya, karena pertanyaan pertama setiap administrasi adalah memastikan keadaan server yang sedang dihadapi.

Membaca peran server yang sedang dihadapi#

Dua pernyataan menegaskan peran server, yaitu pg_is_in_recovery() yang menyatakan apakah server berjalan sebagai pengganti, dan wal_level yang menyatakan kesiapan server utama mengalirkan perubahannya. Blok berikut membaca keduanya pada server tunggal ini.

bash 
# peran server dan kesiapan alirannya
psql -U postgres -d perpustakaan -c "SELECT pg_is_in_recovery() AS sedang_pulih;"
psql -U postgres -d perpustakaan -c "SHOW wal_level;"
text Keluaran 
 sedang_pulih
--------------
 f
(1 row)

 wal_level
-----------
 replica
(1 row)

Nilai salah pada fungsi pertama menegaskan server ini utama, sedangkan wal_level bernilai replica menjadi bawaan yang sudah siap mengalirkan perubahan ke penggantinya tanpa penyetelan tambahan. Setiap perubahan pada server direkam ke write-ahead log sebagaimana dibahas pada jaminan durability, dan replikasi fisik pada intinya adalah pengiriman catatan log itu ke server lain yang memainkannya ulang.

Streaming replication dan perannya#

Streaming replication mengirim catatan WAL dari utama ke standby seiring perubahan terjadi, sehingga standby memainkan ulang perubahan yang sama dan tetap selangkah di belakang. Penyiapannya berpola baku, yaitu menyalin kluster utama melalui pg_basebackup, menandai salinannya dengan berkas standby.signal, dan mengarahkan primary_conninfo ke utama.

Blok berikut menggambarkan rangkaiannya tanpa dijalankan, karena penyiapan standby menuntut folder kluster kedua dan koneksi antar server yang tidak tersedia pada lingkungan latihan ini.

bash 
# tidak-dijalankan (menuntut kluster kedua dan koneksi antar server)
# rangkaian menyiapkan standby dari utama
pg_basebackup -U postgres -D /tmp/standby -Fp -Xs -R
# berkas standby.signal dan primary_conninfo dibuat oleh flag -R secara otomatis

Flag -R pada pg_basebackup menuliskan konfigurasinya sekaligus, sehingga folder hasilnya langsung siap dimulai sebagai standby. Kesehatan aliran terbaca dari tampilan pg_stat_replication di sisi utama, dan blok berikut menegaskan bahwa server tunggal tidak memiliki pengganti yang tersambung, pembacaan yang tetap di lingkungan mana pun.

bash 
# daftar standby yang tersambung pada server tunggal
psql -U postgres -d perpustakaan -c "SELECT COUNT(*) AS standby_tersambung FROM pg_stat_replication;"
text Keluaran 
 standby_tersambung
--------------------
                  0
(1 row)

Teguhnya pemutusan antara utama dan standby diatur synchronous_commit, yaitu seberapa lama utama menunggu standby sebelum menyatakan COMMIT berhasil. Pilihannya merupakan pertukaran antara kepastian dan kecepatan yang disengaja per aplikasi.

Replikasi logis sebagai pembanding#

Replikasi fisik menyalin kluster seutuhnya pada tingkat berkas, sedangkan replikasi logis mengirim perubahan pada tingkat tabel dan dapat menyaring antar basis data, keunggulan yang dipakai untuk pembaruan besar versi tanpa henti dan untuk pertukaran antar kluster. Dua bentuk ini saling melengkapi, yaitu fisik untuk ketersediaan dan pemulihan, logis untuk perpindahan serta integrasi, dan keputusannya mengikuti masalah yang dijawab.

Sebelum menyentuh keduanya, satu hal perlu dipahami dari pembahasan WAL sebelumnya, yaitu slot replikasi yang menjaga WAL agar tidak terpotong. Slot yang terlupakan di sisi pengganti yang mati membuat WAL menumpuk hingga disk utama penuh, dan jebakan operasional inilah yang paling sering muncul.

PITR dalam strategi pemulihan#

Pemulihan titik waktu (point-in-time recovery) menggabungkan cadangan fisik pg_basebackup dengan arsip WAL yang berkelanjutan, sehingga kluster dipulihkan ke detik mana pun sebelum insiden, termasuk detik sebelum kesalahan penghapusan terjadi. Arsip WAL dikonfigurasi melalui archive_mode dan archive_command, dan pemulihannya menyatakan target waktunya pada recovery_target_time.

Strategi pemulihan yang utuh tersusun dari tiga lapis. Lapis pertama adalah cadangan logis harian dari pg_dump untuk granularitas per objek, lapis kedua adalah cadangan fisik berkala dari pg_basebackup sebagai fondasinya, dan lapis ketiga adalah arsip WAL yang mengisi jeda antar cadangan fisik. Latihan pemulihannya menjadi bagian tetap prosedur, sebagaimana ditegaskan pada topik backup.

Kesalahan umum#

Kesalahan pertama adalah mengira standby menggantikan cadangan, karena penghapusan pada utama tersalin ke standby seketika, dan pemulihan titik waktu tetap menjadi satu-satunya jawaban atas kesalahan logika. Kesalahan kedua adalah membiarkan slot replikasi pada standby yang mati, yang menahan WAL dan memenuhi disk utama, dan pemantauan slot menjadi bagian dari monitoring.

Kesalahan ketiga adalah menganggap replikasi sinkron tanpa memeriksa synchronous_commit, karena bawaannya asinkron dan jendela kehilangan transaksinya nyata. Kesalahan keempat adalah menyiapkan standby tanpa latihan promosinya, karena pemindahan peran utama adalah prosedur yang harus lancar sebelum insiden, bukan sesudahnya.

Ringkasan#

  • Streaming replication mengirim WAL dari utama ke standby, dan pg_is_in_recovery menegaskan peran server yang dihadapi.
  • wal_level replica adalah bawaan yang siap mengalirkan, dan pg_stat_replication memantau standby yang tersambung.
  • Replikasi fisik untuk ketersediaan, logis untuk seleksi tabel dan perpindahan versi, dan slotnya wajib dipantau.
  • PITR menyatukan cadangan fisik dengan arsip WAL untuk memulihkan detik tertentu, dan latihannya menjadi prosedur tetap.

Referensi#