{"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\/hr\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql","title":{"rendered":"Orchestrator i VIP kao HA-rje\u0161enje za MySQL klaster","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>U Citymobilu koristimo MySQL bazu podataka kao glavno spremi\u0161te trajnih podataka. Imamo nekoliko klastera baza podataka za razli\u010dite usluge i ciljeve.<\/p>\n<p>Stalna dostupnost glavnog \u010dvora je kriti\u010dna mjera funkcionalnosti cijelog sustava i njegovih dijelova. Automatsko obnavljanje klastera u slu\u010daju kvara glavnog \u010dvora zna\u010dajno smanjuje vrijeme reakcije na incidente i vrijeme zastoja sustava. U ovom \u010dlanku \u0107u razmotriti shemu osiguravanja visoke dostupnosti (HA) MySQL klastera temeljenog na <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\">MySQL Orchestrator<\/a><\/noindex> i virtualnim IP adresama (VIP).<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator i VIP kao HA-rje\u0161enje za MySQL klaster\" 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-rje\u0161enje temeljeno na VIP<\/h1>\n<p>\nPrvo \u0107u ukratko objasniti \u0161to predstavlja na\u0161 sustav pohrane podataka.<\/p>\n<p>Koristimo klasi\u010dnu shemu replikacije s jednim glavnim \u010dvorom koji ima pravo pisanja i brojnim replikama koje se koriste isklju\u010divo za \u010ditanje. Klaster mo\u017ee sadr\u017eavati me\u0111unavodni glavni \u010dvor \u2014 \u010dvor koji je istovremeno i replika i glavni za druge. Klijenti se obra\u0107aju replikama putem HAProxy-a, \u0161to omogu\u0107ava ravnomjerno raspore\u0111ivanje optere\u0107enja i lako skaliranje. Kori\u0161tenje HAProxy-a ima povijesne razloga i trenutno smo u procesu migracije na ProxySQL.<\/p>\n<p>Replikacija se izvodi u polusinkronom re\u017eimu na temelju <code>GTID<\/code>. To zna\u010di da najmanje jedna replika mora zabilje\u017eiti transakciju u dnevnik prije nego \u0161to bude priznata kao uspje\u0161na. Ovaj re\u017eim replikacije osigurava optimalnu ravnote\u017eu izme\u0111u performansi i o\u010duvanja podataka u slu\u010daju kvara glavnog \u010dvora. Uglavnom, sve promjene se prenose od glavnog \u010dvora do replika pomo\u0107u <code>Row Based Replication (RBR)<\/code>, ali dio \u010dvorova mo\u017ee imati <code>mixed binlog format<\/code>.<\/p>\n<p>Orkestrator povremeno a\u017eurira stanje topologije klastera, analizira dobivene informacije i u slu\u010daju problema mo\u017ee pokrenuti proceduru automatskog obnavljanja. Samu proceduru provodi developer, budu\u0107i da se mo\u017ee provesti na razli\u010dite na\u010dine: na temelju VIP, DNS-a, kori\u0161tenjem usluga otkrivanja servisa (service discovery) ili vlastitih mehanizama. <\/p>\n<p>Jedan od jednostavnih na\u010dina obnavljanja glavnog \u010dvora u slu\u010daju kvara je kori\u0161tenje plovnih VIP-adresa.<\/p>\n<p>\u0160to trebate znati o ovom rje\u0161enju prije nego \u0161to nastavite:<\/p>\n<ul>\n<li>VIP je IP adresa koja nije vezana za odre\u0111eni fizi\u010dki mre\u017eni su\u010delje. Kada do\u0111e do kvara \u010dvora ili planiranih radova, mo\u017eemo prebaciti VIP na drugi resurs s minimalnim vremenom zastoja.\n<\/li>\n<li>Osloba\u0111anje i dodjela virtualne IP adrese su jeftine i brze operacije.\n<\/li>\n<li>Za rad s VIP-om potrebna je SSH veza s poslu\u017eiteljem ili kori\u0161tenje posebnih alata, na primjer, <code>keepalived<\/code>.\n<\/li>\n<\/ul>\n<p>\nPogledajmo mogu\u0107e probleme s na\u0161im voditeljem i predstavimo kako bi trebao raditi mehanizam automatskog oporavka.<\/p>\n<h4>Izgubljena je mre\u017ena povezanost s voditeljem ili je do\u0161lo do problema na razini 'hardvera', i poslu\u017eitelj je nedostupan.<\/h4>\n<p><\/p>\n<ol>\n<li>Orkestrator a\u017eurira topologiju klastera, svaki replikant javlja o nedostupnosti voditelja. Orkestrator pokre\u0107e proces izbora replikanta koji \u0107e postati novi voditelj i zapo\u010dinje oporavak.\n<\/li>\n<li>Poku\u0161avamo skinuti VIP s starog voditelja \u2014 bezuspje\u0161no.\n<\/li>\n<li>Replikant prelazi u ulogu voditelja. Topologija se rekonstrui\u0161e.\n<\/li>\n<li>Dodajemo novo mre\u017eno su\u010delje s VIP-om. Budu\u0107i da nismo mogli skinuti VIP, u pozadini pokre\u0107emo periodi\u010dno slanje zahtjeva <b>gratuitous ARP<\/b>. Ova vrsta zahtjeva\/odgovora omogu\u0107ava a\u017euriranje tablice mapiranja IP i MAC adresa na povezanim prelaznicima, \u010dime obavje\u0161tavamo o preseljenju na\u0161eg VIP-a. To minimizira vjerojatnost <code>split brain<\/code> prilikom vra\u0107anja starog voditelja. \n<\/li>\n<li>Sve nove veze odmah se preusmjeravaju na novog voditelja. Stare veze zavr\u0161avaju neuspjehom, ponovni zahtjevi se \u0161alju na razini aplikacije prema bazi podataka.\n<\/li>\n<\/ol>\n<p><\/p>\n<h4>Poslu\u017eitelj radi u normalnom re\u017eimu, do\u0161lo je do kvara na razini DBMS-a.<\/h4>\n<p>\nAlgoritam je sli\u010dan prethodnom slu\u010daju: a\u017euriranje topologije i pokretanje procesa oporavka. Budu\u0107i da je poslu\u017eitelj dostupan, uspje\u0161no osloba\u0111amo VIP na starom voditelju, premje\u0161tamo ga na novi i \u0161aljemo nekoliko ARP zahtjeva. Mogu\u0107i povratak starog voditelja ne bi trebao utjecati na rekonstrukciju klastera i rad aplikacije.<\/p>\n<h4>Ostali problemi<\/h4>\n<p>\nKvar replikanta ili me\u0111upredajnika <em>ne dovodi<\/em> do automatskih radnji i zahtijeva ru\u010dnu intervenciju.<\/p>\n<p>Virtualno mre\u017eno su\u010delje se uvijek dodaje privremeno, tj. nakon ponovnog pokretanja servera, VIP se automatski ne dodjeljuje. Svaki primjerak DB se prema zadanim postavkama pokre\u0107e u na\u010dinu samo za \u010ditanje, orkestrator automatski prebacuje novog majstora na zapis i poku\u0161ava uspostaviti <code>samo za \u010ditanje<\/code> na starom majstoru. Ove radnje su usmjerene na smanjenje vjerojatnosti <code>split brain<\/code>.<\/p>\n<p>Tijekom procesa obnavljanja mogu se pojaviti problemi koji se tako\u0111er trebaju prijaviti putem UI orkestratora, pored standardnih alata za pra\u0107enje. Pro\u0161irili smo REST API dodaju\u0107i tu mogu\u0107nost (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/pull\/1088\">PR<\/a><\/noindex> trenutno je na razmatranju).<\/p>\n<p>Op\u0107a shema HA rje\u0161enja prikazana je u nastavku.<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator i VIP kao HA-rje\u0161enje za MySQL klaster\" src=\"\/wp-content\/uploads\/2020\/05\/485dbbc8f2b1a7595f5fa4f36ad92f7e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Odabir novog majstora<\/h1>\n<p>\nOrkestrator je dovoljno pametan i poku\u0161ava odabrati <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/blob\/5126b849ae4f655e1cbe0fbddfa0d7299674f712\/go\/inst\/instance_utils.go#L112\">najprikladniju replikaciju<\/a><\/noindex> kao novog majstora prema sljede\u0107im kriterijima:<\/p>\n<ul>\n<li>zaostatak replikacije od majstora;\n<\/li>\n<li>verzija MySQL majstora i replike;\n<\/li>\n<li>vrsta replikacije (RBR, SBR ili mixed);\n<\/li>\n<li>lokalitet u jednom ili razli\u010ditim podatkovnim centrima;\n<\/li>\n<li>postojanje <code>errant GTID<\/code> \u2014 transakcije koje su izvr\u0161ene na replici, a nedostaju na majstoru;\n<\/li>\n<li>tako\u0111er se uzimaju u obzir korisni\u010dka pravila odabira.\n<\/li>\n<\/ul>\n<p>\nSvaka replikacija nije idealan kandidat za ulogu majstora. Na primjer, repliciranje se mo\u017ee koristiti za sigurnosno kopiranje podataka, ili server ima slabiju konfiguraciju 'hardvera'. Orkestrator <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/blob\/master\/docs\/topology-recovery.md#adding-promotion-rules\">podr\u017eava<\/a><\/noindex> ru\u010dna pravila putem kojih mo\u017eete postaviti svoje preferencije za odabir kandidata od najpo\u017eeljnijih do ignoriranih.<\/p>\n<h1>Vrijeme reakcije i obnavljanja<\/h1>\n<p>\nU slu\u010daju incidenta va\u017eno je minimizirati vrijeme zastoja sustava, stoga razmatramo parametre MySQL-a koji utje\u010du na izgradnju i a\u017euriranje topologije klastera od strane orkestratora:<\/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 broj sekundi, tijekom kojih replikacija \u010deka dolazak novih podataka ili heartbeat signala od majstora, prije nego \u0161to se veza smatra izgubljenom i izvr\u0161i se ponovna veza. \u0160to je manja vrijednost, to \u0107e br\u017ee replikacija mo\u0107i odrediti da je veza s majstorom prekinuta. Postavljamo ovu vrijednost na 5 sekundi.\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 broj sekundi izme\u0111u poku\u0161aja ponovnog povezivanja. U slu\u010daju mre\u017enih problema, niska vrijednost ovog parametra omogu\u0107it \u0107e brzo ponovno povezivanje i sprije\u010diti pokretanje procesa oporavka klastera. Preporu\u010dena vrijednost je 1 sekunda.\n<\/li>\n<li><code>MASTER_RETRY_COUNT<\/code> \u2014 maksimalni broj poku\u0161aja ponovnog povezivanja. \n<\/li>\n<li><code>MASTER_HEARTBEAT_PERIOD<\/code> \u2014 interval u sekundama nakon kojeg majstor \u0161alje heartbeat signal. Po defaultu je polovica vrijednosti <code>slave_net_timeout<\/code>.\n<\/li>\n<\/ul>\n<p>\nParametri orkestratora:<\/p>\n<ul>\n<li><code>DelayMasterPromotionIfSQLThreadNotUpToDate<\/code> \u2014 ako je postavljeno na <code>true<\/code>, uloga majstora ne\u0107e biti primijenjena na kandidatu za replikaciju dok SQL tok replike ne izvr\u0161i sve neprimijenjene transakcije iz Relay Log-a. Ovu opciju koristimo kako bismo sprije\u010dili gubitak transakcija u slu\u010daju zastoja svih kandidata za replikaciju.\n<\/li>\n<li><code>InstancePollSeconds<\/code> \u2014 u\u010destalost izgradnje i a\u017euriranja topologije.\n<\/li>\n<li><code>RecoveryPollSeconds<\/code> \u2014 u\u010destalost analize topologije. U slu\u010daju otkrivanja problema pokre\u0107e se oporavak topologije. To je<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\/blob\/548265494b3107ca2581d6ccee059e062a759b77\/go\/config\/config.go#L45\"> konstanta<\/a><\/noindex>, jednaka 1 sekundi.\n<\/li>\n<\/ul>\n<p>\nSvaki \u010dvor klastera se ispituje od strane orkestratora jednom u <code>InstancePollSeconds<\/code> sekundi. Kada se otkrije problem, stanje klastera se prisilno<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\/blob\/548265494b3107ca2581d6ccee059e062a759b77\/go\/logic\/topology_recovery.go#L1409\"> a\u017eurira<\/a><\/noindex>, a zatim se donosi kona\u010dna odluka o provo\u0111enju oporavka. Eksperimentiranjem s razli\u010ditim parametrima Baze podataka i orkestratora, uspjeli smo smanjiti trajanje reagiranja i oporavka na 30 sekundi.<\/p>\n<h1>Testni sto<\/h1>\n<p>\nTestiranje HA sheme zapo\u010deli smo razvojem lokalnog <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ParshinPavel\/mysql-ha-sandbox\">testnog okru\u017eenja<\/a><\/noindex> i daljnjim implementacijama u testno i produkcijsko okru\u017eenje. Lokalno okru\u017eenje je potpuno automatizirano na temelju Dockera i omogu\u0107uje eksperimentiranje s konfiguracijom orkestratora i mre\u017ee, skaliranje klastera od 2-3 servera do nekoliko desetaka i provo\u0111enje vje\u017ebi u sigurnom okru\u017eenju. <\/p>\n<p>Tijekom vje\u017ebi odabiremo jednu od metoda simulacije problema: odmah zaustaviti majstora pomo\u0107u <code>kill -9<\/code>, nje\u017eno zavr\u0161iti proces i zaustaviti server (<code>docker-compose stop<\/code>), simulirati mre\u017ene probleme pomo\u0107u <code>iptables -j REJECT<\/code> ili <code>iptables -j DROP<\/code>. O\u010dekujemo sljede\u0107e rezultate:<\/p>\n<ul>\n<li>orkestrator \u0107e otkriti probleme s majstorom i a\u017eurirati topologiju u najvi\u0161e 10 sekundi;\n<\/li>\n<li>procedura oporavka automatski \u0107e se pokrenuti: promijenit \u0107e se mre\u017ena konfiguracija, uloga majstora pre\u0107i \u0107e na replikaciju, topologija \u0107e se preurediti;\n<\/li>\n<li>novi master bit \u0107e dostupan za pisanje, a aktivne replike ne\u0107e biti izgubljene tijekom rekonstrukcije;\n<\/li>\n<li>podaci \u0107e po\u010deti biti zapisivani u novi master i replicirani;\n<\/li>\n<li>ukupno vrijeme oporavka ne\u0107e prelaziti 30 sekundi.\n<\/li>\n<\/ul>\n<p>\nKao \u0161to znate, sustav se mo\u017ee pona\u0161ati razli\u010dito u testnom i produkcijskom okru\u017eenju zbog razli\u010dite konfiguracije 'hardvera' i mre\u017ee, razlika u sinteti\u010dkom i stvarnom optere\u0107enju itd. Stoga povremeno provodimo vje\u017ebe u stvarnim uvjetima, provjeravaju\u0107i kako sustav reagira na gubitak mre\u017ene povezanosti ili degradaciju njegovih pojedina\u010dnih dijelova. U budu\u0107nosti \u017eelimo izgraditi potpuno identi\u010dnu infrastrukturu za oba okru\u017eenja i automatizirati njezino testiranje.<\/p>\n<h1>Zaklju\u010dci<\/h1>\n<p>\nFunkcionalnost glavnog \u010dvora sustava za pohranu podataka jedan je od glavnih zadataka SRE i operativnog tima. Implementacija orkestratora i HA rje\u0161enja temeljenog na VIP-u omogu\u0107ila je postizanje sljede\u0107ih rezultata:<\/p>\n<ul>\n<li>pouzdano otkrivanje problema s topologijom klastera baze podataka;\n<\/li>\n<li>automatsko i brzo reagiranje na incidente vezane uz master, \u0161to smanjuje vrijeme zastoja sustava.\n<\/li>\n<\/ul>\n<p>\nMe\u0111utim, rje\u0161enje ima svoja ograni\u010denja i nedostatke:<\/p>\n<ul>\n<li>skaliranje HA sheme na nekoliko DC-ova zahtijevat \u0107e jedinstvenu L2 mre\u017eu izme\u0111u njih;\n<\/li>\n<li>prije nego \u0161to dodijelimo VIP na novom masteru, trebamo ga osloboditi na starom. Proces je sekvencijalan, \u0161to pove\u0107ava vrijeme oporavka;\n<\/li>\n<li>osloba\u0111anje VIP-a zahtijeva SSH pristup poslu\u017eitelju, ili neki drugi na\u010din pozivanja udaljenih proceduralnih poziva. Budu\u0107i da poslu\u017eitelj ili baza podataka imaju problema, uzrokovanih procesom oporavka, ne mo\u017eemo biti sigurni da \u0107e otpu\u0161tanje VIP-a biti uspje\u0161no. To mo\u017ee dovesti do pojave dva poslu\u017eitelja s istim virtualnim IP adresom i problema. <code>split brain<\/code>.\n<\/li>\n<\/ul>\n<p>\nDa bismo izbjegli <code>split brain<\/code>, mo\u017eemo koristiti metodu <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/STONITH\">STONITH<\/a><\/noindex> ('Shoot The Other Node In The Head'), koja potpuno izolira ili isklju\u010duje problemati\u010dni \u010dvor. Postoje i drugi na\u010dini implementacije visoke dostupnosti klastera: kombinacija VIP-a i DNS-a, otkrivanje usluga i proxy usluge, sinkrona replikacija i drugi na\u010dini, koji imaju svoje nedostatke i prednosti.<\/p>\n<p>Govorio sam o na\u0161em pristupu izgradnji otpornog MySQL klastera. On je jednostavan za implementaciju i osigurava odgovaraju\u0107i nivo pouzdanosti u trenutnim okolnostima. Kako se sistem u cjelini i infrastruktura posebno razvijaju, ovaj pristup \u0107e se nesumnjivo razvijati.<br \/>\n<br \/>Izvor: <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.4 - 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\/hr\/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.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"hr_HR\" \/>\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\/hr\/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\udd47Orkestrator i VIP kao HA-re\u0161enje za MySQL klaster | ProHoster","description":"U Sitimobilu koristimo MySQL bazu podataka kao glavno skladi\u0161te trajnih podataka.","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hr_HR","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\/hr\/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\/hr\/wp-json\/wp\/v2\/posts\/82113","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=82113"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/82113\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media\/82114"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=82113"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=82113"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=82113"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}