Was ist das beste Setup für eine MySQL-Multi-Master-Replikation für einen POS in einem Restaurant?

Question

Wir sind dabei, einen Point of Sale (POS) -Lösung umzusetzen, in dem wir einen bestehenden Open Source-POS stark modifiziert haben. Der ursprüngliche POS wurde nie mit der Replikation / Synchronisation zwischen Terminals erstellt und wir möchten diese hinzufügen.

Wir verwenden MYSQL 5.7 und benötigen eine Lösung, um Folgendes auszuführen:

• Jedes POS-Terminal muss unabhängig von anderen Terminals oder Back Office-Server arbeiten - d. H. Haben Sie eine eigene lokale Datenbank und funktioniert, auch wenn das Netzwerk untergeht

• Multi-Master-Synchronisation - Alle POS-Terminals sollten den aktuellen Status des Systems widerspiegeln

Beispiel 1: Sie sollten in der Lage sein, eine Bestellung an einem POS-Anschluss zu starten und sie an einem anderen Terminal zu enden / zu ändern.

Beispiel 2: Wenn Sie eine Bestellung für eine Restauranttabelle an einem Terminal starten, wird ein anderer Kellner angezeigt, dass dieser Tisch von einem anderen POS-Terminal besetzt ist.

• skalierbar auf n-Terminals - einige Kunden haben 1 POS-Anschlüsse, etwa 3 und etwa 100. Die Lösung muss auf eine beliebige Anzahl von POS-Terminals skaliert werden

Ich habe folgende Lösungen angesehen:

• MySQL-Cluster
• MySQL-Replikation
• maria db replikation
• Maria db Gallera Cluster

Es scheint, dass MySQL synchrone Replikation könnte Arbeit, aber ich bin nicht sicher, ob das das beste Setup ist.

Ich hätte gerne in Bezug auf:

• welche Technologie zu verwenden
• wie am besten so eingestellt werden soll

Answer 1

Ich würde mit Galera gehen. Es ist selbstheilend, nachdem ein einzelner Knoten stirbt und online wiederkommt. Wenn jedoch das gesamte Netzwerk stirbt (keine Maschine mit einer anderen Maschine sprechen kann), ist der NDB-Cluster möglicherweise die einzige Lösung, da sie Ausfälle durch benutzerdefinierte "Konfliktlösung" -Algorithmen repariert.

plain replication hat viele potenzielle Misserfolge und braucht mehr Handholding. SEMI-SYNC erfordert, dass ein Teil des Netzwerks aufbleibt. Wenn semi-synchron seine "sync" nicht tun kann, kehrt es anhändig an "asynchron", wodurch das, was Sie erwartet hatten.

100 Knoten in jeder Replikationstechnologie werden eine Herausforderung sein. Die letzten 5-10 Knoten benötigt spezielle Gehäuse für größere Netzwerke. Für einfache Replikation und Semi-Synchronisierung sind "Relay" -Server wünschenswert. Sie nehmen zusätzliche Setup und erfordern zusätzliche Handhabung in fehlerhaften Situationen. Ich habe nicht von NDB oder Galera gehört, um wegen größerer Netzwerke, die möglicherweise ein Dutzend Knoten erschüttert werden. Einige Leute haben mehrere Galera-Cluster mit Async zwischen den Clustern.

Es ist Ihnen vielleicht besser, Zeit und Geld zu verbringen, um das Netzwerk zuerst zu härten.

Ein großer Kaufhaus kann möglicherweise 10 Kassenzähler mit jeweils 4 POS verfügen. Diese Hinweise bei hartem kabelgebundenen (sehr zuverlässigen) 4-Knoten-Cluster von einiger Art, plus etwas Zerbrechender zwischen den Clustern. Wenn Sie WLAN verwenden, verschlüsseln Sie unbedingt den gesamten Verkehr.

mit einfachen Replikation, ein Dual-Master-, Single-Writer (oder 3-Knoten-Galera-Cluster) ist möglicherweise das Beste. Es erfordert, dass alle POS an den Meister schreiben können, sonst sind sie offline. Es erfordert auch eine zusätzliche Codierung, um mit den "kritischen Liegestellen" umzugehen, in der Sie etwas posten, um etwas zu posten, und müssen es sofort wieder lesen, und muss sicher sein, dass eine Replikationslag abgerechnet wird. (Hinweis: Ich habe keine schreibgeschilderte auf dem POS, nur indirekt durch den Master und die Replikation.)

das alles kauen. Es tut uns leid, ich habe keine Antwort "tat diese".