{"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\/ro\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql","title":{"rendered":"Orchestrator \u0219i VIP ca solu\u021bie HA pentru clusterul MySQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>\u00cen Sitimobil, folosim baza de date MySQL ca principal depozit pentru datele permanente. Avem mai multe clustere de baze de date pentru diferite servicii \u0219i scopuri.<\/p>\n<p>Disponibilitatea constant\u0103 a masterului este un indicator critic al func\u021bionalit\u0103\u021bii \u00eentregului sistem \u0219i al p\u0103r\u021bilor sale. Recuperarea automat\u0103 a clusterului \u00een caz de avarie a masterului reduce semnificativ timpul de reac\u021bie la incident \u0219i timpul de nefunc\u021bionare a sistemului. \u00cen acest articol, voi discuta despre schema de asigurare a disponibilit\u0103\u021bii ridicate (HA) a clusterului MySQL pe baza <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\">MySQL Orchestrator<\/a><\/noindex> \u0219i adreselor IP virtuale (VIP).<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator \u0219i VIP ca solu\u021bie HA pentru clusterul 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>Solu\u021bia HA bazat\u0103 pe VIP<\/h1>\n<p>\nMai \u00eent\u00e2i, voi prezenta pe scurt ce reprezint\u0103 sistemul nostru de stocare a datelor.<\/p>\n<p>Folosim o schem\u0103 clasic\u0103 de replicare cu un master disponibil pentru scriere \u0219i multe replici, care sunt folosite numai pentru citire. Clusterul poate con\u021bine un master intermediar \u2014 un nod care este at\u00e2t replic\u0103, c\u00e2t \u0219i master pentru altele. Clien\u021bii se conecteaz\u0103 la replici prin HAProxy, ceea ce permite o distribu\u021bie uniform\u0103 a \u00eenc\u0103rc\u0103turii \u0219i o scalare u\u0219oar\u0103. Utilizarea HAProxy se bazeaz\u0103 pe motive istorice, iar acum suntem \u00een proces de migrare c\u0103tre ProxySQL.<\/p>\n<p>Replicarea se face \u00een modul semi-sincron, pe baza <code>GTID<\/code>. Aceasta \u00eenseamn\u0103 c\u0103 cel pu\u021bin o replic\u0103 trebuie s\u0103 scrie tranzac\u021bia \u00een jurnal \u00eenainte ca aceasta s\u0103 fie considerat\u0103 reu\u0219it\u0103. Acest mod de replicare ofer\u0103 un echilibru optim \u00eentre performan\u021b\u0103 \u0219i integritatea datelor \u00een cazul unei defec\u021biuni a nodului principal. \u00cen principal, toate modific\u0103rile sunt transmise de la master la replici prin <code>Row Based Replication (RBR)<\/code>, dar unele noduri pot avea <code>mixed binlog format<\/code>.<\/p>\n<p>Orchestratorul actualizeaz\u0103 periodic starea topologiei clusterului, analizeaz\u0103 informa\u021biile primite \u0219i, \u00een cazul unor probleme, poate ini\u021bia procedura de recuperare automat\u0103. Responsabilitatea pentru procedur\u0103 revine dezvoltatorului, deoarece aceasta poate fi implementat\u0103 \u00een mai multe moduri: pe baza VIP, DNS, folosind servicii de descoperire a serviciilor (service discovery) sau mecanisme personalizate. <\/p>\n<p>Una dintre modalit\u0103\u021bile simple de restaurare a masterului \u00een cazul unei defec\u021biuni este utilizarea adreselor VIP flotante.<\/p>\n<p>Ce trebuie s\u0103 \u0219tii despre aceast\u0103 solu\u021bie \u00eenainte de a merge mai departe:<\/p>\n<ul>\n<li>VIP este o adres\u0103 IP care nu este legat\u0103 de o interfa\u021b\u0103 de re\u021bea fizic\u0103 specific\u0103. Atunci c\u00e2nd un nod e\u0219ueaz\u0103 sau \u00een timpul lucr\u0103rilor planificate, putem comuta VIP-ul pe un alt resurs\u0103 cu un timp minim de nefunc\u021bionare.\n<\/li>\n<li>Eliberarea \u0219i alocarea unei adrese IP virtuale sunt opera\u021biuni ieftine \u0219i rapide.\n<\/li>\n<li>Pentru a lucra cu VIP este necesar accesul la server prin SSH sau utilizarea de utilitare speciale, cum ar fi <code>keepalived<\/code>.\n<\/li>\n<\/ul>\n<p>\nS\u0103 analiz\u0103m problemele posibile cu maestrul nostru \u0219i s\u0103 ne imagin\u0103m cum ar trebui s\u0103 func\u021bioneze mecanismul de recuperare automat\u0103.<\/p>\n<h4>A disp\u0103rut conectivitatea de re\u021bea c\u0103tre maestru sau a ap\u0103rut o problem\u0103 la nivel de hardware, iar serverul devine inaccesibil.<\/h4>\n<p><\/p>\n<ol>\n<li>Orchestratorul actualizeaz\u0103 topologia clusterului, fiecare replic\u0103 raporteaz\u0103 indisponibilitatea maestrului. Orchestratorul ini\u021biaz\u0103 procesul de selectare a unei replici potrivite pentru rolul de nou maestru \u0219i \u00eencepe recuperarea.\n<\/li>\n<li>\u00cencerc\u0103m s\u0103 eliber\u0103m VIP-ul de la vechiul maestru - f\u0103r\u0103 succes.\n<\/li>\n<li>Replica trece \u00een rolul de maestru. Topologia se restructureaz\u0103.\n<\/li>\n<li>Adaug\u0103m o nou\u0103 interfa\u021b\u0103 de re\u021bea cu VIP. Deoarece nu am reu\u0219it s\u0103 eliber\u0103m VIP-ul, \u00een fundal ini\u021biem trimiterea periodic\u0103 a unei solicit\u0103ri <b>gratuitous ARP<\/b>. Aceast\u0103 form\u0103 de solicitare\/r\u0103spuns permite actualizarea tabelei de asocia\u021bie IP \u0219i MAC pe switch-urile conectate, notific\u00e2nd astfel despre mutarea VIP-ului nostru. Acest lucru minimizeaz\u0103 probabilitatea de <code>split brain<\/code> \u00een cazul revenirii vechiului maestru. \n<\/li>\n<li>Toate noile conexiuni sunt imediat redirec\u021bionate c\u0103tre noul maestru. Conexiunile mai vechi se finalizeaz\u0103 cu e\u0219ec, iar apelurile la baza de date la nivel de aplica\u021bie sunt repetate.\n<\/li>\n<\/ol>\n<p><\/p>\n<h4>Serverul func\u021bioneaz\u0103 \u00een mod normal, s-a produs o defectare la nivelul SGBD-ului.<\/h4>\n<p>\nAlgoritmul este similar cu cazul anterior: actualizarea topologiei \u0219i ini\u021bierea procesului de recuperare. Deoarece serverul este accesibil, eliber\u0103m cu succes VIP-ul de la vechiul maestru, \u00eel mut\u0103m pe cel nou \u0219i trimitem c\u00e2teva solicit\u0103ri ARP. O eventual\u0103 revenire a vechiului maestru nu ar trebui s\u0103 afecteze clusterul restructurat \u0219i func\u021bionarea aplica\u021biei.<\/p>\n<h4>Alte probleme<\/h4>\n<p>\nDefectarea replicilor sau a masterelor intermediare <em>nu duce<\/em> la ac\u021biuni automate \u0219i necesit\u0103 interven\u021bie manual\u0103.<\/p>\n<p>Interfa\u021bele de re\u021bea virtuale sunt ad\u0103ugate temporar, ceea ce \u00eenseamn\u0103 c\u0103 dup\u0103 repornirea serverului, VIP-ul nu este alocat automat. Fiecare instan\u021b\u0103 de baz\u0103 de date porne\u0219te \u00een mod implicit \u00een modul de citire, orchestratorul activeaz\u0103 automat un nou master pentru scriere \u0219i \u00eencearc\u0103 s\u0103 stabileasc\u0103 <code>doar citire<\/code> pe vechiul master. Aceste ac\u021biuni sunt menite s\u0103 reduc\u0103 probabilitatea <code>split brain<\/code>.<\/p>\n<p>\u00cen procesul de recuperare pot ap\u0103rea probleme, despre care ar trebui s\u0103 se notifice \u0219i prin UI-ul orchestratorului, pe l\u00e2ng\u0103 instrumentele standard de monitorizare. Am extins REST API-ul ad\u0103ug\u00e2nd aceast\u0103 capacitate (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/pull\/1088\">PR<\/a><\/noindex> este \u00een prezent \u00een examinare).<\/p>\n<p>Schema general\u0103 a solu\u021biei HA este prezentat\u0103 mai jos.<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator \u0219i VIP ca solu\u021bie HA pentru clusterul MySQL\" src=\"\/wp-content\/uploads\/2020\/05\/485dbbc8f2b1a7595f5fa4f36ad92f7e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Alegerea unui nou master<\/h1>\n<p>\nOrchestratorul este destul de inteligent \u0219i se str\u0103duie\u0219te s\u0103 aleag\u0103 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/blob\/5126b849ae4f655e1cbe0fbddfa0d7299674f712\/go\/inst\/instance_utils.go#L112\">replica cea mai potrivit\u0103<\/a><\/noindex> ca nou master pe baza urm\u0103toarelor criterii:<\/p>\n<ul>\n<li>\u00eent\u00e2rzierea replicii fa\u021b\u0103 de master;\n<\/li>\n<li>versiunea MySQL a masterului \u0219i replicii;\n<\/li>\n<li>tipul de replicare (RBR, SBR sau mixed);\n<\/li>\n<li>loca\u021bia \u00een acela\u0219i sau \u00een diferite centre de date;\n<\/li>\n<li>existen\u021ba <code>GTID eronat<\/code> \u2014 tranzac\u021bii care au fost efectuate pe replic\u0103 \u0219i lipsesc de pe master;\n<\/li>\n<li>de asemenea, se iau \u00een considerare regulile personalizate de selec\u021bie.\n<\/li>\n<\/ul>\n<p>\nNu fiecare replic\u0103 este un candidat ideal pentru rolul de master. De exemplu, replica poate fi utilizat\u0103 pentru backup de date sau serverul poate avea o configura\u021bie hardware mai slab\u0103. Orchestratorul <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/blob\/master\/docs\/topology-recovery.md#adding-promotion-rules\">sus\u021bine<\/a><\/noindex> reguli manuale, prin care se pot stabili preferin\u021bele proprii pentru alegerea candidatului de la cele mai preferate la cele ignorate.<\/p>\n<h1>Timp de reac\u021bie \u0219i recuperare<\/h1>\n<p>\n\u00cen cazul unui incident, este important s\u0103 se minimizeze timpul de nefunc\u021bionare a sistemului, de aceea s\u0103 analiz\u0103m op\u021biunile MySQL care influen\u021beaz\u0103 construirea \u0219i actualizarea topologiei clusterei de c\u0103tre orchestrator:<\/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 num\u0103rul de secunde \u00een care replica a\u0219teapt\u0103 primirea de noi date sau un semnal heartbeat de la master, \u00eenainte ca conexiunea s\u0103 fie considerat\u0103 pierdut\u0103 \u0219i s\u0103 se efectueze reconectarea. Cu c\u00e2t valoarea este mai mic\u0103, cu at\u00e2t replica poate determina mai repede c\u0103 leg\u0103tura cu masterul este \u00eentrerupt\u0103. Stabilim aceast\u0103 valoare la 5 secunde.\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 num\u0103rul de secunde \u00eentre \u00eencerc\u0103rile de reconectare. \u00cen cazul problemelor de re\u021bea, o valoare sc\u0103zut\u0103 a acestui parametru va permite reconectarea rapid\u0103 \u0219i va preveni ini\u021bierea procesului de recuperare a clusterului. Valoarea recomandat\u0103 este de 1 secund\u0103.\n<\/li>\n<li><code>MASTER_RETRY_COUNT<\/code> \u2014 num\u0103rul maxim de \u00eencerc\u0103ri de reconectare. \n<\/li>\n<li><code>MASTER_HEARTBEAT_PERIOD<\/code> \u2014 intervalul \u00een secunde dup\u0103 care masterul trimite un semnal de puls. Implicit este egal cu jum\u0103tate din valoarea <code>slave_net_timeout<\/code>.\n<\/li>\n<\/ul>\n<p>\nParametrii orchestratorului:<\/p>\n<ul>\n<li><code>DelayMasterPromotionIfSQLThreadNotUpToDate<\/code> \u2014 dac\u0103 este egal cu <code>true<\/code>, atunci rolul de master nu va fi aplicat pe replica-candidat p\u00e2n\u0103 c\u00e2nd fluxul SQL al replicii nu va aplica toate tranzac\u021biile neaplicate din Relay Log. Folosim aceast\u0103 op\u021biune pentru a nu pierde tranzac\u021bii \u00een condi\u021bii de \u00eent\u00e2rziere a tuturor replicilor-candidate.\n<\/li>\n<li><code>InstancePollSeconds<\/code> \u2014 frecven\u021ba construirea \u0219i actualizarea topologiei.\n<\/li>\n<li><code>RecoveryPollSeconds<\/code> \u2014 frecven\u021ba analizei topologiei. \u00cen cazul depist\u0103rii unei probleme, se ini\u021biaz\u0103 recuperarea topologiei. Aceasta<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\/blob\/548265494b3107ca2581d6ccee059e062a759b77\/go\/config\/config.go#L45\"> este o constant\u0103<\/a><\/noindex>, egal\u0103 cu 1 secund\u0103.\n<\/li>\n<\/ul>\n<p>\nFiecare nod al clusterului este interogat de orchestrator o dat\u0103 la <code>InstancePollSeconds<\/code> secunde. \u00cen cazul depist\u0103rii unei probleme, starea clusterului este actualizat\u0103 for\u021bat<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\/blob\/548265494b3107ca2581d6ccee059e062a759b77\/go\/logic\/topology_recovery.go#L1409\"> , iar apoi se ia o decizie final\u0103 cu privire la executarea recuper\u0103rii. Experiment\u00e2nd cu diferi\u021bi parametri ai DB \u0219i ai orchestratorului, am reu\u0219it s\u0103 reducem durata de reac\u021bie \u0219i recuperare la 30 de secunde.<\/a><\/noindex>Testarea schemei HA a \u00eenceput cu dezvoltarea unui<\/p>\n<h1>Banc de testare<\/h1>\n<p>\nstand de testare local <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ParshinPavel\/mysql-ha-sandbox\">\u0219i ulterior implementarea acestuia \u00een medii de testare \u0219i produc\u021bie. Standul local este complet automatizat pe baza Docker \u0219i permite experimentarea cu configura\u021bia orchestratoului \u0219i a re\u021belei, scalarea clusterului de la 2-3 servere la c\u00e2teva zeci \u0219i desf\u0103\u0219urarea exerci\u021biilor \u00eentr-un mediu sigur.<\/a><\/noindex> \u00cen timpul exerci\u021biilor, alegem una dintre metodele de simulare a problemei: a opri instantaneu masterul folosind <\/p>\n<p>, a \u00eencheia procesul \u00een mod elegant \u0219i a opri serverul ( <code>kill -9<\/code>docker-compose stop<code>), a simula probleme de re\u021bea folosind<\/code>iptables -j REJECT <code>iptables -j DROP<\/code> sau <code>. Ne a\u0219tept\u0103m la urm\u0103toarele rezultate:<\/code>orchestratorul va depista probleme cu masterul \u0219i va actualiza topologia \u00een maximum 10 secunde;<\/p>\n<ul>\n<li>procedura de recuperare va demara automat: configura\u021bia re\u021belei se va schimba, rolul de master va trece la replica, topologia se va reconstrui;\n<\/li>\n<li>procedura de recuperare va fi ini\u021biat\u0103 automat: configura\u021bia re\u021belei se va schimba, rolul de master va fi transferat c\u0103tre replica, topologia va fi restructurat\u0103;\n<\/li>\n<li>noul master va deveni disponibil pentru scriere, replicile active nu vor fi pierdute \u00een procesul de reconstruc\u021bie;\n<\/li>\n<li>datele vor \u00eencepe s\u0103 fie scrise \u00een noul master \u0219i s\u0103 fie replicat;\n<\/li>\n<li>timpul total de recuperare va fi de maximum 30 de secunde.\n<\/li>\n<\/ul>\n<p>\nDup\u0103 cum \u0219ti\u021bi, sistemul poate ac\u021biona diferit \u00een mediile de testare \u0219i produc\u021bie din cauza configura\u021biei diferite a hardware-ului \u0219i re\u021belei, diferen\u021belor dintre sarcinile sintetice \u0219i reale etc. Prin urmare, periodic desf\u0103\u0219ur\u0103m exerci\u021bii \u00een condi\u021bii reale, test\u00e2nd cum se comport\u0103 sistemul \u00een cazul pierderii conectivit\u0103\u021bii de re\u021bea sau degrad\u0103rii unor p\u0103r\u021bi ale acestuia. \u00cen viitor, dorim s\u0103 construim o infrastructur\u0103 complet identic\u0103 pentru ambele medii \u0219i s\u0103 automatiz\u0103m testarea acesteia.<\/p>\n<h1>Conclusions<\/h1>\n<p>\nFunc\u021bionarea principalului nod al sistemului de stocare a datelor este una dintre sarcinile principale ale echipei SRE \u0219i opera\u021biunilor. Implementarea orchestratorului \u0219i a solu\u021biei HA bazate pe VIP a permis ob\u021binerea urm\u0103toarelor rezultate:<\/p>\n<ul>\n<li>detectarea fiabil\u0103 a problemelor cu topologia cluster-ului DB;\n<\/li>\n<li>reac\u021bia automat\u0103 \u0219i rapid\u0103 la incidentele legate de master, ceea ce reduce timpul de nefunc\u021bionare al sistemului.\n<\/li>\n<\/ul>\n<p>\nCu toate acestea, solu\u021bia are limit\u0103rile \u0219i dezavantajele sale:<\/p>\n<ul>\n<li>extinderea schemei HA pe mai multe centre de date va necesita o re\u021bea L2 unic\u0103 \u00eentre acestea;\n<\/li>\n<li>\u00eenainte de a atribui VIP noului master, trebuie s\u0103-l eliber\u0103m de pe cel vechi. Procesul este secven\u021bial, ceea ce cre\u0219te timpul de recuperare;\n<\/li>\n<li>eliberarea VIP necesit\u0103 acces SSH la server, sau orice alt mod de a apela proceduri la distan\u021b\u0103. Deoarece serverul sau DB-ul \u00eent\u00e2mpin\u0103 probleme, care au cauzat procesul de recuperare, nu putem fi siguri c\u0103 eliminarea VIP-ului se va finaliza cu succes. Iar acest lucru poate duce la apari\u021bia a dou\u0103 servere cu aceea\u0219i adres\u0103 IP virtual\u0103 \u0219i la probleme <code>split brain<\/code>.\n<\/li>\n<\/ul>\n<p>\nPentru a evita <code>split brain<\/code>, se poate folosi metoda <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/STONITH\">STONITH<\/a><\/noindex> ('Shoot The Other Node In The Head'), care izoleaz\u0103 complet sau dezactiveaz\u0103 nodul problematic. Exist\u0103 \u0219i alte moduri de a implementa \u00eenalt\u0103 disponibilitate a cluster-ului: combina\u021bia de VIP \u0219i DNS, detectarea serviciilor \u0219i servicii proxy, replicarea sincron\u0103 \u0219i alte metode, fiecare av\u00e2nd propriile dezavantaje \u0219i avantaje.<\/p>\n<p>Am vorbit despre abordarea noastr\u0103 \u00een crearea unui cluster MySQL rezistent la erori. Este simplu de implementat \u0219i ofer\u0103 un nivel acceptabil de fiabilitate \u00een condi\u021biile actuale. Pe m\u0103sur\u0103 ce \u00eentreaga sistem\u0103 \u0219i infrastructura \u00een special evolueaz\u0103, aceast\u0103 abordare va evolua cu siguran\u021b\u0103.<br \/>\n<br \/>Sursa: <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.2.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\/ro\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"ro_RO\" \/>\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\/ro\/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 \u0219i VIP ca solu\u021bie HA pentru clusterul MySQL | ProHoster","description":"La Sitimobil, folosim baza de date MySQL ca principal depozit de date permanente.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","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\/ro\/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\/ro\/wp-json\/wp\/v2\/posts\/82113","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=82113"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/82113\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/82114"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=82113"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=82113"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=82113"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}