{"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\/da\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql","title":{"rendered":"Orchestrator og VIP som HA-l\u00f8sning for MySQL-kluster","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>I Sitimobil bruger vi MySQL-databasen som vores prim\u00e6re lager til vedholdende data. Vi har flere databaseklustre til forskellige tjenester og form\u00e5l.<\/p>\n<p>Den vedholdende tilg\u00e6ngelighed af masteren er en kritisk indikator for funktionaliteten i hele systemet og dets enkelte dele. Den automatiske gendannelse af klusteret i tilf\u00e6lde af masterfejl reducerer kraftigt responstiden p\u00e5 h\u00e6ndelser og systemnedetid. I denne artikel vil jeg gennemg\u00e5 opstillingen for h\u00f8j tilg\u00e6ngelighed (HA) af MySQL-klusteret baseret p\u00e5 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\">MySQL Orchestrator<\/a><\/noindex> og virtuelle IP-adresser (VIP).<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator og VIP som HA-l\u00f8sning for MySQL-kluster\" 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\u00f8sning baseret p\u00e5 VIP<\/h1>\n<p>\nF\u00f8rst vil jeg kort beskrive, hvad vores datalagringssystem indeb\u00e6rer.<\/p>\n<p>Vi anvender den klassiske replikationsordning med \u00e9n master, der er tilg\u00e6ngelig for skrivning, og mange replikaer, der kun bruges til l\u00e6sning. Klusteret kan indeholde en mellemliggende master \u2014 en node, der samtidig er b\u00e5de replik og master for andre. Klienter henvender sig til replikaerne gennem HAProxy, hvilket tillader j\u00e6vn belastningsfordeling og nem skalering. Brugen af HAProxy skyldes historiske \u00e5rsager, og vi er i \u00f8jeblikket i gang med at migrere til ProxySQL.<\/p>\n<p>Replikationen udf\u00f8res i halvsynkron tilstand baseret p\u00e5 <code>GTID<\/code>. Det betyder, at mindst \u00e9n replik skal registrere transaktionen i loggen, f\u00f8r den betragtes som vellykket. Denne replikationsmetode sikrer den optimale balance mellem ydeevne og dataintegritet i tilf\u00e6lde af svigt af hovednoden. Generelt overf\u00f8res alle \u00e6ndringer fra masteren til replikaerne ved hj\u00e6lp af <code>Row Based Replication (RBR)<\/code>, men nogle noder kan have <code>mixed binlog format<\/code>.<\/p>\n<p>Orkestratoren opdaterer regelm\u00e6ssigt tilstandene i klusterets topologi, analyserer de indsamlede oplysninger, og i tilf\u00e6lde af problemer kan den starte proceduren for automatisk gendannelse. Selve proceduren styres af udvikleren, da den kan implementeres p\u00e5 forskellige m\u00e5der: baseret p\u00e5 VIP, DNS, ved hj\u00e6lp af tjenesteopdagelsestjenester eller skr\u00e6ddersyede mekanismer. <\/p>\n<p>En af de enkle m\u00e5der at gendanne masteren ved svigt er at bruge sv\u00f8mmende VIP-adresser.<\/p>\n<p>Hvad du skal vide om denne l\u00f8sning, f\u00f8r vi g\u00e5r videre:<\/p>\n<ul>\n<li>VIP er en IP-adresse, der ikke er knyttet til en specifik fysisk netv\u00e6rksgr\u00e6nseflade. N\u00e5r en node fejler, eller ved planlagte vedligeholdelsesarbejder, kan vi skifte VIP til en anden ressource med minimal nedetid.\n<\/li>\n<li>Frigivelse og tildeling af en virtuel IP-adresse er billige og hurtige operationer.\n<\/li>\n<li>For at arbejde med VIP kr\u00e6ves adgang til serveren via SSH eller brug af specialv\u00e6rkt\u00f8jer, for eksempel <code>keepalived<\/code>.\n<\/li>\n<\/ul>\n<p>\nLad os overveje mulige problemer med vores master og pr\u00e6sentere, hvordan mekanismen for automatisk genopretning skal fungere.<\/p>\n<h4>Der er mistet netv\u00e6rksforbindelse til masteren, eller der er opst\u00e5et et problem p\u00e5 'hardware'-niveau, og serveren er utilg\u00e6ngelig.<\/h4>\n<p><\/p>\n<ol>\n<li>Orkestratoren opdaterer klyngens topologi, hver replika rapporterer om utilg\u00e6ngeligheden af masteren. Orkestratoren starter processen med at v\u00e6lge en replika, der er egnet til rollen som ny master, og begynder genopretningen.\n<\/li>\n<li>Vi fors\u00f8ger at fjerne VIP fra den gamle master \u2014 uden held.\n<\/li>\n<li>Replikaen skifter til rollen som master. Topologien omstruktureres.\n<\/li>\n<li>Vi tilf\u00f8jer en ny netv\u00e6rksgr\u00e6nseflade med VIP. Da det ikke lykkedes at fjerne VIP, startes der i baggrunden en periodisk afsendelse af foresp\u00f8rgsler, <b>gratuitous ARP<\/b>. Denne type anmodning\/response tillader opdatering af IP- og MAC-adresseopslagstabellen p\u00e5 de tilsluttede switches, hvilket dermed informerer om flytningen af vores VIP. Dette minimerer sandsynligheden for <code>split brain<\/code> ved tilbagevenden af den gamle master. \n<\/li>\n<li>Alle nye forbindelser omdirigeres straks til den nye master. Gamle forbindelser mislykkes, og der foretages nye foresp\u00f8rgsler til databasen p\u00e5 applikationsniveau.\n<\/li>\n<\/ol>\n<p><\/p>\n<h4>Serveren fungerer normalt, der er sket et nedbrud p\u00e5 DBMS-niveau.<\/h4>\n<p>\nAlgoritmen er lig den forrige situation: opdatering af topologien og igangs\u00e6ttelse af genopretningsprocessen. Da serveren er tilg\u00e6ngelig, frigiver vi succesfuldt VIP p\u00e5 den gamle master, flytter den til den nye og sender flere ARP-foresp\u00f8rgsler. En mulig tilbagevenden af den gamle master b\u00f8r ikke p\u00e5virke den omstrukturerede klynge og applikationens funktion.<\/p>\n<h4>Andre problemer<\/h4>\n<p>\nNedbrud af replikaer eller intermedi\u00e6re mestre <em>f\u00f8rer ikke til<\/em> automatiske handlinger og kr\u00e6ver manuel indgriben.<\/p>\n<p>Den virtuelle netv\u00e6rksgr\u00e6nseflade tilf\u00f8jes altid midlertidigt, det vil sige, at efter genstart af serveren tildeles VIP automatisk ikke. Hver DB-instans starter som standard i skrivebeskyttet tilstand, orkestret skifter automatisk den nye master til skrivning og fors\u00f8ger at etablere <code>skrivebeskyttet<\/code> p\u00e5 den gamle master. Disse handlinger har til form\u00e5l at reducere sandsynligheden for <code>split brain<\/code>.<\/p>\n<p>Under genoprettelsen kan der opst\u00e5 problemer, som ogs\u00e5 b\u00f8r meddeles gennem orkestrets UI ud over de standard overv\u00e5gningsv\u00e6rkt\u00f8jer. Vi har udvidet REST API'et med en s\u00e5dan mulighed (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/pull\/1088\">PR<\/a><\/noindex> er i \u00f8jeblikket under overvejelse).<\/p>\n<p>Den overordnede skabelon for HA-l\u00f8sningen pr\u00e6senteres nedenfor.<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator og VIP som HA-l\u00f8sning for MySQL-kluster\" src=\"\/wp-content\/uploads\/2020\/05\/485dbbc8f2b1a7595f5fa4f36ad92f7e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Valg af ny master<\/h1>\n<p>\nOrkestret er tilstr\u00e6kkeligt intelligent og pr\u00f8ver at v\u00e6lge <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/blob\/5126b849ae4f655e1cbe0fbddfa0d7299674f712\/go\/inst\/instance_utils.go#L112\">den mest passende replika<\/a><\/noindex> som ny master baseret p\u00e5 f\u00f8lgende kriterier:<\/p>\n<ul>\n<li>eftersl\u00e6b af replikaen i forhold til masteren;\n<\/li>\n<li>versionen af MySQL for masteren og replikaen;\n<\/li>\n<li>typen af replikering (RBR, SBR eller mixed);\n<\/li>\n<li>placering i samme eller forskellige datacentre;\n<\/li>\n<li>tilstedev\u00e6relse <code>errant GTID<\/code> \u2014 transaktioner, der er blevet udf\u00f8rt p\u00e5 replikaen og mangler p\u00e5 masteren;\n<\/li>\n<li>brugerdefinerede regler for valg tages ogs\u00e5 i betragtning.\n<\/li>\n<\/ul>\n<p>\nIkke hver replika er en ideel kandidat til rollen som master. For eksempel kan replikaen blive brugt til sikkerhedskopiering af data, eller serveren kan have en svagere 'hardware'-konfiguration. Orkestret <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/blob\/master\/docs\/topology-recovery.md#adding-promotion-rules\">even Linus Torvalds himself \u2014 he called the WireGuard code \"a work of art.\"<\/a><\/noindex> h\u00e5ndterede regler, der g\u00f8r det muligt at indstille dine pr\u00e6ferencer for udv\u00e6lgelse af kandidater fra de mest \u00f8nskede til de ignorerede.<\/p>\n<h1>Reaktionstid og genopretning<\/h1>\n<p>\nI tilf\u00e6lde af en h\u00e6ndelse er det vigtigt at minimere systemets nedetid, s\u00e5 vi overvejer MySQL-parametrene, der p\u00e5virker opbygningen og opdateringen af cluster-topologien af orkestret:<\/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 antallet af sekunder, som replikaen venter p\u00e5 at modtage nye data eller heartbeat-signal fra masteren, f\u00f8r forbindelsen betragtes som tabt, og genoprettelse udf\u00f8res. Jo lavere v\u00e6rdi, jo hurtigere kan replikaen bestemme, at forbindelsen til masteren er brudt. Vi s\u00e6tter denne v\u00e6rdi til 5 sekunder.\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 antal sekunder mellem genforbindelsesfors\u00f8g. I tilf\u00e6lde af netv\u00e6rksproblemer vil en lav v\u00e6rdi af denne parameter muligg\u00f8re hurtig genforbindelse og forhindre, at processen med at gendanne klyngen starter. Den anbefalede v\u00e6rdi er 1 sekund.\n<\/li>\n<li><code>MASTER_RETRY_COUNT<\/code> \u2014 det maksimale antal genforbindelsesfors\u00f8g. \n<\/li>\n<li><code>MASTER_HEARTBEAT_PERIOD<\/code> \u2014 intervallet i sekunder, hvorefter master sender et heartbeat-signal. Som standard er det halvdelen af v\u00e6rdien <code>slave_net_timeout<\/code>.\n<\/li>\n<\/ul>\n<p>\nOrkestratorparametre:<\/p>\n<ul>\n<li><code>DelayMasterPromotionIfSQLThreadNotUpToDate<\/code> \u2014 hvis det er lig med <code>true<\/code>, vil masterrollen ikke blive anvendt p\u00e5 det kandidat-replika, f\u00f8r SQL-tr\u00e5den p\u00e5 replikanten har udf\u00f8rt alle de uans\u00f8gte transaktioner fra Relay Log. Vi bruger denne mulighed for ikke at miste transaktioner under betingelser, hvor alle kandidat-replikaer er bagud.\n<\/li>\n<li><code>InstancePollSeconds<\/code> \u2014 frekvensen af opbygning og opdatering af topologi.\n<\/li>\n<li><code>RecoveryPollSeconds<\/code> \u2014 frekvensen af topologianalyse. Ved opdagelse af et problem startes gendannelsen af topologi. Dette<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\/blob\/548265494b3107ca2581d6ccee059e062a759b77\/go\/config\/config.go#L45\"> er en konstant<\/a><\/noindex>, der er lig med 1 sekund.\n<\/li>\n<\/ul>\n<p>\nHver node i klyngen sp\u00f8rges af orkestratoren \u00e9n gang hvert <code>InstancePollSeconds<\/code> sekund. Ved opdagelse af et problem opdateres klyngens tilstand tvunget<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\/blob\/548265494b3107ca2581d6ccee059e062a759b77\/go\/logic\/topology_recovery.go#L1409\"> , hvorefter der tr\u00e6ffes en endelig beslutning om gendannelsen. Ved at eksperimentere med forskellige DB- og orkestratorparametre har vi v\u00e6ret i stand til at reducere svartiden og gendannelsen til 30 sekunder.<\/a><\/noindex>Testningen af HA-ordningen begyndte vi med at udvikle et lokalt<\/p>\n<h1>Testb\u00e6nk<\/h1>\n<p>\ntestmilj\u00f8 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ParshinPavel\/mysql-ha-sandbox\">og efterf\u00f8lgende implementering i test- og produktionsmilj\u00f8er. Det lokale milj\u00f8 er fuldt automatiseret baseret p\u00e5 Docker og giver mulighed for at eksperimentere med orkestratorens og netv\u00e6rkets konfiguration samt skalere klyngen fra 2-3 servere til flere dusin og gennemf\u00f8re \u00f8velser i et sikkert milj\u00f8.<\/a><\/noindex> Under \u00f8velserne v\u00e6lger vi en af metoderne til at simulere problemet: hurtigt dr\u00e6be masteren ved hj\u00e6lp af <\/p>\n<p>, blidt afslutte processen og stoppe serveren ( <code>kill -9<\/code>docker-compose stop<code>), simulere netv\u00e6rksproblemer ved hj\u00e6lp af<\/code>iptables -j REJECT <code>iptables -j DROP<\/code> eller <code>. Vi forventer f\u00f8lgende resultater:<\/code>orkestratoren vil opdage problemer med masteren og opdatere topologien p\u00e5 ikke mere end 10 sekunder;<\/p>\n<ul>\n<li>gendannelsesproceduren vil automatisk starte: netv\u00e6rkskonfigurationen vil \u00e6ndres, masterrollen vil overg\u00e5 til replikatet, topologien vil blive ombygget;\n<\/li>\n<li>proceduren for genoprettelse vil automatisk blive startet: netv\u00e6rkskonfigurationen vil \u00e6ndre sig, rollen som master vil skifte til replikatet, og topologien vil blive omstruktureret;\n<\/li>\n<li>den nye master vil v\u00e6re tilg\u00e6ngelig for skrivning, og de levende repliker vil ikke g\u00e5 tabt under ombygningen;\n<\/li>\n<li>data vil begynde at blive skrevet til den nye master og repliceres;\n<\/li>\n<li>den samlede gendannelsestid vil v\u00e6re h\u00f8jst 30 sekunder.\n<\/li>\n<\/ul>\n<p>\nSom du ved, kan systemet opf\u00f8re sig forskelligt i test- og produktionsmilj\u00f8er p\u00e5 grund af forskellig hardwarekonfiguration og netv\u00e6rk, samt forskelle i syntetisk og reel belastning osv. Derfor gennemf\u00f8rer vi j\u00e6vnligt \u00f8velser under reale forhold for at teste, hvordan systemet reagerer ved tab af netv\u00e6rksforbindelse eller nedbrydning af dets enkelte dele. I fremtiden \u00f8nsker vi at opbygge en fuldt identisk infrastruktur for begge milj\u00f8er og automatisere dens testning.<\/p>\n<h1>Konklusioner<\/h1>\n<p>\nFunktionaliteten af hovednoden i datalagringssystemet er en af de prim\u00e6re opgaver for SRE-teamet og driften. Implementeringen af orkestratoren og HA-l\u00f8sningen baseret p\u00e5 VIP har givet f\u00f8lgende resultater:<\/p>\n<ul>\n<li>p\u00e5lidelig opdagelse af problemer med DB-clusterets topologi;\n<\/li>\n<li>automatisk og hurtig reaktion p\u00e5 h\u00e6ndelser relateret til masteren, hvilket reducerer systemets nedetid.\n<\/li>\n<\/ul>\n<p>\nMen l\u00f8sningen har sine begr\u00e6nsninger og ulemper:<\/p>\n<ul>\n<li>skalerings-HA-skemaet p\u00e5 flere datacentre kr\u00e6ver en f\u00e6lles L2-netv\u00e6rk mellem dem;\n<\/li>\n<li>f\u00f8r vi tildeler VIP p\u00e5 den nye master, skal vi frig\u00f8re det p\u00e5 den gamle. Processen er sekventiel, hvilket \u00f8ger gendannelsestiden;\n<\/li>\n<li>frigivelse af VIP kr\u00e6ver SSH-adgang til serveren eller en anden metode til at kalde fjerntjenester. Da serveren eller databasen oplever problemer, der f\u00f8rte til gendannelsesprocessen, kan vi ikke v\u00e6re sikre p\u00e5, at frigivelsen af VIP vil v\u00e6re vellykket. Dette kan f\u00f8re til, at to servere har den samme virtuelle IP-adresse, hvilket skaber et problem. <code>split brain<\/code>.\n<\/li>\n<\/ul>\n<p>\nFor at undg\u00e5 <code>split brain<\/code>, kan man bruge metoden <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/STONITH\">STONITH<\/a><\/noindex> (\u201cShoot The Other Node In The Head\u201d), som fuldst\u00e6ndigt isolerer eller frakobler den problematiske node. Der er ogs\u00e5 andre m\u00e5der at implementere h\u00f8j tilg\u00e6ngelighed i klusteret: en kombination af VIP og DNS, serviceopdagelse og proxy-tjenester, synkron replikation og andre metoder, som har deres fordele og ulemper.<\/p>\n<p>Jeg har fortalt om vores tilgang til at skabe en fejltolerant MySQL-klynge. Den er enkel at implementere og giver et acceptabelt niveau af p\u00e5lidelighed under de nuv\u00e6rende forhold. Efterh\u00e5nden som hele systemet og infrastrukturen udvikler sig, vil denne tilgang uden tvivl ogs\u00e5 udvikle sig.<br \/>\n<br \/>Kilde: <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.3 - 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\/da\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\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\/da\/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 og VIP som HA-l\u00f8sning for MySQL-klyngen | ProHoster","description":"Hos SitiMobil bruger vi MySQL-databasen som vores prim\u00e6re lager for vedvarende data.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/82113","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=82113"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/82113\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/82114"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=82113"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=82113"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=82113"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}