SQL Replication - Master/Slave Writes Non Application based.

A

anonemuss

New Member
Hallo.
Zur Zeit arbeite ich an einigen Server Clustern, allerdings tritt vor allem bei kleineren ein nicht unerhebliches Problem auf.
Bei Master/Slave Replication müssen ja alle Writes am Master durchgeführt werden. Allerdings suche ich noch einen Weg dies zu erzielen ohne das in eine Web-Application zu implementieren. (Maximale Flexibilität damit ich bestehende Codes nicht umschreiben muss.)
Optimale Lösung wäre Wohl, dass wenn der Slave einen Write-Befehl erhält, diesen einfach an den Master weiterschickt und der Master Server dann diesen Write ausführt.
(SQL Server Software: MariaDB bzw. MySQL)
OS: Ubuntu Server 14.04 LTS

Kennt jemand eine Möglichkeit so ein "Forwarding" Queries zu realisieren? (Andernfalls bleibt mir vermutl. nur noch Dual Master Config :/)

MFG
Anonemuss
 
Danke für eure schnellen Antworten :).
Habe mir beide Möglichkeiten mal genauer angesehen und denke, dass MaxScale genau das richtige wäre. (wusste bisher nicht, dass es auch bei simplen Replikationen angewendet werden kann :7)
Habt mir sehr weiter geholfen. Zeit Google und Fachliteratur etwas zu quälen um herauszufinden wie ich MaxScale einbinden kann. :)

Vielen Dank,
Anonemuss
 
Das ist ja genau der "tricky part" dabei. Will auch Backends wie Wordpress, Joomla oder sonstige OpenSource Pordukte schnell und einfach betreiben können. :p
Daher hab ich ja nach etwas wie MaxScale gesucht, weil ja Multi-Master Konfigurationen gerne mal Fehler aufweisen. :7
 
Außerdem ist MaxScale nahezu transparent für die Applikation.

Da kann man als DBA seine Umgebung sauber fahren und die Applikationen benutzen einfach die "Wolke Datenbank" :)

Gruß
Markus
 
anonemuss said:
Will auch Backends wie Wordpress, Joomla oder sonstige OpenSource Pordukte schnell und einfach betreiben können. :p
Click to expand...
Das wirst du so einfach nicht hinbekommen, immerhin sind zwischen Master und Slave auch einiges an Latenz, wenn dein Wordpress oder Joomla nun ein Update in der Datenbank durchführt und direkt darauf einen Select des gleichen Datensatzes macht, muss der Datensatz nicht unbedingt schon auf dem Slave sein und das wird dir auf längere Zeit sehr viel Kopfschmerzen bereiten.
 
Grundsätzlich hast du recht allerdings habe ich das durchaus bedacht.
Von Server zu Server ist die Reaktionszeit sehr gering, außerdem wird ein Loadbalancer davor geschalten, welcher session-persistent ist.
Oder hab ich deinen Hinweis falsch verstanden ?

MFG
Anonemuss
 
Danke für eure Antworten, allerdings ist mir noch etwas aufgefallen.
Nachdem ich mich nun intensivst mit Max Scale und Mariadb beschäftigt habe ist mir bei der Master/Slave Konfiguration in Kombination noch ein Problem aufgefallen.
Dieser Cluster um den es hier geht ist sehr klein: 2 Server
Daher bräuchte ich wohl die Möglichkeit auch einen MaxScale Failover zu konfigurieren, denn sollte der Master mit MaxScale ausfallen, bleibt der Slave im Slave-Status(und kann bzw. sollte nicht beschrieben werden).
Kennt jemand einen einfacheren Weg redundante MariaDB-Server zu konfigurieren, die gegenseitig übernehmen im Falle eines Ausfalls?
Oder bleibt mir nur die Möglichkeit 3 Server zu nehmen für Galera (wobei da auch wieder die Frage im Raum steht, was denn passiert wenn der Arbiter ausfällt^^) bzw. eine Dual Master Replikation zu nutzen.

MFG
Anonemuss
 
Ein Split-brain Szenario kann Böse enden, also würde ich hier schon einen Cluster aus mindestens drei Nodes empfehlen. Was spricht dagegen alle Server als Master laufen zu lassen und einen einen dritten Server in das Konzept mitaufzunehmen, wo du MaxScale und einen garbd-Daemon (als "virtuellen" dritten Cluster-Node) laufen lässt?
 
Guten Morgen.
Eigentlich wäre das ja die optimale Lösung, allerdings versuche ich die Kosten niedrig zu halten, da es sich in diesem konkreten Fall noch um privat gemietete Server in Rechenzentren handelt. Daher dachte ich ja auch eher an 2 Nodes.^^
Ich werde jetzt noch über eine Kombination aus all den Lösungen grübeln und mich nach einigen Tests auf VMs für eine Entscheiden. Im Moment klingt ja Master/Slave am besten ohne auf 3 Server umzusteigen.

Master/Slave Replication in Kombination mit MaxScale auf beiden Servern allerdings nur auf dem Slave gestartet. Im Falle eines Ausfalls könnte ein Script entweder den Slave direkt zum Master "promoten" oder MaxScale macht das :).
Werde diese Variante gleich mal testen :D.


Vielen lieben Dank für eure Hilfe.
Werde meine Resultate diesbezüglich hier noch schreiben, sobald bzw. wenn dieser Ansatz funktioniert.

MFG
Anonemuss
 
anonemuss said:
Guten Morgen.
Eigentlich wäre das ja die optimale Lösung, allerdings versuche ich die Kosten niedrig zu halten, da es sich in diesem konkreten Fall noch um privat gemietete Server in Rechenzentren handelt. Daher dachte ich ja auch eher an 2 Nodes.^^
Ich werde jetzt noch über eine Kombination aus all den Lösungen grübeln und mich nach einigen Tests auf VMs für eine Entscheiden. Im Moment klingt ja Master/Slave am besten ohne auf 3 Server umzusteigen.

Master/Slave Replication in Kombination mit MaxScale auf beiden Servern allerdings nur auf dem Slave gestartet. Im Falle eines Ausfalls könnte ein Script entweder den Slave direkt zum Master "promoten" oder MaxScale macht das :).
Werde diese Variante gleich mal testen :D.


Vielen lieben Dank für eure Hilfe.
Werde meine Resultate diesbezüglich hier noch schreiben, sobald bzw. wenn dieser Ansatz funktioniert.

MFG
Anonemuss
Click to expand...

Ohne jetzt genaueres über das Server-Konzept und deinen Anbieter zu wissen: Wäre es vielleicht eine Option, einen vServer als dritten Node (garbd) zu verwenden? Ist kostengünstiger und du kannst einen MariaDB Cluster bestehend aus drei Nodes schaffen. Kannst ja auch dort direkt MaxScale raufpacken. SSL Kommunikation zwischen den Nodes ist auch ohne großartige Probleme möglich.

Meiner Meinung nach klingt die Lösung mit dem Scripten eher nach einer "Bastellösung". Je nach Wichtigkeit des Projektes - und sei es privat - kann es aber auch reichen. Das musst du wissen.

Wenn du zwei Nodes hast, die Verbindung zwischen diesen Beiden unterbrochen wird und du den Slave zu einem Master hebst, dann hast du zwei eigenständige MariaDB-Server autark laufen. Wenn aber nun bei beiden Servern Daten geschrieben werden, dann kann das Böse enden. Sobald die Verbindung beider Nodes wieder da ist, gewinnt die Node, die die - AFAIK - "höchste Transaktions-ID" (kenne gerade die genaue Bezeichnung nicht) hat und überschreibt alle Daten der anderen Node. Dann hast du einen Datenverlust. Split-Brain Szenario.

Kurz erwähnt: - eventuell als Ideenanregung Wenn du zwei Master-Master Nodes hast und die Verbindung zwischen diesen unterbrochen wird, dann sind beide nur mehr eingeschränkt verfügbar und lassen keine Querys mehr zu ("wsrep not ready for application use"), um eben genau dieses Split-Brain-Problem - vor allem bei Änderungen - zu verhindern. In einem Produkt unserer Firma, auch wenn anderer Einsatzzweck, habe ich deswegen einen Daemon geschrieben, der Split-Brain erkennt und beide Nodes autark als neuen Cluster startet, damit wieder beide Nodes ansteuerbar und auch beschreibbar sind. Da ist der eventuell entstehende Datenverlust mehr oder weniger egal, weil da das Einsatzgebiet etwas anders ist.
 
Würde diese Variante nicht wieder einen Single Point of Failure haben? (den Arbiter = garbd).

Sollte die garbd Node ausfallen würden die Server ja genauso annehmen sie selbst wären das Problem und somit blockieren oder verstehe ich da etwas falsch?
 
Hallo.
Kurzes Update für die, die mein Thema verfolgt haben:
Arbiter wäre kein Single Point of Failure. So wie es aussieht dürften keine Fehler auftreten solange mehr als 50% des Clusters in Verbindung zu einander stehen.
Bezüglich der praktischen Konfiguration eines MariaDB Galera Clusters bin ich noch nicht auf eine funktionierende Variante gestoßen, werde mich allerdings dazu äußern sobald dieser Fall eintritt.
Mit freundlichen Grüßen
Anonemuss
 
You must log in or register to reply here.
Back
Top