Ticketing Raft-Parameter
| Element | Wert |
|---|---|
| Herzschlag-Intervall | 500 ms (cluster_heartbeat_ms) |
| Ausfall-Erkennungszeit | 2000 ms (cluster_election_timeout_ms) — bleibt der Herzschlag so lange aus, gilt der Leader als ausgefallen |
| Tatsächliches Wahlfenster | 1750–2000 ms — pro Knoten zufällig gestreut, um gleichzeitige Kandidaturen (Split Vote) zu vermeiden. Der Höchstwert ist genau die konfigurierte Ausfall-Erkennungszeit |
| Client-Stillstand bei Leaderausfall | gemessen Ausfall-Erkennungszeit + 0,3–0,5 s (mit den Standardwerten also ca. 2,3–2,5 s) — Erkennung plus eine Umleitung |
| Knotenzahl | 3 oder 5 (beim Konfigurationsladen erzwungen — alles andere verweigert den Start) |
| Knoten-ID | seine (cluster_self) Position in der cluster_peers-Liste — deshalb muss die Listenreihenfolge auf jedem Knoten identisch sein |
| Bootstrap | 500 ms nach dem Start initialisiert sich jeder Knoten mit derselben Mitgliedschaft — wird ignoriert, wenn er einem bereits initialisierten Cluster beitritt |
| Log-Speicherung | In-Memory (flüchtig) — ein neu gestarteter Knoten erholt sich per Replikation/Snapshot |
| Lease-Ablauf-Erkennung | der Leader prüft alle 100 ms und committet Expire per Konsens |
Granularität des wait-Timeouts | das Wartezeit-Timeout (T) wird ebenfalls im selben 100-ms-Takt entschieden — es kann bis zu 100 ms verspätet eintreffen |
| Leader-Wechsel-Mitteilung | wechselt der Leader, geht sofort ein L an alle verbundenen Clients |
Herzschlag und Ausfall-Erkennungszeit wählen
Beide Werte werden in der Konfiguration über cluster_heartbeat_ms und cluster_election_timeout_ms eingestellt. Die Ausfall-Erkennungszeit (T) ist zugleich die Zeit, die der Dienst bei einem Leaderausfall stillsteht; ist sie umgekehrt zu kurz, wird ein lebender Leader fälschlich für tot gehalten und es kommt zu unnötigen Wahlen.
| Herzschlag / T | Erkennungsfenster | Schlimmste gemessene Verzögerung bei Leader-Kill | Empfohlene Umgebung |
|---|---|---|---|
| 100 ms / 600 ms | 450–600 ms | ca. 0,9 s | gleiches Rack / gleiche AZ, sehr stabile Latenz |
| 100 ms / 1000 ms | 750–1000 ms | ca. 1,2 s | gleiche AZ |
| 250 ms / 2500 ms | 1875–2500 ms | ca. 2,8 s | Multi-AZ |
| 500 ms / 2000 ms | 1750–2000 ms | ca. 2,4 s | Standard — ausgewogen für Multi-AZ |
| 500 ms / 5000 ms | 3750–5000 ms | ca. 5,3 s | regionsübergreifend, stark schwankende Latenz |
- Die Verarbeitungslatenz im Normalbetrieb ist von diesen Werten unabhängig (gemessen: kein Unterschied im p50) — sie bestimmen ausschließlich die Erholungszeit im Fehlerfall.
- Fällt ein Follower aus, bleibt das bei jedem Wert für Clients ohne Auswirkung. Nur der Ausfall des Leaders erzeugt die obige Verzögerung.
- Einschränkung:
cluster_election_timeout_msmuss mindestens 600 ms betragen und mindestens das Vierfache des Herzschlags sein. (Gemessen wurde, dass eine einzelne Scheduling-Verzögerung unter Last zwei Herzschläge komplett verschluckt.)
Warum 3 oder 5 Knoten
Ein Commit benötigt eine Mehrheit. Eine Konfiguration mit gerader Knotenzahl erhöht nur die Kosten, ohne die Fehlertoleranz zu verbessern, daher lehnt der Server sie ab.
| Knotenzahl | Mehrheit | Tolerierte gleichzeitige Ausfälle |
|---|---|---|
| 2 | 2 | 0 — ein einzelner Ausfall stoppt den Cluster. Nicht besser als der Single-Modus |
| 3 | 2 | 1 |
| 4 | 3 | 1 — dasselbe wie bei 3 Knoten, nur teurer |
| 5 | 3 | 2 |
Zusammenfassung des Fehlerverhaltens
| Situation | Verhalten |
|---|---|
| Client-Anfrage an einen Nicht-Leader-Knoten | M (Leader-Adresse), oder E no_leader, falls der Leader unbekannt ist |
| Leaderausfall | neuer Leader innerhalb von 500–1000 ms gewählt. Anfragen in diesem Fenster erhalten E no_leader → der Client versucht es erneut |
| Während des Leaderwechsels | anstehende Acquire-Anfragen werden mit M/E no_leader bereinigt, und der Client versucht es beim neuen Leader erneut |
| Knotenneustart | bootet mit leerem Zustand → holt über die Log-Replikation/den Snapshot eines Peers auf |
| Mehrheit verloren | Commits werden unmöglich → Schreibvorgänge stoppen (Sicherheit zuerst), wird automatisch fortgesetzt, sobald die Mehrheit wiederhergestellt ist |
Begriffe
- Quorum — mehr als die Hälfte aller Knoten (2 von 3, oder 3 von 5). Da jede Entscheidung die Zustimmung des Quorums erfordert, können zwei partitionierte Gruppen niemals gleichzeitig widersprüchliche Entscheidungen committen.
- Wahl-Timeout (election timeout) — wie lange ein Follower ohne Herzschlag wartet, bevor er schließt, dass der Leader gestorben ist, und eine Wahl startet. Pro Knoten randomisiert, um gleichzeitige Kandidaturen zu reduzieren.