Cluster, Partisi Jaringan, Federation, dan Shovel — Belajar RabbitMQ

Apa yang Dibagi dan Tidak Dibagi dalam Cluster

Direplikasi ke semua node	Tidak direplikasi
Definisi exchange, binding	Isi classic queue (hanya di satu node)
User, permission, vhost	—
Policy dan parameter	—
Isi quorum queue (ke replikanya)	—

⚠️ Classic queue hidup di satu node saja

Dalam cluster, sebuah classic queue berada di node tempat ia pertama dideklarasikan. Node lain hanya meneruskan permintaan ke sana. Bila node itu mati, queue tersebut tidak tersedia sampai node kembali — walaupun cluster secara keseluruhan sehat.

Inilah alasan lain mengapa quorum queue menjadi default yang benar untuk apa pun yang penting.

Membentuk Cluster

cluster manualbash

# Syarat mutlak: seluruh node memakai Erlang cookie yang SAMA
# /var/lib/rabbitmq/.erlang.cookie  (mode 0400, milik user rabbitmq)

# di node-2 dan node-3:
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster rabbit@node-1
rabbitmqctl start_app

rabbitmqctl cluster_status

pembentukan otomatis (lebih baik)ini

# rabbitmq.conf
cluster_formation.peer_discovery_backend = classic_config
cluster_formation.classic_config.nodes.1 = rabbit@node-1
cluster_formation.classic_config.nodes.2 = rabbit@node-2
cluster_formation.classic_config.nodes.3 = rabbit@node-3

# di Kubernetes:
# cluster_formation.peer_discovery_backend = k8s
# cluster_formation.k8s.host = kubernetes.default.svc.cluster.local

⛔ Erlang cookie: penyebab kegagalan cluster nomor satu

Node dengan cookie berbeda tidak bisa saling bicara sama sekali. Pesan errornya sering menyesatkan — biasanya Node not responding atau Authentication failed — sehingga orang mencurigai jaringan atau DNS selama berjam-jam.

bash

# periksa dari setiap node
docker exec rabbit-1 cat /var/lib/rabbitmq/.erlang.cookie
docker exec rabbit-2 cat /var/lib/rabbitmq/.erlang.cookie
# harus identik, tanpa newline tambahan, permission 0400

Partisi Jaringan (Split Brain)

apa yang terjaditext

Cluster 3 node, jaringan terpotong:

  [ node-1 ]  ✂  [ node-2   node-3 ]
   minoritas        mayoritas

Tanpa penanganan, kedua sisi mengira sisi lain yang mati,
lalu masing-masing menerima publish → data menyimpang.

strategi penangananini

# rabbitmq.conf
cluster_partition_handling = pause_minority

Strategi	Perilaku	Penilaian
`pause_minority`	Sisi minoritas berhenti melayani sampai partisi pulih	Dianjurkan. Konsistensi diutamakan
`autoheal`	Setelah pulih, sisi minoritas di-restart dan datanya dibuang	Bisa kehilangan pesan diam-diam
`ignore`	Tidak melakukan apa-apa	Split brain sungguhan. Hanya untuk cluster 2 node yang sudah pasrah

pause_minority memerlukan jumlah node ganjil agar konsep "mayoritas" bermakna — alasan yang sama dengan quorum queue.

Menyebar Node dengan Benar

penempatan nodetext

✅ Tiga node di tiga availability zone dalam SATU region
   latensi antar-AZ ± 1–2 ms, cukup untuk Raft

❌ Tiga node di tiga REGION berbeda
   latensi 50–200 ms membuat konsensus Raft sangat lambat;
   setiap publish dengan confirm menunggu replikasi lintas benua

Untuk multi-region: cluster terpisah per region,
dihubungkan dengan Federation atau Shovel.

Shovel: Memindahkan Pesan Antar Broker

shovel dinamisbash

rabbitmqctl set_parameter shovel migrasi-ke-baru '{
  "src-protocol": "amqp091",
  "src-uri":      "amqp://user:sandi@broker-lama:5672/%2f",
  "src-queue":    "pesanan.email",

  "dest-protocol": "amqp091",
  "dest-uri":      "amqp://user:sandi@broker-baru:5672/%2f",
  "dest-queue":    "pesanan.email",

  "ack-mode":         "on-confirm",
  "src-prefetch-count": 1000,
  "src-delete-after": "never"
}'

rabbitmqctl shovel_status
rabbitmqctl clear_parameter shovel migrasi-ke-baru

💡 ack-mode: on-confirm adalah satu-satunya pilihan aman

Shovel baru meng-ack pesan di sumber setelah tujuan mengonfirmasi penerimaannya. Dengan on-publish atau no-ack, pesan bisa hilang di tengah perpindahan bila tujuan bermasalah.

src-delete-after: queue-length berguna untuk migrasi sekali jalan: shovel berhenti sendiri setelah memindahkan pesan yang ada saat ia dimulai.

Federation: Menyambungkan Broker Lintas Lokasi

federation exchangebash

# di broker hilir (yang menerima)
rabbitmqctl set_parameter federation-upstream jakarta '{
  "uri": "amqp://user:sandi@rabbit-jakarta:5672",
  "expires": 3600000,
  "max-hops": 1
}'

rabbitmqctl set_policy federasi-pesanan "^pesanan$" '{
  "federation-upstream-set": "all"
}' --priority 10 --apply-to exchanges

	Shovel	Federation
Memindahkan	Isi satu queue	Pesan dari exchange
Arah	Satu arah, eksplisit	Upstream ke downstream
Cocok untuk	Migrasi, DR, pemindahan sekali jalan	Distribusi peristiwa multi-region berkelanjutan
Kesederhanaan	Sangat sederhana	Perlu perhatian pada `max-hops`

max-hops mencegah pesan berputar tanpa henti bila dua broker saling memfederasi. Setel 1 kecuali Anda benar-benar membangun topologi berlapis.

Load Balancer di Depan Cluster

hal yang perlu diperhatikantext

✅ TCP load balancer (layer 4), bukan HTTP
✅ Timeout idle HARUS lebih besar dari heartbeat AMQP
   LB idle 60s + heartbeat 60s → koneksi diputus di tengah
   Setel LB idle ≥ 300s, atau heartbeat lebih kecil dari idle LB
✅ Health check ke port 5672, atau HTTP /api/health/checks/alarms
❌ Sticky session tidak diperlukan — AMQP sudah stateful per koneksi