{"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\/pl\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql","title":{"rendered":"Orchestrator i VIP jako rozwi\u0105zanie HA dla klastra MySQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>W SitiMobil u\u017cywamy bazy danych MySQL jako g\u0142\u00f3wnego magazynu danych trwa\u0142ych. Posiadamy kilka klastr\u00f3w baz danych do r\u00f3\u017cnych us\u0142ug i cel\u00f3w.<\/p>\n<p>Ci\u0105g\u0142a dost\u0119pno\u015b\u0107 g\u0142\u00f3wnego w\u0119z\u0142a jest krytycznym wska\u017anikiem wydajno\u015bci ca\u0142ego systemu i jego poszczeg\u00f3lnych cz\u0119\u015bci. Automatyczne przywracanie klastra w przypadku awarii g\u0142\u00f3wnego w\u0119z\u0142a znacznie skraca czas reakcji na incydent oraz czas przestoj\u00f3w systemu. W tym artykule om\u00f3wi\u0119 schemat zapewnienia wysokiej dost\u0119pno\u015bci (HA) klastra MySQL oparty na <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\">MySQL Orchestrator<\/a><\/noindex> i wirtualnych adresach IP (VIP).<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator i VIP jako rozwi\u0105zanie HA dla klastra MySQL\" 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>Rozwi\u0105zanie HA oparte na VIP<\/h1>\n<p>\nNajpierw kr\u00f3tko opowiem o tym, czym jest nasz system przechowywania danych.<\/p>\n<p>U\u017cywamy klasycznego schematu replikacji z jednym g\u0142\u00f3wnym, dost\u0119pnym do zapisu, i wieloma replikami, kt\u00f3re s\u0105 u\u017cywane tylko do odczytu. Klaster mo\u017ce zawiera\u0107 po\u015bredniego g\u0142\u00f3wnego \u2014 w\u0119ze\u0142, kt\u00f3ry jednocze\u015bnie jest replik\u0105 i g\u0142\u00f3wnym dla innych. Klienci \u0142\u0105cz\u0105 si\u0119 z replikami przez HAProxy, co pozwala na r\u00f3wnomierne roz\u0142o\u017cenie obci\u0105\u017cenia i \u0142atwe skalowanie. U\u017cycie HAProxy ma swoje historyczne uzasadnienie i obecnie jeste\u015bmy w trakcie migracji na ProxySQL.<\/p>\n<p>Replikacja odbywa si\u0119 w trybie p\u00f3\u0142synchronicznym w oparciu o <code>GTID<\/code>. Oznacza to, \u017ce co najmniej jedna replika musi zapisa\u0107 transakcj\u0119 w dzienniku, zanim zostanie uznana za udan\u0105. Taki tryb replikacji zapewnia optymaln\u0105 r\u00f3wnowag\u0119 mi\u0119dzy wydajno\u015bci\u0105 a integralno\u015bci\u0105 danych w przypadku awarii w\u0119z\u0142a g\u0142\u00f3wnego. G\u0142\u00f3wne zmiany przekazywane s\u0105 z g\u0142\u00f3wnego w\u0119z\u0142a do replik za pomoc\u0105 <code>Row Based Replication (RBR)<\/code>, jednak niekt\u00f3re w\u0119z\u0142y mog\u0105 mie\u0107 <code>mixed binlog format<\/code>.<\/p>\n<p>Orkiestrator okresowo aktualizuje stan topologii klastra, analizuje uzyskane informacje i w przypadku wyst\u0105pienia problem\u00f3w mo\u017ce uruchomi\u0107 procedur\u0119 automatycznego przywracania. Za sam\u0105 procedur\u0119 odpowiada programista, poniewa\u017c mo\u017cna j\u0105 wdro\u017cy\u0107 na r\u00f3\u017cne sposoby: na podstawie VIP, DNS, z u\u017cyciem us\u0142ug wykrywania serwis\u00f3w (service discovery) lub w\u0142asnych mechanizm\u00f3w. <\/p>\n<p>Jednym z prostych sposob\u00f3w przywracania g\u0142\u00f3wnego w\u0119z\u0142a w przypadku jego awarii jest u\u017cycie p\u0142ywaj\u0105cych adres\u00f3w VIP.<\/p>\n<p>Co trzeba wiedzie\u0107 o tym rozwi\u0105zaniu, zanim przejdziemy dalej:<\/p>\n<ul>\n<li>VIP to adres IP, kt\u00f3ry nie jest przypisany do konkretnego fizycznego interfejsu sieciowego. W przypadku awarii w\u0119z\u0142a lub podczas prac konserwacyjnych mo\u017cemy prze\u0142\u0105czy\u0107 VIP na inne zasoby w minimalnym czasie przestoju.\n<\/li>\n<li>Zwolenie i przyznawanie wirtualnego adresu IP to tanie i szybkie operacje.\n<\/li>\n<li>Aby pracowa\u0107 z VIP, wymagany jest dost\u0119p do serwera przez SSH lub wykorzystanie specjalnych narz\u0119dzi, takich jak <code>keepalived<\/code>.\n<\/li>\n<\/ul>\n<p>\nPrzeanalizujmy mo\u017cliwe problemy z naszym mistrzem i przedstawmy, jak powinien dzia\u0142a\u0107 mechanizm automatycznego przywracania.<\/p>\n<h4>Utracono \u0142\u0105czno\u015b\u0107 sieciow\u0105 z mistrzem lub pojawi\u0142 si\u0119 problem na poziomie 'sprz\u0119tu', a serwer jest niedost\u0119pny.<\/h4>\n<p><\/p>\n<ol>\n<li>Orkiestrator aktualizuje topologi\u0119 klastra, ka\u017cda replika informuje o niedost\u0119pno\u015bci mistrza. Orkiestrator uruchamia proces wyboru repliki, kt\u00f3ra mo\u017ce pe\u0142ni\u0107 rol\u0119 nowego mistrza, i rozpoczyna przywracanie.\n<\/li>\n<li>Pr\u00f3bujemy usun\u0105\u0107 VIP ze starego mistrza \u2014 bezskutecznie.\n<\/li>\n<li>Replika prze\u0142\u0105cza si\u0119 w rol\u0119 mistrza. Topologia zostaje przekszta\u0142cona.\n<\/li>\n<li>Dodajemy nowy interfejs sieciowy z VIP. Poniewa\u017c nie uda\u0142o si\u0119 usun\u0105\u0107 VIP, w tle uruchamiamy okresowe wysy\u0142anie zapytania <b>gratuitous ARP<\/b>. Ten typ zapytania\/odpowiedzi pozwala zaktualizowa\u0107 na pod\u0142\u0105czonych prze\u0142\u0105cznikach tabel\u0119 przyporz\u0105dkowania adres\u00f3w IP do MAC, informuj\u0105c tym samym o przeprowadzce naszego VIP. Minimalizuje to ryzyko <code>split brain<\/code> w przypadku powrotu starego mistrza. \n<\/li>\n<li>Wszystkie nowe po\u0142\u0105czenia natychmiast kierowane s\u0105 do nowego mistrza. Stare po\u0142\u0105czenia ko\u0144cz\u0105 si\u0119 niepowodzeniem, nast\u0119puj\u0105 ponowne pr\u00f3by na poziomie aplikacji.\n<\/li>\n<\/ol>\n<p><\/p>\n<h4>Serwer dzia\u0142a w normalnym trybie, wyst\u0105pi\u0142a awaria na poziomie DBMS.<\/h4>\n<p>\nAlgorytm jest podobny do poprzedniego przypadku: aktualizacja topologii i uruchomienie procesu przywracania. Poniewa\u017c serwer jest dost\u0119pny, skutecznie zwalniamy VIP na starym mistrzu, przenosimy go na nowy i wysy\u0142amy kilka zapyta\u0144 ARP. Potencjalny powr\u00f3t starego mistrza nie powinien mie\u0107 wp\u0142ywu na przekszta\u0142cony klaster i dzia\u0142anie aplikacji.<\/p>\n<h4>Inne problemy<\/h4>\n<p>\nAwaria replik lub po\u015brednich mistrz\u00f3w <em>nie prowadzi<\/em> do automatycznych dzia\u0142a\u0144 i wymaga r\u0119cznej interwencji.<\/p>\n<p>Wirtualny interfejs sieciowy jest zawsze dodawany tymczasowo, to znaczy po ponownym uruchomieniu serwera VIP nie jest automatycznie przydzielany. Ka\u017cdy egzemplarz bazy danych domy\u015blnie dzia\u0142a w trybie tylko do odczytu, a orkiestrator automatycznie prze\u0142\u0105cza nowego mastera na zapis i stara si\u0119 ustawi\u0107 <code>tylko do odczytu<\/code> na starym masterze. Dzia\u0142ania te maj\u0105 na celu zmniejszenie prawdopodobie\u0144stwa <code>split brain<\/code>.<\/p>\n<p>W procesie przywracania mog\u0105 wyst\u0105pi\u0107 problemy, o kt\u00f3rych r\u00f3wnie\u017c warto informowa\u0107 przez UI orkiestratora opr\u00f3cz standardowych \u015brodk\u00f3w monitoruj\u0105cych. Rozszerzyli\u015bmy REST API, dodaj\u0105c tak\u0105 mo\u017cliwo\u015b\u0107 (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/pull\/1088\">PR<\/a><\/noindex> jest aktualnie rozwa\u017cane).<\/p>\n<p>Og\u00f3lny schemat rozwi\u0105zania HA przedstawiono poni\u017cej.<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator i VIP jako rozwi\u0105zanie HA dla klastra MySQL\" src=\"\/wp-content\/uploads\/2020\/05\/485dbbc8f2b1a7595f5fa4f36ad92f7e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Wyb\u00f3r nowego mastera<\/h1>\n<p>\nOrkiestrator jest wystarczaj\u0105co inteligentny i stara si\u0119 wybra\u0107 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/blob\/5126b849ae4f655e1cbe0fbddfa0d7299674f712\/go\/inst\/instance_utils.go#L112\">najbardziej odpowiedni\u0105 replik\u0119<\/a><\/noindex> jako nowego mastera wed\u0142ug nast\u0119puj\u0105cych kryteri\u00f3w:<\/p>\n<ul>\n<li>op\u00f3\u017anienie repliki w stosunku do mastera;\n<\/li>\n<li>wersja MySQL mastera i repliki;\n<\/li>\n<li>typ replikacji (RBR, SBR lub mixed);\n<\/li>\n<li>lokalizacja w jednym lub r\u00f3\u017cnych centrach danych;\n<\/li>\n<li>obecno\u015b\u0107 <code>errant GTID<\/code> \u2014 transakcje, kt\u00f3re zosta\u0142y wykonane na replikach i brakuj\u0105 na masterze;\n<\/li>\n<li>tak\u017ce brane s\u0105 pod uwag\u0119 zasady wyboru u\u017cytkownika.\n<\/li>\n<\/ul>\n<p>\nNie ka\u017cda replika jest idealnym kandydatem na rol\u0119 mastera. Na przyk\u0142ad, replika mo\u017ce by\u0107 u\u017cywana do tworzenia kopii zapasowych danych lub serwer mo\u017ce mie\u0107 s\u0142absz\u0105 konfiguracj\u0119 \u201esprz\u0119tu\u201d. Orkiestrator <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/blob\/master\/docs\/topology-recovery.md#adding-promotion-rules\">wspiera<\/a><\/noindex> r\u0119czne zasady, za pomoc\u0105 kt\u00f3rych mo\u017cna dostosowa\u0107 swoje preferencje dotycz\u0105ce wyboru kandydata od najbardziej preferowanych do ignorowanych.<\/p>\n<h1>Czas reakcji i przywracania<\/h1>\n<p>\nW przypadku incydentu wa\u017cne jest, aby zminimalizowa\u0107 czas przestoju systemu, dlatego rozwa\u017cymy parametry MySQL, kt\u00f3re wp\u0142ywaj\u0105 na budowanie i aktualizacj\u0119 topologii klastra przez orkiestratora:<\/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> \u2014 liczba sekund, w ci\u0105gu kt\u00f3rych replika oczekuje na nowe dane lub sygna\u0142 heartbeat od mastera, zanim po\u0142\u0105czenie zostanie uznane za utracone i nast\u0105pi ponowne po\u0142\u0105czenie. Im mniejsza warto\u015b\u0107, tym szybciej replika mo\u017ce okre\u015bli\u0107, \u017ce po\u0142\u0105czenie z masterem zosta\u0142o przerwane. Ustalamy t\u0119 warto\u015b\u0107 na 5 sekund.\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 liczba sekund pomi\u0119dzy pr\u00f3bami ponownego po\u0142\u0105czenia. W przypadku problem\u00f3w z sieci\u0105 niska warto\u015b\u0107 tego parametru umo\u017cliwi szybkie ponowne po\u0142\u0105czenie i zapobiegnie uruchomieniu procesu przywracania klastra. Zalecana warto\u015b\u0107 to 1 sekunda.\n<\/li>\n<li><code>MASTER_RETRY_COUNT<\/code> \u2014 maksymalna liczba pr\u00f3b ponownego po\u0142\u0105czenia. \n<\/li>\n<li><code>MASTER_HEARTBEAT_PERIOD<\/code> \u2014 interwa\u0142 w sekundach, po kt\u00f3rym mistrz wysy\u0142a sygna\u0142 heartbeat. Domy\u015blnie wynosi po\u0142ow\u0119 warto\u015bci <code>slave_net_timeout<\/code>.\n<\/li>\n<\/ul>\n<p>\nParametry orkiestratora:<\/p>\n<ul>\n<li><code>DelayMasterPromotionIfSQLThreadNotUpToDate<\/code> \u2014 je\u015bli jest r\u00f3wny <code>true<\/code>, to rola mistrza nie zostanie zastosowana na replikacie-kandydacie, dop\u00f3ki w\u0105tek SQL repliki nie wykona wszystkich niewykonanych transakcji z Relay Log. U\u017cywamy tej opcji, aby nie utraci\u0107 transakcji w warunkach op\u00f3\u017anienia wszystkich replik-kandydat\u00f3w.\n<\/li>\n<li><code>InstancePollSeconds<\/code> \u2014 cz\u0119stotliwo\u015b\u0107 budowania i aktualizowania topologii.\n<\/li>\n<li><code>RecoveryPollSeconds<\/code> \u2014 cz\u0119stotliwo\u015b\u0107 analizy topologii. W przypadku wykrycia problemu uruchamiane jest przywracanie topologii. To<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\/blob\/548265494b3107ca2581d6ccee059e062a759b77\/go\/config\/config.go#L45\"> sta\u0142a<\/a><\/noindex>, r\u00f3wna 1 sekundzie.\n<\/li>\n<\/ul>\n<p>\nKa\u017cdy w\u0119ze\u0142 klastra jest sprawdzany przez orkiestratora raz na <code>InstancePollSeconds<\/code> sekund. Po wykryciu problemu stan klastra jest przymusowo<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\/blob\/548265494b3107ca2581d6ccee059e062a759b77\/go\/logic\/topology_recovery.go#L1409\"> aktualizowany<\/a><\/noindex>, a nast\u0119pnie podejmowana jest ostateczna decyzja o przeprowadzeniu przywracania. Eksperymentuj\u0105c z r\u00f3\u017cnymi parametrami Bazy Danych i orkiestratora, uda\u0142o nam si\u0119 skr\u00f3ci\u0107 czas reakcji i przywracania do 30 sekund.<\/p>\n<h1>Stojak testowy<\/h1>\n<p>\nTestowanie schematu HA rozpocz\u0119li\u015bmy od opracowania lokalnego <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ParshinPavel\/mysql-ha-sandbox\">sto\u0142u testowego<\/a><\/noindex> i dalszej implementacji w \u015brodowiskach testowych i produkcyjnych. Lokalny st\u00f3\u0142 jest ca\u0142kowicie zautomatyzowany na bazie Dockera i pozwala na eksperymentowanie z konfiguracj\u0105 orkiestratora i sieci, skalowanie klastra z 2-3 serwer\u00f3w do kilkudziesi\u0119ciu i przeprowadzanie \u0107wicze\u0144 w bezpiecznym \u015brodowisku. <\/p>\n<p>Podczas \u0107wicze\u0144 wybieramy jedn\u0105 z metod symulacji problemu: natychmiastowe zabicie mistrza za pomoc\u0105 <code>kill -9<\/code>, delikatne zamkni\u0119cie procesu i zatrzymanie serwera (<code>docker-compose stop<\/code>), symulowanie problem\u00f3w z sieci\u0105 za pomoc\u0105 <code>iptables -j REJECT<\/code> lub <code>iptables -j DROP.<\/code>Oczekujemy takich wynik\u00f3w:<\/p>\n<ul>\n<li>orkiestrator wykryje problemy z mistrzem i zaktualizuje topologi\u0119 w mniej ni\u017c 10 sekund;\n<\/li>\n<li>procedura przywracania uruchomi si\u0119 automatycznie: zmieni si\u0119 konfiguracja sieciowa, rola mistrza przejdzie do repliki, topologia zostanie przebudowana;\n<\/li>\n<li>Nowy master b\u0119dzie dost\u0119pny do zapis\u00f3w, a bie\u017c\u0105ce repliki nie zostan\u0105 utracone podczas przebudowy;\n<\/li>\n<li>Dane zaczn\u0105 by\u0107 zapisywane na nowym masterze i replikowane;\n<\/li>\n<li>\u0141\u0105czny czas przywracania nie przekroczy 30 sekund.\n<\/li>\n<\/ul>\n<p>\nJak wiemy, system mo\u017ce dzia\u0142a\u0107 r\u00f3\u017cnie w \u015brodowisku testowym i produkcyjnym z powodu r\u00f3\u017cnej konfiguracji sprz\u0119tu oraz sieci, r\u00f3\u017cnic w obci\u0105\u017ceniu syntetycznym i rzeczywistym itd. Dlatego okresowo przeprowadzamy \u0107wiczenia w realnych warunkach, sprawdzaj\u0105c, jak system zachowuje si\u0119 w przypadku utraty \u0142\u0105czno\u015bci sieciowej lub degradacji jego poszczeg\u00f3lnych cz\u0119\u015bci. W przysz\u0142o\u015bci chcemy zbudowa\u0107 ca\u0142kowicie identyczn\u0105 infrastruktur\u0119 dla obu \u015brodowisk i zautomatyzowa\u0107 jej testowanie.<\/p>\n<h1>Wnioski<\/h1>\n<p>\nSprawno\u015b\u0107 g\u0142\u00f3wnego w\u0119z\u0142a systemu przechowywania danych jest jednym z g\u0142\u00f3wnych zada\u0144 zespo\u0142u SRE i operacyjnego. Wdro\u017cenie orkiestratora oraz rozwi\u0105zania HA opartego na VIP pozwoli\u0142o osi\u0105gn\u0105\u0107 nast\u0119puj\u0105ce rezultaty:<\/p>\n<ul>\n<li>Niezawodne wykrywanie problem\u00f3w z topologi\u0105 klastra bazy danych;\n<\/li>\n<li>Automatyczna i szybka reakcja na incydenty zwi\u0105zane z masterem, co zmniejsza czas przestoj\u00f3w systemu.\n<\/li>\n<\/ul>\n<p>\nJednak rozwi\u0105zanie ma swoje ograniczenia i wady:<\/p>\n<ul>\n<li>Skalowanie schematu HA na kilka centr\u00f3w danych wymaga posiadania jednolitej sieci L2 mi\u0119dzy nimi;\n<\/li>\n<li>Przed przypisaniem VIP do nowego mastera musimy zwolni\u0107 go na starym. Proces jest sekwencyjny, co wyd\u0142u\u017ca czas przywracania;\n<\/li>\n<li>Zwolnienie VIP wymaga dost\u0119pu SSH do serwera lub innego sposobu wywo\u0142ania zdalnych procedur. Poniewa\u017c serwer lub baza danych napotyka problemy prowadz\u0105ce do procesu przywracania, nie mo\u017cemy by\u0107 pewni, \u017ce zwolnienie VIP zako\u0144czy si\u0119 powodzeniem. Mo\u017ce to prowadzi\u0107 do powstania dw\u00f3ch serwer\u00f3w z tym samym wirtualnym adresem IP i zwi\u0105zanych z tym problem\u00f3w. <code>split brain<\/code>.\n<\/li>\n<\/ul>\n<p>\nAby unikn\u0105\u0107 <code>split brain<\/code>, mo\u017cna zastosowa\u0107 metod\u0119 <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/STONITH\">STONITH<\/a><\/noindex> ('Shoot The Other Node In The Head'), kt\u00f3ra ca\u0142kowicie izoluje lub wy\u0142\u0105cza problemowy w\u0119ze\u0142. Istniej\u0105 tak\u017ce inne sposoby wdra\u017cania wysokiej dost\u0119pno\u015bci klastra: kombinacja VIP i DNS, wykrywanie us\u0142ug i serwisy proxy, synchronizowana replikacja oraz inne metody, kt\u00f3re maj\u0105 swoje wady i zalety.<\/p>\n<p>Opowiedzia\u0142em o naszym podej\u015bciu do tworzenia odpornego klastra MySQL. Jest ono proste w realizacji i zapewnia akceptowalny poziom niezawodno\u015bci w obecnych warunkach. W miar\u0119 rozwoju ca\u0142ego systemu oraz infrastruktury, to podej\u015bcie z pewno\u015bci\u0105 b\u0119dzie ewoluowa\u0107.<br \/>\n<br \/>\u0179r\u00f3d\u0142o: <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\/pl\/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=\"pl_PL\" \/>\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\/pl\/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 i VIP jako rozwi\u0105zanie HA dla klastra MySQL | ProHoster","description":"W Sitimobil u\u017cywamy bazy danych MySQL jako g\u0142\u00f3wnego magazynu danych trwa\u0142ych.","canonical_url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pl_PL","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\/pl\/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\/pl\/wp-json\/wp\/v2\/posts\/82113","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/comments?post=82113"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/82113\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media\/82114"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=82113"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=82113"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=82113"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}