Replikasi

Read replica dengan REPLICAOF: aliran data, pengujian keterlambatan, dan dasar failover.

Daftar isi

Replikasi menyalin setiap tulisan dari satu server master ke server lain yang disebut replica, sehingga data yang sama tersedia di lebih dari satu proses Redis. Topik ini membahas aliran data antara master dan replika, cara membentuk pasangan tersebut dengan perintah REPLICAOF, pengujian keterlambatan aliran tulis dengan WAIT, serta promosi replika menjadi master sebagai dasar failover. Seluruh percobaan dijalankan pada dua server terisolasi di port 6390 dan 6391 tanpa persistensi, sehingga setiap blok dapat diulang dari awal dengan keluaran yang sama.

Peran master dan replika#

Pada topologi replikasi, master menerima seluruh perintah tulis, sedangkan replika menyimpan salinan data dan melayani pembacaan. Aplikasi menulis ke master dan membagi beban baca ke replika, pola yang lazim disebut read replica. Aliran replikasi bersifat asinkron, artinya master tidak menunggu replika menerima tulisan sebelum membalas klien, sehingga replika dapat tertinggal beberapa milidetik dari master.

Hubungan dibentuk saat runtime dengan perintah REPLICAOF pada server yang akan menjadi replika. Server itu membuka koneksi ke master, mengirim perintah PSYNC untuk meminta sinkronisasi awal, lalu menerima snapshot data berupa berkas RDB, dan setelah itu menerima aliran perintah tulis yang sama persis dengan yang diterima master. Perintah ROLE melaporkan peran server saat ini, yaitu master atau slave, beserta status koneksi replikasinya. Diagram berikut merangkum alur tersebut dari pembukaan koneksi sampai aliran perintah tulis yang mengalir terus.

Masterport 6390, menerima tulisanReplicaport 6391, melayani baca1. REPLICAOF: buka koneksi2. PSYNC: minta sinkronisasi awal3. aliran perintah tulis, berkelanjutan
Alur replikasi: replika membuka koneksi, meminta sinkronisasi lewat PSYNC, lalu menerima aliran perintah tulis dari master

Menjalankan pasangan master dan replika#

Lab pada topik ini menyalakan dua server di port 6390 dan 6391 dengan direktori data bersama di /tmp/lab-repl. Kedua server berjalan tanpa persistensi agar percobaan tidak meninggalkan berkas data, dengan log diarahkan ke berkas terpisah agar terminal tetap bersih. Opsi --repl-diskless-sync-delay 0 pada master mematikan penundaan bawaan transfer RDB tanpa disk, yaitu jeda lima detik yang memang dirancang untuk mengumpulkan banyak replika sekaligus, sedangkan pada lab dengan satu replika jeda itu hanya memperlambat pengujian. Jalankan blok berikut untuk menyalakan kedua server dan menjadikan port 6391 sebagai replika dari port 6390.

bash
# hentikan sisa proses lab dari topik sebelumnya, bila ada
redis-cli -p 6390 shutdown nosave 2>/dev/null || true
redis-cli -p 6391 shutdown nosave 2>/dev/null || true
redis-cli -p 6392 shutdown nosave 2>/dev/null || true
redis-cli -p 6393 shutdown nosave 2>/dev/null || true
redis-cli -p 6394 shutdown nosave 2>/dev/null || true
# siapkan direktori data lab replikasi
mkdir -p /tmp/lab-repl
# nyalakan master tanpa persistensi, log diarahkan ke berkas
redis-server --port 6390 --bind 127.0.0.1 --daemonize yes --dir /tmp/lab-repl --save "" --protected-mode no --repl-diskless-sync-delay 0 --logfile /tmp/lab-repl-master.log
# nyalakan replika dengan konfigurasi yang sama di port lain
redis-server --port 6391 --bind 127.0.0.1 --daemonize yes --dir /tmp/lab-repl --save "" --protected-mode no --logfile /tmp/lab-repl-replica.log
# tunggu kedua server siap, lalu pastikan koneksinya hidup
sleep 1
redis-cli -p 6390 PING
redis-cli -p 6391 PING
# jadikan server 6391 sebagai replika dari master 6390
redis-cli -p 6391 REPLICAOF 127.0.0.1 6390
text Keluaran
PONG
PONG
OK

Perintah REPLICAOF langsung memicu proses sinkronisasi di latar belakang, sehingga status koneksi perlu dipastikan sebelum data diuji. Blok berikut menggunakan WAIT untuk menunggu replika mengakui posisi aliran tulis terakhir, kemudian membaca baris pertama keluaran ROLE pada kedua server. Opsi head -1 digunakan karena ROLE melaporkan banyak baris tambahan yang isinya berubah, sedangkan baris pertamanya selalu berisi nama peran.

bash
# tunggu sampai satu replika mengakui seluruh aliran tulis, batas 5000 ms
redis-cli -p 6390 WAIT 1 5000
# periksa peran master pada port 6390
redis-cli -p 6390 role | head -1
# periksa peran replika pada port 6391
redis-cli -p 6391 role | head -1
text Keluaran
1
master
slave

Keluaran memperlihatkan pasangan peran yang diharapkan, yaitu master pada port 6390 dan slave pada port 6391. Nama peran slave pada keluaran ROLE adalah sebutan historis yang digunakan protokol replikasi, sedangkan perintah pembentuknya bernama REPLICAOF. Angka 1 pada WAIT berarti satu replika sudah mengakui posisi tulisan yang diminta, tanda bahwa koneksi replikasi aktif dan sinkronisasi awal selesai.

Menguji aliran tulis dengan WAIT#

Perintah WAIT memblokir pemanggilnya sampai sekurang-kurangnya sejumlah replika mengakui seluruh tulisan yang dikirim sebelum WAIT, atau sampai batas waktu dalam milidetik habis, dan mengembalikan jumlah replika yang sudah mengakui. Perintah ini menjadi alat uji keterlambatan yang sederhana, karena tulisan yang sudah dikonfirmasi WAIT pasti sudah diproses oleh replika yang bersangkutan. Tanpa WAIT, pembacaan langsung ke replika setelah menulis ke master dapat mengembalikan data lama, karena aliran replikasi membutuhkan jeda singkat untuk tiba. Jalankan blok berikut untuk menulis satu key di master, menunggu pengakuannya, lalu membaca key yang sama dari replika.

bash
# tulis key pengaturan pada master
redis-cli -p 6390 SET pengaturan:bahasa id
# tunggu replika memproses tulisan tersebut, batas waktu 2000 ms
redis-cli -p 6390 WAIT 1 2000
# baca key yang sama langsung dari replika
redis-cli -p 6391 GET pengaturan:bahasa
text Keluaran
OK
1
id

Keluaran id pada pembacaan replika membuktikan tulisan master sudah tiba di replika sebelum pembacaan dilakukan. Arah tulisan juga terkunci satu arah, karena replika menolak perintah tulis yang dikirim langsung kepadanya. Uji penolakan tersebut dengan menulis ke port 6391.

bash
# tulisan langsung ke replika ditolak server
redis-cli -p 6391 SET pengaturan:bahasa en
text Keluaran
READONLY You can't write against a read only replica.

Pesan error READONLY muncul karena mode baca-saja untuk replika merupakan perilaku bawaan Redis, dan seluruh perubahan data hanya boleh masuk melalui master. Disiplin ini menjaga salinan tidak menyimpang dari sumbernya, karena satu-satunya jalur perubahan adalah aliran replikasi. Apabila tulisan sementara pada replika memang diperlukan untuk percobaan, lakukan pada lab terpisah dan jangan pada pasangan replikasi produksi.

Promosi replika sebagai dasar failover#

Failover adalah pengalihan peran master ke server lain ketika master gagal, dan bentuk paling dasarnya adalah promosi manual. Argumen NO ONE pada REPLICAOF membebaskan replika dari master dan mengubahnya menjadi master mandiri yang menerima tulisan. Aplikasi kemudian diarahkan ke port yang baru, sedangkan master lama dapat bergabung kembali sebagai replika dari master yang baru. Jalankan blok berikut untuk mempromosikan port 6391 dan memeriksa peran kedua server sesudahnya.

bash
# bebaskan replika dari master agar menjadi master mandiri
redis-cli -p 6391 REPLICAOF NO ONE
# periksa peran baru server 6391 setelah promosi
redis-cli -p 6391 role | head -1
# periksa peran master lama pada port 6390
redis-cli -p 6390 role | head -1
text Keluaran
OK
master
master

Kedua server kini berperan sebagai master secara mandiri, dengan port 6391 siap menerima tulisan dan port 6390 kehilangan seluruh replikanya. Promosi manual seperti ini cocok untuk pemeliharaan terencana, sedangkan kegagalan mendadak menuntut deteksi otomatis atas kondisi master, tugas yang diambil alih oleh Sentinel pada pengaturan ketersediaan yang lengkap.

Percobaan topik ini selesai, sehingga kedua server lab dimatikan tanpa menyimpan data ke disk.

bash
# matikan kedua server lab tanpa menyimpan data ke disk
redis-cli -p 6390 shutdown nosave
redis-cli -p 6391 shutdown nosave

Ringkasan#

  • REPLICAOF membentuk hubungan replikasi saat runtime, dengan alur koneksi, PSYNC, sinkronisasi awal berupa RDB, lalu aliran perintah tulis yang berkelanjutan.
  • WAIT n ms memblokir sampai sejumlah replika mengakui tulisan terdahulu atau batas waktu habis, dan menjadi cara sederhana menguji keterlambatan sebelum membaca dari replika.
  • Replika menolak tulisan dengan error READONLY, sehingga seluruh perubahan data hanya lewat master dan salinan tetap konsisten dengan aliran replikasi.
  • REPLICAOF NO ONE mempromosikan replika menjadi master sebagai dasar failover manual, dengan risiko kehilangan tulisan terakhir karena replikasi asinkron.

Referensi#

  • Replication — Redis — Panduan resmi replikasi yang menjelaskan sinkronisasi awal, aliran perintah, dan perilaku asinkron.
  • REPLICAOF — Redis — Dokumentasi perintah pembentuk dan pelepasan hubungan replikasi, termasuk argumen NO ONE.
  • WAIT — Redis — Dokumentasi perintah yang memblokir pemanggil sampai replika mengakui tulisan, beserta batas waktunya.
  • ROLE — Redis — Dokumentasi perintah pelapor peran server beserta bentuk keluarannya untuk master dan replika.