Belajar RabbitMQ - RabbitMQ Clustering

#Pendahuluan

Setiap RabbitMQ yang berjalan di satu mesin adalah single point of failure. Jika node itu mati, semua queue dan pesan di dalamnya hilang, dan seluruh layanan yang bergantung padanya berhenti. Untuk produksi, kalian butuh lebih dari satu node: inilah cluster.

Cluster RabbitMQ menggabungkan beberapa node menjadi satu broker logis. Queue, exchange, binding, user, dan permission disinkronkan di seluruh node. Klien cukup terhubung ke salah satu node dan melihat topologi yang sama. Yang menarik: di dalam cluster, keputusan routing dan status node terus terbagi — beberapa resource di-replikasi, yang lain hanya disimpan di satu node.

Episode ini membahas cara membentuk cluster, mekanisme node discovery, pengamanan antar node dengan Erlang cookie, penambahan dan penghapusan node, serta isu paling rumit dalam sistem terdistribusi: network partition dan strategi menanganinya.

#Cluster Fundamentals

#Konsep Dasar Cluster

Dalam cluster, setiap node punya nama unik seperti rabbit@node1. Metadata seperti user, vhost, queue, exchange, dan binding direplikasi ke semua node — jadi topologi selalu konsisten di mana pun klien terhubung. Namun isi pesan queue secara default tidak direplikasi; kita akan menyelesaikan ini di episode 20 dengan quorum queues.

#Erlang Cookie Authentication

Semua node harus berbagi Erlang cookie — rahasia bersama yang mengotentikasi node satu sama lain. Cookie tersimpan di file (biasanya ~/.erlang.cookie). Jika cookie berbeda, node tidak bisa bergabung ke cluster. Simpan cookie dengan permission yang aman dan jangan pernah commit ke repository.

#Classic Clustering vs Peer Discovery

RabbitMQ menawarkan dua pendekatan formasi:

• Classic clustering — node pertama dipilih, lalu node lain bergabung secara manual.
• Peer discovery — node saling menemukan lewat DNS, cloud API (AWS), atau Kubernetes. Pendekatan ini lebih cocok untuk otomasi.

cluster_formation.peer_discovery_backend = rabbit_peer_discovery_dns
cluster_formation.dns.hostname = rabbits.discovery.svc.cluster.local

#Memeriksa Status dan Kesehatan Cluster

Setelah cluster terbentuk, periksa kondisi terkini dengan rabbitmqctl cluster_status:

rabbitmqctl cluster_status

Output perintah cluster_status menampilkan daftar node yang hidup, status disk setiap node, serta mode partition handling yang aktif. Biasakan menjalankannya setelah setiap perubahan cluster — dan jadikan bagian dari runbook troubleshooting. Sering kali satu node yang berhenti membuat semua orang panik, padahal cluster_status menunjukkan node lain masih sehat dan melayani.

#Cluster Setup

#Membuat Cluster Manual

Anggap tiga node: rabbit@node1, rabbit@node2, rabbit@node3. Mulai node2 dan node3, lalu gabungkan ke node1:

rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster rabbit@node1
rabbitmqctl start_app
rabbitmqctl cluster_status

Urutan stop_app → reset → join_cluster → start_app adalah prosedur standar bergabung ke cluster. reset membersihkan state node agar bisa menerima metadata cluster.

#Menambah dan Menghapus Node

Untuk menambah node, ulangi prosedur di atas. Untuk menghapus node, jalankan dari node lain:

rabbitmqctl forget_cluster_node rabbit@node2

Perintah forget_cluster_node mengeluarkan node dari cluster. Jika node itu mati permanen, jalankan perintah dengan flag --offline dari node yang masih hidup.

#Menangani Node yang Hilang Secara Permanen

Jika sebuah node gagal dan tidak akan kembali — misalnya mesinnya diganti — node tersebut harus dikeluarkan dari cluster dengan cara khusus. Dari node lain yang masih hidup:

rabbitmqctl forget_cluster_node rabbit@node2 --offline

Flag --offline dibutuhkan ketika node yang di-forget tidak dapat dijangkau. Prosedur ini menghentikan sisa cluster menunggu node mati tersebut dan menjaga metadata tetap konsisten. Pastikan data penting dari node mati sudah ditangani sebelum menjalankan perintah ini.

#Cluster Partitioning dan Split-Brain

Jika jaringan antar node terputus, cluster bisa terpecah menjadi beberapa "kepulauan" yang masing-masing menganggap dirinya utuh — ini split-brain. Pilihan mode partition menentukan apa yang terjadi saat jaringan pulih:

• pause_minority — node minoritas berhenti; menghindari konflik (default).
• autoheal — partisi minoritas restart dan menyesuaikan dengan mayoritas.
• ignore — partisi dibiarkan; berisiko konflik data.

cluster_partition_handling = autoheal

#Cluster Behavior

#Distribusi Queue dan Load Balancing

Queue non-replicated hanya hidup di node tempat queue dideklarasikan. Koneksi klien harus diarahkan ke node pemilik queue — karena itu klien biasanya memakai beberapa node sebagai endpoint. Load balancing koneksi bisa dilakukan dengan DNS round-robin atau load balancer TCP di depan port 5672.

Ada satu konsekuensi penting: karena metadata direplikasi, setiap node tahu di mana setiap queue berada. Klien yang terhubung ke node mana pun tetap bisa mem-publish atau consume — broker yang menerima operasi akan meneruskannya ke node pemilik queue. Yang tidak tersedia hanyalah akses ke isi queue non-replicated ketika node pemiliknya mati.

#Node Failure Handling

Jika sebuah node mati, node lain tetap melayani topologi yang sama, tetapi queue non-replicated yang berada di node mati tidak bisa diakses sampai node kembali. Inilah alasan quorum queues penting: pesan di dalamnya tetap bisa diakses dari node lain yang hidup.

Jika node kembali setelah jeda, dia otomatis menyinkronkan ulang metadata dengan node lain saat reconnect, dan queue miliknya kembali dapat diakses. Untuk queue yang datanya krusial, episode 20 akan menunjukkan bagaimana quorum queue membuat pemulihan tidak bergantung pada satu node.

#Penutup

Di episode 19 ini kalian sudah membentuk cluster multi node dengan Erlang cookie, memahami classic clustering vs peer discovery, menambah dan menghapus node, serta menangani network partition dengan mode pause_minority, autoheal, dan ignore.

Inti yang harus dibawa pulang:

• Metadata direplikasi ke semua node; isi queue tidak.
• Erlang cookie mengotentikasi node; rahasiakan dan jangan di-commit.
• Prosedur join cluster: stop_app, reset, join_cluster, start_app.
• Peer discovery mempermudah formasi otomatis lewat DNS/AWS/K8s.
• Split-brain ditangani dengan pause_minority, autoheal, atau ignore.
• Load balancer TCP membantu distribusi koneksi klien.
• Queue non-replicated tidak bisa diakses saat node pemiliknya mati.

Di episode 20 selanjutnya kita akan mencapai high availability dengan quorum queues — membangun replikasi berbasis algoritma konsensus Raft, membandingkannya dengan classic mirrored queues, mengonfigurasi faktor replikasi, menangani poison messages, serta memigrasi dari classic queues. Ini tipe queue yang wajib dipakai untuk produksi!