Server Support Forum
Datenbank skalieren mit GaleraCluster

Zurück   Server Support Forum > >


Antwort
 
Themen-Optionen Thema bewerten
  #1  
Alt 07.11.2017, 18:42
Bimmel Bimmel ist offline
Registered User
 
Registriert seit: 11.2017
Beiträge: 2
Datenbank skalieren mit GaleraCluster

Hallo allerseits,

ich programmiere gerade eine Datenbank-Lastige Web-Anwendung (LAMP) und habe mich in der letzten Zeit daher mit Optimierungs- und Skalierungs-Methoden beschäftigt.
Die Anwendung ist glücklicherweise überwiegend durch Read-Abfragen geprägt und es sind kurzfristig auch keine gigantischen Besucher-Zahlen zu erwarten. Dafür sollte die Anwendung aber eine robuste Verfügbarkeit aufweisen.
In manchen Bereichen der Anwendung werden pro Seitenaufruf mehrere hundert Queries erzeugt und der Seitenaufruf bzw. der Ajax-Request kann dann durchaus ein paar Sekunden dauern.
Nachdem ich nun viele Skalierungs-Modelle studiert habe, ist mein favorisiertes SetUp ein MariaDB GaleraCluster mit MaxScale als vorgeschaltetem Datenbank-Proxy mit Read/Write-Split.
Ich habe bei mir zu Hause sowohl den Cluster als auch den Proxy zu Testzwecken eingerichtet und soweit ich das beurteilen kann, funktioniert alles so wie erwartet. Den Haupt-Vorteil sehe ich darin, dass die Anwendung (basiert auf einem PHP-Framework) nur den Proxy sieht und der Cluster quasi verdeckt im Hintergrund lesend skaliert. Auf diese Weise sind zumindest keine Anpassungen am ORM notwendig, was je nach Framework und zur Verfügung stehenden CallBack-Möglichkeiten eine große Erleichterung bedeutet.
Leider kann ich das Setup primär aus zeitlichen Gründen nicht selber managen, sondern bin auf einen Hoster angewiesen. Insofern ist nahezu jedes SetUp mit ziemlich hohen Kosten verbunden und deshalb würde ich gerne nachfragen, wo Ihr Vor- und Nachteile seht oder praktische Erfahrungen gesammelt habt...

Auf der offiziellen Seite von GaleraCluster wird bei den "Configuration Tips" zwischen "Multi-Master Setup" und "Single Master Setup" unterschieden.
Ich habe das so verstanden, dass beim Multi-Master-SetUp die Wahrscheinlichkeit für Konflikte und den damit verbundenen RollBacks steigt.
Eigentlich bewirbt GaleraCluster das Feature Multi-Master jedoch sehr offensiv. Auf Applikationsebene scheint ja auch ohne Proxy kein Read/Write-Split mehr notwendig zu sein (ein Load-Balancing hingegen schon). Es wird aber auch explizit auf die möglichen Konflikte im Multi-Master-Betrieb hingewiesen. Im Prinzip verstehe ich das so, dass die Anwendung mit den neuen Herausforderungen des Multi-Master-SetUps zurecht kommen muss, die es vorher in der Einzel-Datenbank-Umgebung so nicht gab. Aus Sicht der Anwendung treten Konflikte nun möglicherweise häufiger oder in anderer Form auf als bei Single-Master-SetUps. Mir ist nur nicht ganz klar, was diese "certification conflicts" für die im Hintergrund arbeitende Web-Anwendung in der Praxis bedeuten. Wird bei certification conflicts zuvor im Hintergrund versucht den Konflikt mit einer kleinen Verzögerung alleine zu lösen, so dass bei vernünftig geplanten Kapazitäten dann doch nicht alles zurückgerollt werden muss, sondern die Konflikte bzw. das Monitoring selbiger erstmal nur die Notwendigkeit aufzeigt, die Cluster-Kapazitäten zu erhöhen?
Ich versuche also zwischen Multi-Master-Betrieb und Single-Master-Betrieb abzuwägen und frage mich auch, in wie weit ich Konflikte nicht nur erkennen können muss, sondern möglicherweise auch Strategien entwickeln muss, um nach einem RollBack die jeweilige Aktion benutzerfreundlich zum Abschluss zu bringen?

Ist bei MaxScale mit Read/Write-Split die WriteMaster-Node gleichzeitig auch noch für Read-Anfragen erreichbar? Ich frage mich hierbei, ob der MaxScale in so einem SetUp dynamisch dafür sorgt, dass der WriteMaster stets genügend Ressourcen für Write übrig hat, aber bei entsprechend geringer Auslastung auch noch für Read-Anfragen zur Verfügung steht? Wenn der WriteMaster nur schreibt, würden von den mindestens 3 notwendigen Nodes ja nur 2 für die Skalierung der Reads zur Verfügung stehen und wenn ein Knoten dann noch regelmäßig für BackUps in den Donor-Mode geschickt wird, zeitweise sogar nur eine einzige Node.

Ich habe gelesen, dass die bei MaxScale notwendige Logik für einen Read/Write-Split wohl einiges an CPU-Zeit kosten kann. In meinem Fall erwarte ich da durchaus Probleme, da pro Seitenaufruf wie gesagt mehrere hundert Abfragen stattfinden können, was mit steigender User-Anzahl dann viel Arbeit für MaxScale bedeuten könnte..die Frage ist aber auch, wie zuverlässig MaxScale in der Praxis läuft und ob man problemlos 2 Rechner mit je einem Trio aus Webserver, MaxScale und keepalived als HA-Lösung zusammenschalten kann, was dann mit 3 Cluster-Nodes insgesamt 5 Server ergibt.

Ich hoffe, das war nicht zu viel Text - eventuell kann ja jemand seine praktischen Erfahrungen mit GaleraCluster teilen.

Viele Grüße
Bimmel
Mit Zitat antworten

  #2  
Alt 07.11.2017, 21:05
ThomasChr ThomasChr ist offline
Registered User
 
Registriert seit: 08.2014
Beiträge: 339
Leider kann ich krine Erfahrungswerte zu Galera beitragen, aber ich finde die Infrastruktur der Wikipedia recht interessant: https://meta.m.wikimedia.org/wiki/Wikimedia_servers

Dort sorgen Varnish Caches dafür dass pute Read Requests quasi nie an der Datenbank ankommen, und wenn dann nur am Read Only Cluster.
Erst wenn man sich einloggt und Änderungen macht gehts ans Master Cluster.

Vielleicht hilft dir das ja als Inspiration!

Thomas
Mit Zitat antworten
  #3  
Alt 08.11.2017, 14:52
IP-Projects.de IP-Projects.de ist offline
verifizierter Anbieter
 
Registriert seit: 06.2006
Ort: Würzburg
Beiträge: 1.681
IP-Projects.de eine Nachricht über ICQ schicken IP-Projects.de eine Nachricht über MSN schicken Datenbank skalieren mit GaleraCluster
Das Problem bei GaleraCluster ist, dass die Anwendungen Deadlocks abfangen muss. Dazu solltest du dir mal https://severalnines.com/blog/avoidi...lti-node-reads ansehen.

Der Kern der Sache ist, es muss vermieden werden, dass du eine Tabelle für lange Zeit lockst für einen Schreibprozess da sonst das Cluster diese nicht rechtzeitig synchronisieren kann und damit die Konsistens verliert. Dann geht quasi nichts mehr solange bis das Cluster repariert wurde.

Dazu gibt es zu beachten, dass du mindestens 3 Nodes brauchst. 2 Nodes werden zwar grundsätzlich unterstützt, aber 3 sind empfohlen als kleinste Einheit. Es geht dabei darum, dass wenn dein Cluster inkonsistent wird, noch ausreichend Ressourcen zur Verfügung stehen in Form von Rechenleistung, damit Informationen während des Rebuild Prozesses geliefert werden können. In der 2 Node Konstellation ist der Synchronisationsprozess so Ressourcenträchtig, dass kaum Leistung zur Beantwortung von Anfragen bleibt.

Das ist so kurz und Knapp das Wichtigste was es zu beachten gibt.
__________________

IP-Projects GmbH & Co. KG
Michael Schinzel | Am Vogelherd 14 | D - 97295 Waldbrunn
Tel.: +49 (0) 9306 - 76499-0 | FAX: +49 (0) 9306 - 76499-15
E-Mail: schinzel@ip-projects.de

UsTID: DE279448086 | Finanzamt Würzburg
Handelsregister: HRA 6798 | Amtsgericht Würzburg
Mit Zitat antworten
  #4  
Alt 11.11.2017, 10:10
Bimmel Bimmel ist offline
Registered User
 
Registriert seit: 11.2017
Beiträge: 2
Hallo Thomas,

Zitat:
Zitat von ThomasChr Beitrag anzeigen
Dort sorgen Varnish Caches dafür dass pute Read Requests quasi nie an der Datenbank ankommen, und wenn dann nur am Read Only Cluster.
vielen Dank für den Tipp, aber was ich so in Kürze gelesen habe scheint Varnish ja eher ein Cache zu sein. Ein Cache wird bei mir wohl nicht funktionieren, da sich z.B. die Tabellen in meiner Datenbank in relativ kurzen Abständen ändern (je nach User-Auslastung alle paar Sekunden, mit steigender Userzahl werden die Intervalle noch kürzer). Es werden jeweils nur sehr kleine Datenmengen geschrieben, weswegen weiterhin gilt, dass die DB stark Lese-Lastig ist, aber einen Cache konnte ich wegen der häufigen Änderungen bislang noch nicht sinnvoll einsetzen. Deswegen habe ich mich mehr nach Skalierungs-Techniken umgesehen.

Hallo IP-Projects,

vielen Dank auch Dir für Deine Hilfe.

Zitat:
Zitat von IP-Projects.de Beitrag anzeigen
Der Kern der Sache ist, es muss vermieden werden, dass du eine Tabelle für lange Zeit lockst für einen Schreibprozess da sonst das Cluster diese nicht rechtzeitig synchronisieren kann und damit die Konsistens verliert. Dann geht quasi nichts mehr solange bis das Cluster repariert wurde.
Das Problem habe ich aber doch nicht, wenn ich beim MaxScale das Read/Write-Splitting nutze (Lese-Anfragen auf alle 3 Nodes verteilen, Schreib-Anfragen nur an die Master-Node), oder?

Zitat:
MaxScale Read/Write Splitting with Galera Cluster

The readwritesplit router is designed to increase the read-only processing capability of a cluster while maintaining consistency. This is achieved by splitting the query load into read and write queries. Read queries, which do not modify data, are spread across multiple nodes while all write queries will be sent to a single node.
Zitat:
Zitat von IP-Projects.de Beitrag anzeigen
Dazu gibt es zu beachten, dass du mindestens 3 Nodes brauchst.
Ja, ich wollte mit 3 Nodes arbeiten (1 SingleMaster, 2 Slaves). Aufgrund der Beschreibung auf den Seiten von MariaDB ging ich bislang davon aus, dass man die 3 Nodes im Produktiv-Betrieb z.B. für eine Erprobungsphase unter echten Bedingungen auch ohne Abonnement betreiben darf...

Zitat:
If you are using MaxScale with three or more database server instances in production, you need to purchase either a MariaDB TX or AX Subscription to access features such as management and monitoring tools, notification services for security alerts and bug fixes, technical and consultative support which includes 24x7 support coverage as well as performance tuning, best practice recommendations and code review.
Das liest sich für mich so, als ob das Abonnement zur Nutzung bestimmter Tools oder Service-Leistungen erforderlich ist. Jetzt habe ich auf deren Seiten aber noch folgendes gefunden...

Zitat:
Business Source License 1.0

Licensor: MariaDB Corporation Ab

Software: MariaDB MaxScale™ v.2.0. The Software is © 2016 MariaDB Corporation Ab

Use Limitation: Usage of the software is free when your application uses the Software with a total of less than three database server instances for production purposes.

Change Date: 2019-01-01
Für die aktuelle Version 2.1 konnte ich kein Paper finden, aber in diesem Paper hört sich das so an, als ob man bei 3 Nodes im Produktiv-Betrieb immer ein Abonnement benötigt. Bei den diversen Abonnement-Varianten steht beim Preis nur ein unverbindliches "Contact us" - sind anscheinend Top-Secret.

Weiß jemand, ob man in der aktuellen Version bei 3 Nodes im Produktiv-Betrieb von Anfang ein Abonnement benötigt und wo das preislich ungefähr anfängt?
Mit Zitat antworten
Antwort

Lesezeichen


Themen-Optionen
Thema bewerten
Thema bewerten:

Forumregeln
Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist aus.
HTML-Code ist aus.

Gehe zu

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Datenbank von Linux: MySQL unter Xampp Impotieren srb85 Sonstige Admin-Software 14 29.11.2016 12:08
Courier soll mySQL Datenbank abfragen grep666 Mail 3 24.06.2011 11:06
VPN + SQL Datenbank Vanilie Sonstige Serverdienste 3 08.10.2009 19:39
Datenbank nicht erreichbar noname2k SQL 4 16.08.2008 19:04
Datenbank lädt.... webercon SQL 8 28.02.2004 00:43


Datenbank skalieren mit GaleraCluster
Datenbank skalieren mit GaleraCluster
Datenbank skalieren mit GaleraCluster Datenbank skalieren mit GaleraCluster
Powered by vBulletin® Version 3.8.11 (Deutsch)
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2017 DragonByte Technologies Ltd.