{"id":82113,"date":"2020-05-19T13:42:51","date_gmt":"2020-05-19T11:42:51","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql"},"modified":"2020-05-19T13:42:51","modified_gmt":"2020-05-19T11:42:51","slug":"orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql","title":{"rendered":"Orchestrator und VIP als HA-L\u00f6sung f\u00fcr das MySQL-Cluster","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Bei SitiMobil verwenden wir eine MySQL-Datenbank als prim\u00e4ren Speicher f\u00fcr persistente Daten. Wir haben mehrere Datenbankcluster f\u00fcr verschiedene Dienste und Zwecke.<\/p>\n<p>Die st\u00e4ndige Verf\u00fcgbarkeit des Masters ist ein kritischer Indikator f\u00fcr die Funktionsf\u00e4higkeit des gesamten Systems und seiner einzelnen Teile. Die automatische Wiederherstellung des Clusters im Falle eines Master-Ausfalls verringert die Reaktionszeit auf Vorf\u00e4lle und die Ausfallzeit des Systems erheblich. In diesem Artikel werde ich das Schema zur Gew\u00e4hrleistung einer hohen Verf\u00fcgbarkeit (HA) des MySQL-Clusters basierend auf <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\">MySQL Orchestrator<\/a><\/noindex> und virtuellen IP-Adressen (VIP) erl\u00e4utern.<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator und VIP als HA-L\u00f6sung f\u00fcr das MySQL-Cluster\" src=\"\/wp-content\/uploads\/2020\/05\/a76ef93caee0fc13d2afb12c25a25531.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>HA-L\u00f6sung auf Basis von VIP<\/h1>\n<p>\nZuerst m\u00f6chte ich kurz erkl\u00e4ren, wie unser Datenspeichersystem aufgebaut ist.<\/p>\n<p>Wir verwenden ein klassisches Replikationsschema mit einem schreibberechtigten Master und mehreren Replikaten, die nur f\u00fcr Lesezwecke verwendet werden. Der Cluster kann einen Zwischen-Master enthalten \u2013 einen Knoten, der gleichzeitig auch ein Replikat und Master f\u00fcr andere ist. Kunden greifen \u00fcber HAProxy auf die Replikate zu, was eine gleichm\u00e4\u00dfige Lastverteilung erm\u00f6glicht und eine einfache Skalierung erleichtert. Die Verwendung von HAProxy hat historische Gr\u00fcnde, und wir befinden uns derzeit im Prozess der Migration zu ProxySQL.<\/p>\n<p>Die Replikation erfolgt im halb-synchronen Modus basierend auf <code>GTID<\/code>. Das bedeutet, dass mindestens ein Replikat die Transaktion im Protokoll speichern muss, bevor diese als erfolgreich anerkannt wird. Dieser Replikationsmodus bietet einen optimalen Kompromiss zwischen Leistung und Datensicherheit im Falle eines Ausfalls des Master-Knotens. Haupts\u00e4chlich werden alle \u00c4nderungen vom Master an die Replikate mittels <code>Row Based Replication (RBR)<\/code>, aber einige Knoten k\u00f6nnen ein <code>gemischtes binlog-Format<\/code>.<\/p>\n<p>verwenden. Der Orchestrator aktualisiert regelm\u00e4\u00dfig den Zustand der Cluster-Topologie, analysiert die erhaltenen Informationen und kann im Falle von Problemen den automatischen Wiederherstellungsprozess starten. F\u00fcr den Prozess selbst ist der Entwickler verantwortlich, da er auf verschiedene Arten umgesetzt werden kann: basierend auf VIP, DNS, unter Verwendung von Diensten zur Dienstentdeckung oder benutzerdefinierten Mechanismen. <\/p>\n<p>Eine der einfachen Methoden zur Wiederherstellung des Masters im Falle eines Ausfalls ist die Verwendung von schwebenden VIP-Adressen.<\/p>\n<p>Folgendes sollten Sie \u00fcber diese L\u00f6sung wissen, bevor Sie fortfahren:<\/p>\n<ul>\n<li>VIP ist eine IP-Adresse, die nicht an eine bestimmte physische Netzwerkschnittstelle gebunden ist. Bei einem Ausfall des Knotens oder w\u00e4hrend geplanter Wartungsarbeiten k\u00f6nnen wir die VIP auf eine andere Ressource mit minimaler Ausfallzeit umschalten.\n<\/li>\n<li>Die Freigabe und Zuteilung einer virtuellen IP-Adresse sind kosteng\u00fcnstige und schnelle Operationen.\n<\/li>\n<li>F\u00fcr die Arbeit mit VIP ist der Zugriff auf den Server \u00fcber SSH oder die Verwendung spezieller Dienstprogramme erforderlich, zum Beispiel <code>keepalived<\/code>.\n<\/li>\n<\/ul>\n<p>\nBetrachten wir die m\u00f6glichen Probleme mit unserem Master und wie der Mechanismus zur automatischen Wiederherstellung funktionieren sollte.<\/p>\n<h4>Es gibt keine Netzwerkverbindung zum Master, oder es gibt ein Problem auf der Hardware-Ebene, und der Server ist nicht verf\u00fcgbar.<\/h4>\n<p><\/p>\n<ol>\n<li>Der Orchestrator aktualisiert die Topologie des Clusters, jede Replik meldet die Nichterreichbarkeit des Masters. Der Orchestrator startet den Prozess zur Auswahl einer Replik, die als neuer Master geeignet ist, und beginnt mit der Wiederherstellung.\n<\/li>\n<li>Wir versuchen, die VIP vom alten Master zu entfernen \u2013 ohne Erfolg.\n<\/li>\n<li>Die Replik schaltet in die Rolle des Masters um. Die Topologie wird neu strukturiert.\n<\/li>\n<li>Wir f\u00fcgen eine neue Netzwerkschnittstelle mit VIP hinzu. Da das Entfernen der VIP nicht erfolgreich war, starten wir im Hintergrund das regelm\u00e4\u00dfige Senden von Anfragen <b>gratuitous ARP<\/b>. Diese Art von Anfrage\/Antwort erm\u00f6glicht es, die Zuordnungstabelle von IP- und MAC-Adressen auf den angeschlossenen Switches zu aktualisieren, wodurch wir \u00fcber den Umzug unserer VIP informieren. Dadurch wird die Wahrscheinlichkeit eines <code>split brain<\/code> bei der R\u00fcckkehr des alten Masters minimiert. \n<\/li>\n<li>Alle neuen Verbindungen werden sofort an den neuen Master umgeleitet. Alte Verbindungen schlagen fehl, es erfolgen erneute Zugriffe auf die DB auf Anwendungsebene.\n<\/li>\n<\/ol>\n<p><\/p>\n<h4>Der Server arbeitet im normalen Modus, es gab einen Ausfall auf der Ebene der DBMS.<\/h4>\n<p>\nDer Algorithmus \u00e4hnelt dem vorherigen Fall: Aktualisierung der Topologie und Start des Wiederherstellungsprozesses. Da der Server verf\u00fcgbar ist, geben wir die VIP erfolgreich vom alten Master frei, \u00fcbertragen sie auf den neuen und senden einige ARP-Anfragen. Eine m\u00f6gliche R\u00fcckkehr des alten Masters sollte die neu strukturierte Cluster und die Arbeit der Anwendung nicht beeintr\u00e4chtigen.<\/p>\n<h4>Andere Probleme<\/h4>\n<p>\nAusfall von Replikaten oder Zwischenmastern <em>f\u00fchrt nicht<\/em> zu automatischen Ma\u00dfnahmen und erfordert manuelles Eingreifen.<\/p>\n<p>Das virtuelle Netzwerk-Interface wird immer vor\u00fcbergehend hinzugef\u00fcgt, das hei\u00dft, nach einem Neustart des Servers wird die VIP automatisch nicht zugewiesen. Jede DB-Instanz startet standardm\u00e4\u00dfig im Nur-Lese-Modus, der Orchestrator wechselt automatisch den neuen Master auf Schreibzugriff und versucht, zu etablieren <code>nur lesen<\/code> auf dem alten Master. Diese Ma\u00dfnahmen zielen darauf ab, die Wahrscheinlichkeit zu verringern <code>split brain<\/code>.<\/p>\n<p>Im Wiederherstellungsprozess k\u00f6nnen Probleme auftreten, \u00fcber die auch \u00fcber die Benutzeroberfl\u00e4che des Orchestrators neben den Standard\u00fcberwachungsinstrumenten informiert werden sollte. Wir haben die REST API erweitert, um eine solche M\u00f6glichkeit hinzuzuf\u00fcgen (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/pull\/1088\">PR<\/a><\/noindex> ist derzeit in Pr\u00fcfung).<\/p>\n<p>Das allgemeine Schema der HA-L\u00f6sung ist unten dargestellt.<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator und VIP als HA-L\u00f6sung f\u00fcr das MySQL-Cluster\" src=\"\/wp-content\/uploads\/2020\/05\/485dbbc8f2b1a7595f5fa4f36ad92f7e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Auswahl eines neuen Masters<\/h1>\n<p>\nDer Orchestrator ist ziemlich intelligent und versucht, auszuw\u00e4hlen <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/blob\/5126b849ae4f655e1cbe0fbddfa0d7299674f712\/go\/inst\/instance_utils.go#L112\">die am besten geeignete Replik<\/a><\/noindex> als neuen Master anhand der folgenden Kriterien:<\/p>\n<ul>\n<li>R\u00fcckstand der Replik vom Master;\n<\/li>\n<li>Version von MySQL des Masters und der Replik;\n<\/li>\n<li>Replikationsart (RBR, SBR oder gemischt);\n<\/li>\n<li>Standort in einem oder verschiedenen Rechenzentren;\n<\/li>\n<li>die Existenz <code>fehlerhafte GTID<\/code> \u2013 Transaktionen, die auf der Replik ausgef\u00fchrt wurden und auf dem Master fehlen;\n<\/li>\n<li>es werden auch benutzerdefinierte Auswahlregeln ber\u00fccksichtigt.\n<\/li>\n<\/ul>\n<p>\nNicht jede Replik ist ein idealer Kandidat f\u00fcr die Rolle des Masters. Beispielsweise kann eine Replik f\u00fcr die Datensicherung verwendet werden oder der Server hat eine schw\u00e4chere Hardware-Konfiguration. Der Orchestrator <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/blob\/master\/docs\/topology-recovery.md#adding-promotion-rules\">unterst\u00fctzt<\/a><\/noindex> manuelle Regeln, mit denen Sie Ihre Pr\u00e4ferenzen f\u00fcr die Auswahl des Kandidaten von den am meisten bevorzugten bis zu den ignorierten konfigurieren k\u00f6nnen.<\/p>\n<h1>Reaktions- und Wiederherstellungszeit<\/h1>\n<p>\nIm Falle eines Vorfalls ist es wichtig, die Ausfallzeit des Systems zu minimieren, daher betrachten wir die MySQL-Parameter, die den Aufbau und die Aktualisierung der Cluster-Topologie durch den Orchestrator beeinflussen:<\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/dev.mysql.com\/doc\/refman\/5.7\/en\/replication-options-slave.html#sysvar_slave_net_timeout\"><code>slave_net_timeout<\/code><\/a><\/noindex> \u2013 die Anzahl der Sekunden, in denen die Replik auf das Eintreffen neuer Daten oder Heartbeat-Signale vom Master wartet, bevor die Verbindung als verloren betrachtet wird und eine Wiederverbindung erfolgt. Je kleiner der Wert, desto schneller kann die Replik feststellen, dass die Verbindung zum Master unterbrochen ist. Wir setzen diesen Wert auf 5 Sekunden.\n<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/dev.mysql.com\/doc\/refman\/5.7\/en\/change-master-to.html\"><code>MASTER_CONNECT_RETRY<\/code><\/a><\/noindex> \u2014 die Anzahl der Sekunden zwischen den Wiederverbindungsversuchen. Bei Netzwerkproblemen erm\u00f6glicht ein niedriger Wert dieses Parameters ein schnelles Wiederverbinden und verhindert, dass der Wiederherstellungsprozess des Clusters gestartet wird. Empfohlener Wert \u2014 1 Sekunde.\n<\/li>\n<li><code>MASTER_RETRY_COUNT<\/code> \u2014 die maximale Anzahl der Wiederverbindungsversuche. \n<\/li>\n<li><code>MASTER_HEARTBEAT_PERIOD<\/code> \u2014 das Intervall in Sekunden, nach dem der Master ein Heartbeat-Signal sendet. Standardm\u00e4\u00dfig betr\u00e4gt es die H\u00e4lfte des Wertes <code>slave_net_timeout<\/code>.\n<\/li>\n<\/ul>\n<p>\nParameter des Orchestrators:<\/p>\n<ul>\n<li><code>DelayMasterPromotionIfSQLThreadNotUpToDate<\/code> \u2014 wenn gleich <code>true<\/code>, wird die Rolle des Masters auf dem Kandidaten-Replikat nicht angewendet, solange der SQL-Thread der Replikation nicht alle ausstehenden Transaktionen aus dem Relay Log abgearbeitet hat. Wir verwenden diese Option, um Transaktionen bei der Verz\u00f6gerung aller Kandidaten-Replikate nicht zu verlieren.\n<\/li>\n<li><code>InstancePollSeconds<\/code> \u2014 die Frequenz der Erstellung und Aktualisierung der Topologie.\n<\/li>\n<li><code>RecoveryPollSeconds<\/code> \u2014 die Frequenz der Analyse der Topologie. Bei Erkennung eines Problems wird die Wiederherstellung der Topologie gestartet. Dies ist<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\/blob\/548265494b3107ca2581d6ccee059e062a759b77\/go\/config\/config.go#L45\"> eine Konstante<\/a><\/noindex>, die 1 Sekunde betr\u00e4gt.\n<\/li>\n<\/ul>\n<p>\nJeder Knoten des Clusters wird vom Orchestrator einmal in <code>InstancePollSeconds<\/code> Sekunden abgefragt. Bei Erkennung eines Problems wird der Status des Clusters zwangsweise<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\/blob\/548265494b3107ca2581d6ccee059e062a759b77\/go\/logic\/topology_recovery.go#L1409\"> aktualisiert<\/a><\/noindex>, und dann wird eine endg\u00fcltige Entscheidung \u00fcber die Durchf\u00fchrung der Wiederherstellung getroffen. Durch Experimentieren mit verschiedenen DB- und Orchestrator-Parametern ist es uns gelungen, die Reaktions- und Wiederherstellungszeiten auf 30 Sekunden zu reduzieren.<\/p>\n<h1>Teststand<\/h1>\n<p>\nWir haben die HA-Schemata getestet, indem wir eine lokale <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ParshinPavel\/mysql-ha-sandbox\">Testumgebung<\/a><\/noindex> entwickelt und dann in Test- und Produktionsumgebungen implementiert haben. Die lokale Testumgebung ist vollst\u00e4ndig automatisiert auf Basis von Docker und erm\u00f6glicht es, mit der Konfiguration des Orchestrators und des Netzwerks zu experimentieren, den Cluster von 2-3 Servern auf mehrere Dutzend zu skalieren und \u00dcbungen in einer sicheren Umgebung durchzuf\u00fchren. <\/p>\n<p>W\u00e4hrend der \u00dcbungen w\u00e4hlen wir eine der Methoden zur Emulation eines Problems: den Master sofort abzuschalten mittels <code>kill -9<\/code>, den Prozess sanft zu beenden und den Server anzuhalten (<code>docker-compose stop<\/code>), Netzwerkprobleme zu simulieren mit <code>iptables -j REJECT<\/code> oder <code>iptables -j DROP<\/code>. Wir erwarten folgende Ergebnisse:<\/p>\n<ul>\n<li>der Orchestrator erkennt Probleme mit dem Master und aktualisiert die Topologie in nicht mehr als 10 Sekunden;\n<\/li>\n<li>der Wiederherstellungsprozess wird automatisch gestartet: die Netzwerk- konfiguration \u00e4ndert sich, die Rolle des Masters wechselt zur Replik, die Topologie wird neu aufgebaut;\n<\/li>\n<li>Der neue Master wird f\u00fcr die Aufnahme verf\u00fcgbar sein, w\u00e4hrend die Live-Replikate im Prozess des Aufbaus nicht verloren gehen;\n<\/li>\n<li>Die Daten werden beginnen, in den neuen Master aufgezeichnet und repliziert zu werden;\n<\/li>\n<li>Die Gesamtwiederherstellungszeit wird 30 Sekunden nicht \u00fcberschreiten.\n<\/li>\n<\/ul>\n<p>\nWie Sie wissen, kann sich das System in Test- und Produktionsumgebungen aufgrund unterschiedlicher Hardware- und Netzwerkkonfigurationen, Unterschiede in synthetischen und realen Lasten usw. unterschiedlich verhalten. Daher f\u00fchren wir regelm\u00e4\u00dfig \u00dcbungen unter realen Bedingungen durch, um zu \u00fcberpr\u00fcfen, wie sich das System bei Verlust der Netzwerkverbindung oder der Degeneration einzelner Teile verh\u00e4lt. In Zukunft m\u00f6chten wir eine vollst\u00e4ndig identische Infrastruktur f\u00fcr beide Umgebungen aufbauen und deren Tests automatisieren.<\/p>\n<h1>Das DBMS Tarantool ist ein attraktives, zukunftstr\u00e4chtiges Produkt zur Erstellung von hochbelasteten Anwendungen.<\/h1>\n<p>\nDie Funktionsf\u00e4higkeit des Hauptknotens des Datenspeicher-Systems ist eine der Hauptaufgaben des SRE- und Betriebsteams. Die Implementierung des Orchestrators und der HA-L\u00f6sungen auf Basis von VIP hat die folgenden Ergebnisse gebracht:<\/p>\n<ul>\n<li>Zuverl\u00e4ssige Erkennung von Problemen mit der DB-Cluster-Topologie;\n<\/li>\n<li>Automatische und schnelle Reaktion auf Vorf\u00e4lle, die mit dem Master verbunden sind, was die Ausfallzeit des Systems reduziert.\n<\/li>\n<\/ul>\n<p>\nDas L\u00f6sung hat jedoch ihre Einschr\u00e4nkungen und Nachteile:<\/p>\n<ul>\n<li>Die Skalierung des HA-Schemas auf mehrere Rechenzentren erfordert ein einheitliches L2-Netzwerk zwischen ihnen;\n<\/li>\n<li>Bevor wir ein VIP auf dem neuen Master zuweisen, m\u00fcssen wir es freigeben auf dem alten. Der Prozess ist sequenziell, was die Wiederherstellungszeit verl\u00e4ngert;\n<\/li>\n<li>Die Freigabe des VIP erfordert SSH-Zugriff auf den Server oder irgendeine andere Methode zur Fernaufrufung von Prozessen. Da der Server oder die DB Probleme hat, die den Wiederherstellungsprozess ausgel\u00f6st haben, k\u00f6nnen wir nicht sicher sein, dass die Freigabe des VIP erfolgreich abgeschlossen wird. Dies k\u00f6nnte dazu f\u00fchren, dass zwei Server mit derselben virtuellen IP-Adresse existieren und zu Problemen f\u00fchren. <code>split brain<\/code>.\n<\/li>\n<\/ul>\n<p>\nUm dies zu vermeiden <code>split brain<\/code>, kann die Methode <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/STONITH\">STONITH<\/a><\/noindex> ('Shoot The Other Node In The Head') verwendet werden, die den problematischen Knoten vollst\u00e4ndig isoliert oder deaktiviert. Es gibt auch andere M\u00f6glichkeiten zur Umsetzung der Hochverf\u00fcgbarkeit des Clusters: eine Kombination aus VIP und DNS, Dienstentdeckung und Proxy-Dienste, synchrone Replikation und andere Methoden, die ihre eigenen Vor- und Nachteile haben.<\/p>\n<p>Ich habe unseren Ansatz zur Erstellung eines ausfallsicheren MySQL-Clusters erl\u00e4utert. Er ist einfach umzusetzen und bietet ein akzeptables Ma\u00df an Zuverl\u00e4ssigkeit unter den aktuellen Bedingungen. Mit dem Fortschritt des gesamten Systems sowie der Infrastruktur wird sich dieser Ansatz zweifellos weiterentwickeln.<br \/>\n<br \/>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/citymobil\/blog\/491044\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412 \u0421\u0438\u0442\u0438\u043c\u043e\u0431\u0438\u043b \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c \u0431\u0430\u0437\u0443 \u0434\u0430\u043d\u043d\u044b\u0445 MySQL \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0433\u043e \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u044b\u0445 \u0434\u0430\u043d\u043d\u044b\u0445. \u0423 \u043d\u0430\u0441 \u0435\u0441\u0442\u044c \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u043e\u0432 \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445 \u043f\u043e\u0434 \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u044b \u0438 \u0446\u0435\u043b\u0438. \u041f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u0430\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u044c \u043c\u0430\u0441\u0442\u0435\u0440\u0430 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043a\u0440\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u043c \u043f\u043e\u043a\u0430\u0437\u0430\u0442\u0435\u043b\u0435\u043c \u0440\u0430\u0431\u043e\u0442\u043e\u0441\u043f\u043e\u0441\u043e\u0431\u043d\u043e\u0441\u0442\u0438 \u0432\u0441\u0435\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u0438 \u0435\u0435 \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u044b\u0445 \u0447\u0430\u0441\u0442\u0435\u0439. \u0410\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0435 \u0432\u043e\u0441\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0435 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u043e\u0442\u043a\u0430\u0437\u0430 \u043c\u0430\u0441\u0442\u0435\u0440\u0430 \u0441\u0438\u043b\u044c\u043d\u043e \u0441\u043d\u0438\u0436\u0430\u0435\u0442 \u0432\u0440\u0435\u043c\u044f \u0440\u0435\u0430\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u043d\u0430 \u0438\u043d\u0446\u0438\u0434\u0435\u043d\u0442 \u0438 \u0432\u0440\u0435\u043c\u044f \u043f\u0440\u043e\u0441\u0442\u043e\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u044b. [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":82114,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-82113","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412 \u0421\u0438\u0442\u0438\u043c\u043e\u0431\u0438\u043b \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c \u0431\u0430\u0437\u0443 \u0434\u0430\u043d\u043d\u044b\u0445 MySQL \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0433\u043e \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u044b\u0445 \u0434\u0430\u043d\u043d\u044b\u0445.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Orchestrator \u0438 VIP \u043a\u0430\u043a HA-\u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u0434\u043b\u044f \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 MySQL | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412 \u0421\u0438\u0442\u0438\u043c\u043e\u0431\u0438\u043b \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c \u0431\u0430\u0437\u0443 \u0434\u0430\u043d\u043d\u044b\u0445 MySQL \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0433\u043e \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u044b\u0445 \u0434\u0430\u043d\u043d\u044b\u0445.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-05-19T11:42:51+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-05-19T11:42:51+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Orchestrator und VIP als HA-L\u00f6sung f\u00fcr das MySQL-Cluster | ProHoster","description":"Bei Citymobil verwenden wir eine MySQL-Datenbank als prim\u00e4ren Speicher f\u00fcr permanente Daten.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Orchestrator \u0438 VIP \u043a\u0430\u043a HA-\u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u0434\u043b\u044f \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 MySQL | ProHoster","og:description":"\u0412 \u0421\u0438\u0442\u0438\u043c\u043e\u0431\u0438\u043b \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c \u0431\u0430\u0437\u0443 \u0434\u0430\u043d\u043d\u044b\u0445 MySQL \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0433\u043e \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u044b\u0445 \u0434\u0430\u043d\u043d\u044b\u0445.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-05-19T11:42:51+00:00","article:modified_time":"2020-05-19T11:42:51+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"82113","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:44:23","updated":"2022-09-28 00:08:45","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/82113","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=82113"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/82113\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/82114"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=82113"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=82113"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=82113"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}