Protokoll — Server ↔ Server (Cluster) ​

Das Peer-RPC-Protokoll, das nur im Cluster-Modus verwendet wird. Knoten teilen sich einen einzigen Sperrenzustand per Raft-Konsens — jede Zustandsänderung einer Sperre (Erwerb, Freigabe, Ablauf) wird erst angewendet, nachdem der Vorschlag des Leaders → Mehrheitsreplikation → Commit durchlaufen wurde, sodass der gegenseitige Ausschluss auch während einer Partitionierung oder eines Failovers bestehen bleibt. Die konzeptionelle Erklärung findest du unter Funktionsweise.

Ablauf — von einem Acquire bis zu seinem Commit ​

Der Leader wandelt den Sperrbefehl in einen replizierten Befehl um, trägt ihn in einer AppendEntries-RPC und committet, sobald eine Mehrheit einschließlich er selbst ihn verzeichnet hat (bei 3 Knoten reicht der Leader plus Follower 1 — er wartet nicht auf den Rest). Die Client-Antwort geht erst nach dem Commit hinaus, sodass die Sperre, sobald du eine Antwort erhalten hast, in die Mehrheit geschrieben ist.

Port- und Adressregeln ​

• Peer-RPC verwendet einen dedizierten Raft-Port = Client-Port + 1000 (z. B. 5225 → 6225). Er wird automatisch ohne separaten Konfigurationsschlüssel abgeleitet und lauscht nur im Cluster-Modus. Deine Firewall muss beide Ports öffnen.
• Die Konfiguration (cluster_self/cluster_peers) enthält immer die Client-Adresse. Nur beim Anwählen (dial) eines Peers wird +1000 zum Port addiert — die an Clients übergebene M-Umleitungsadresse (verwiesen) ist immer die reine Client-Adresse.
• Rollen werden rein anhand des Ports unterschieden — es gibt keinen protokollinternen Schritt, um Client und Peer zu unterscheiden. Die Reihenfolge des Verbindungsaufbaus und die Auth-/TLS-Regeln findest du unter Verbindung & Auth.

Inhalt ​

• Server-zu-Server
  • Verbindung & Auth
  • Frame-Struktur
  • RPC-Typen
  • Replizierte Befehle
  • Snapshot
• Raft-Parameter
• Konfiguration (Umgebungsvariablen)
• Unterbrechungsfreies Neustartverfahren (Rolling Restart)

Siehe auch ​

• Eine einfache Erklärung von Leaderwahl, Mehrheits-Commits und Fehlerszenarien — Funktionsweise
• Wie ein Client den Leader findet — M · Verwiesen, Regeln zur Antwortzuordnung
• Reale Bereitstellungsszenarien (Docker, Kubernetes usw.) — Ticketing-Serverbereitstellung