{"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\/it\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql","title":{"rendered":"Orchestrator e VIP come soluzione HA per un cluster MySQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>In SitiMobil utilizziamo il database MySQL come principale archivio di dati permanenti. Abbiamo diversi cluster di database per vari servizi e scopi.<\/p>\n<p>La disponibilit\u00e0 costante del master \u00e8 un indicatore critico della funzionalit\u00e0 dell'intero sistema e delle sue singole parti. Il ripristino automatico del cluster in caso di guasto del master riduce notevolmente il tempo di risposta agli incidenti e il tempo di inattivit\u00e0 del sistema. In questo articolo esaminer\u00f2 lo schema di alta disponibilit\u00e0 (HA) del cluster MySQL basato su <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\">MySQL Orchestrator<\/a><\/noindex> e indirizzi IP virtuali (VIP).<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator e VIP come soluzione HA per un cluster 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>Soluzione HA basata su VIP<\/h1>\n<p>\nInizier\u00f2 con una breve descrizione di come \u00e8 strutturato il nostro sistema di archiviazione dei dati.<\/p>\n<p>Utilizziamo uno schema di replica classico con un master disponibile per la scrittura e molteplici repliche che vengono utilizzate solo per lettura. Il cluster pu\u00f2 contenere un master intermedio, un nodo che \u00e8 sia una replica sia un master per altri. I clienti accedono alle repliche tramite HAProxy, il che consente di distribuire equamente il carico e di scalare facilmente. L'uso di HAProxy \u00e8 dovuto a motivi storici, e attualmente siamo in fase di migrazione a ProxySQL.<\/p>\n<p>La replica avviene in modalit\u00e0 semi-sincrona sulla base di <code>GTID<\/code>. Questo significa che almeno una replica deve registrare una transazione nel log prima che sia considerata riuscita. Questa modalit\u00e0 di replica garantisce un equilibrio ottimale tra prestazioni e integrit\u00e0 dei dati in caso di guasto del nodo principale. In generale, tutte le modifiche vengono trasferite dal master alle repliche tramite <code>Row Based Replication (RBR)<\/code>, ma alcuni nodi possono avere <code>mixed binlog format<\/code>.<\/p>\n<p>L'orchestratore aggiorna periodicamente lo stato della topologia del cluster, analizza le informazioni raccolte e, in caso di problemi, pu\u00f2 avviare la procedura di ripristino automatico. La responsabilit\u00e0 della procedura ricade sullo sviluppatore, poich\u00e9 pu\u00f2 essere implementata in vari modi: utilizzando VIP, DNS, servizi di discovery delle risorse (service discovery) o meccanismi custom. <\/p>\n<p>Uno dei modi semplici per ripristinare il master in caso di guasto \u00e8 l'utilizzo di indirizzi VIP galleggianti.<\/p>\n<p>Cosa \u00e8 necessario sapere su questa soluzione prima di procedere:<\/p>\n<ul>\n<li>Il VIP \u00e8 un indirizzo IP che non \u00e8 legato a un'interfaccia di rete fisica specifica. In caso di guasto di un nodo o durante lavori programmati, possiamo trasferire il VIP su un'altra risorsa con un tempo di inattivit\u00e0 minimo.\n<\/li>\n<li>Il rilascio e l'assegnazione di un indirizzo IP virtuale sono operazioni economiche e rapide.\n<\/li>\n<li>Per lavorare con il VIP \u00e8 necessaria l'accesso al server tramite SSH, oppure l'uso di utilit\u00e0 speciali, per esempio, <code>keepalived<\/code>.\n<\/li>\n<\/ul>\n<p>\nEsaminiamo i possibili problemi con il nostro master e immaginiamo come dovrebbe funzionare il meccanismo di ripristino automatico.<\/p>\n<h4>\u00c8 stata persa la connettivit\u00e0 di rete con il master, oppure si \u00e8 verificato un problema a livello di \"hardware\" e il server \u00e8 inaccessibile.<\/h4>\n<p><\/p>\n<ol>\n<li>L'orchestratore aggiorna la topologia del cluster, ogni replica segnala l'indisponibilit\u00e0 del master. L'orchestratore avvia il processo di selezione di una replica adatta al ruolo di nuovo master e inizia il ripristino.\n<\/li>\n<li>Stiamo tentando di rimuovere il VIP dal vecchio master \u2014 senza successo.\n<\/li>\n<li>La replica si sta spostando nel ruolo di master. La topologia viene ricostruita.\n<\/li>\n<li>Aggiungiamo una nuova interfaccia di rete con VIP. Poich\u00e9 non siamo riusciti a rimuovere il VIP, in background avviamo un'invio periodica di richieste <b>gratuitous ARP<\/b>. Questo tipo di richiesta\/risposta consente di aggiornare sui switch connessi la tabella di corrispondenza degli indirizzi IP e MAC, informando cos\u00ec del trasferimento del nostro VIP. Ci\u00f2 minimizza la probabilit\u00e0 di <code>split brain<\/code> quando il vecchio master ritorna. \n<\/li>\n<li>Tutte le nuove connessioni vengono immediatamente reindirizzate al nuovo master. Le vecchie connessioni terminano con un errore, vengono effettuate nuove chiamate al database a livello di applicazione.\n<\/li>\n<\/ol>\n<p><\/p>\n<h4>Il server funziona normalmente, si \u00e8 verificato un guasto a livello di DBMS.<\/h4>\n<p>\nL'algoritmo \u00e8 simile al caso precedente: aggiornamento della topologia e avvio del processo di ripristino. Poich\u00e9 il server \u00e8 disponibile, riusciamo a liberare con successo il VIP dal vecchio master, trasferirlo al nuovo e inviare alcune richieste ARP. Un eventuale ritorno del vecchio master non dovrebbe influenzare il cluster ricostruito e il funzionamento dell'applicazione.<\/p>\n<h4>Altri problemi<\/h4>\n<p>\nGuasti delle repliche o dei master intermedi <em>non portano<\/em> a azioni automatiche e richiedono un intervento manuale.<\/p>\n<p>L'interfaccia di rete virtuale viene sempre aggiunta temporaneamente, ovvero dopo il riavvio del server, il VIP non viene automaticamente assegnato. Ogni istanza del DB viene avviata per impostazione predefinita in modalit\u00e0 di sola lettura, l'orchestratore commuta automaticamente il nuovo master su scrittura e cerca di stabilire <code>sola lettura<\/code> sul vecchio master. Queste azioni sono mirate a ridurre la probabilit\u00e0 <code>split brain<\/code>.<\/p>\n<p>Durante il processo di ripristino potrebbero sorgere problemi, dei quali \u00e8 anche opportuno avvisare tramite l'interfaccia utente dell'orchestratore oltre ai normali strumenti di monitoraggio. Abbiamo ampliato l'API REST, aggiungendo questa possibilit\u00e0 (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/pull\/1088\">PR<\/a><\/noindex> \u00e8 attualmente in revisione).<\/p>\n<p>Il diagramma generale della soluzione HA \u00e8 riportato di seguito.<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator e VIP come soluzione HA per un cluster MySQL\" src=\"\/wp-content\/uploads\/2020\/05\/485dbbc8f2b1a7595f5fa4f36ad92f7e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Scelta del nuovo master<\/h1>\n<p>\nL'orchestratore \u00e8 abbastanza intelligente e cerca di selezionare <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/blob\/5126b849ae4f655e1cbe0fbddfa0d7299674f712\/go\/inst\/instance_utils.go#L112\">la replica pi\u00f9 adatta<\/a><\/noindex> come nuovo master secondo i seguenti criteri:<\/p>\n<ul>\n<li>ritardo della replica rispetto al master;\n<\/li>\n<li>versione MySQL del master e della replica;\n<\/li>\n<li>tipo di replicazione (RBR, SBR o mista);\n<\/li>\n<li>posizione in uno o pi\u00f9 data center;\n<\/li>\n<li>presenza di <code>GTID erranti<\/code> \u2014 transazioni che sono state eseguite sulla replica e che mancano sul master;\n<\/li>\n<li>sono considerati anche le regole di selezione personalizzate.\n<\/li>\n<\/ul>\n<p>\nNon ogni replica \u00e8 un candidato ideale per il ruolo di master. Ad esempio, la replica pu\u00f2 essere utilizzata per il backup dei dati, oppure il server pu\u00f2 avere una configurazione hardware pi\u00f9 debole. L'orchestratore <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/blob\/master\/docs\/topology-recovery.md#adding-promotion-rules\">supporta<\/a><\/noindex> regole manuali, che consentono di configurare le proprie preferenze di selezione dei candidati, da quelle pi\u00f9 preferite a quelle ignorate.<\/p>\n<h1>Tempo di risposta e ripristino<\/h1>\n<p>\nIn caso di incidente, \u00e8 importante ridurre al minimo il tempo di inattivit\u00e0 del sistema, quindi consideriamo i parametri MySQL che influenzano la costruzione e l'aggiornamento della topologia del cluster da parte dell'orchestratore:<\/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 il numero di secondi durante i quali la replica attende l'arrivo di nuovi dati o un segnale heartbeat dal master, prima che la connessione venga considerata persa e venga eseguita la riconnessione. Pi\u00f9 basso \u00e8 il valore, pi\u00f9 rapidamente la replica sar\u00e0 in grado di determinare che la connessione con il master \u00e8 stata interrotta. Impostiamo questo valore a 5 secondi.\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 il numero di secondi tra i tentativi di riconnessione. In caso di problemi di rete, un valore basso di questo parametro consentir\u00e0 di riconnettersi rapidamente e prevenire l'avvio del processo di recupero del cluster. Il valore raccomandato \u00e8 di 1 secondo.\n<\/li>\n<li><code>MASTER_RETRY_COUNT<\/code> \u2014 il numero massimo di tentativi di riconnessione. \n<\/li>\n<li><code>MASTER_HEARTBEAT_PERIOD<\/code> \u2014 l'intervallo in secondi dopo il quale il master invia un segnale di heartbeat. Di default \u00e8 pari alla met\u00e0 del valore <code>slave_net_timeout<\/code>.\n<\/li>\n<\/ul>\n<p>\nParametri dell'orchestratore:<\/p>\n<ul>\n<li><code>DelayMasterPromotionIfSQLThreadNotUpToDate<\/code> \u2014 se \u00e8 uguale a <code>true<\/code>, il ruolo di master non sar\u00e0 applicato al replica candidato fino a quando il thread SQL del replica non avr\u00e0 eseguito tutte le transazioni non applicate dal Relay Log. Utilizziamo questa opzione per non perdere transazioni in caso di ritardo di tutti i replica candidati.\n<\/li>\n<li><code>InstancePollSeconds<\/code> \u2014 la frequenza con cui viene costruita e aggiornata la topologia.\n<\/li>\n<li><code>RecoveryPollSeconds<\/code> \u2014 la frequenza con cui viene analizzata la topologia. In caso venga rilevato un problema, viene avviato il recupero della topologia. Questa \u00e8<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\/blob\/548265494b3107ca2581d6ccee059e062a759b77\/go\/config\/config.go#L45\"> una costante<\/a><\/noindex>, pari a 1 secondo.\n<\/li>\n<\/ul>\n<p>\nOgni nodo del cluster viene interrogato dall'orchestratore una volta in <code>InstancePollSeconds<\/code> secondi. In caso di problemi rilevati, lo stato del cluster viene forzatamente<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\/blob\/548265494b3107ca2581d6ccee059e062a759b77\/go\/logic\/topology_recovery.go#L1409\"> aggiornato<\/a><\/noindex>, e poi viene presa una decisione finale sull'esecuzione del recupero. Sperimentando con vari parametri del database e dell'orchestratore, siamo riusciti a ridurre il tempo di reazione e recupero a 30 secondi.<\/p>\n<h1>Banchina di test<\/h1>\n<p>\nAbbiamo iniziato a testare lo schema HA sviluppando un <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ParshinPavel\/mysql-ha-sandbox\">banco di prova locale<\/a><\/noindex> e successivamente implementandolo in ambienti di test e produzione. Il banco di prova locale \u00e8 completamente automatizzato sulla base di Docker e consente di sperimentare con la configurazione dell'orchestratore e della rete, scalando il cluster da 2-3 server a diverse decine e conducendo esercitazioni in un ambiente sicuro. <\/p>\n<p>Durante le esercitazioni scegliamo uno dei metodi di simulazione del problema: interrompere immediatamente il master utilizzando <code>kill -9<\/code>, chiudere delicatamente il processo e fermare il server (<code>docker-compose stop<\/code>), simulare problemi di rete utilizzando <code>iptables -j REJECT<\/code> o <code>iptables -j DROP<\/code>. Ci aspettiamo i seguenti risultati:<\/p>\n<ul>\n<li>l'orchestratore rilever\u00e0 i problemi con il master e aggiorner\u00e0 la topologia in non pi\u00f9 di 10 secondi;\n<\/li>\n<li>la procedura di recupero verr\u00e0 avviata automaticamente: cambier\u00e0 la configurazione di rete, il ruolo di master passer\u00e0 al replica, la topologia verr\u00e0 ricostruita;\n<\/li>\n<li>il nuovo master sar\u00e0 disponibile per la registrazione, le repliche live non andranno perdute durante il processo di ricostruzione;\n<\/li>\n<li>i dati inizieranno a essere registrati nel nuovo master e a essere replicati;\n<\/li>\n<li>il tempo totale di ripristino non superer\u00e0 i 30 secondi.\n<\/li>\n<\/ul>\n<p>\nCome sapete, il sistema pu\u00f2 comportarsi in modo diverso negli ambienti di test e di produzione a causa di diverse configurazioni dell'hardware e della rete, delle differenze nei carichi sintetici e reali, e cos\u00ec via. Pertanto, periodicamente conduciamo esercitazioni in condizioni reali per verificare come si comporta il sistema in caso di perdita di connettivit\u00e0 di rete o di degrado di singole parti. In futuro, vogliamo costruire un'infrastruttura completamente identica per entrambi gli ambienti e automatizzarne il testing.<\/p>\n<h1>Conclusioni<\/h1>\n<p>\nIl funzionamento del nodo principale del sistema di archiviazione dei dati \u00e8 uno degli obiettivi principali del team SRE e dell'operativit\u00e0. L'implementazione di un orchestratore e di una soluzione HA basata su VIP ha portato ai seguenti risultati:<\/p>\n<ul>\n<li>rilevamento affidabile dei problemi con la topologia del cluster del DB;\n<\/li>\n<li>risposta automatica e rapida agli incidenti legati al master, che riduce i tempi di inattivit\u00e0 del sistema.\n<\/li>\n<\/ul>\n<p>\nTuttavia, la soluzione ha le sue limitazioni e svantaggi:<\/p>\n<ul>\n<li>la scalabilit\u00e0 dello schema HA su pi\u00f9 DC richieder\u00e0 una rete L2 unica tra di loro;\n<\/li>\n<li>prima di assegnare il VIP al nuovo master, dobbiamo liberarlo da quello vecchio. Il processo \u00e8 sequenziale, il che aumenta il tempo di ripristino;\n<\/li>\n<li>liberare il VIP richiede accesso SSH al server, o qualsiasi altro metodo per chiamare procedure remote. Poich\u00e9 il server o il DB stanno affrontando problemi che causano il processo di ripristino, non possiamo essere certi che la rimozione del VIP avr\u00e0 successo. Questo potrebbe portare alla creazione di due server con lo stesso indirizzo IP virtuale e alla problematica di <code>split brain<\/code>.\n<\/li>\n<\/ul>\n<p>\nPer evitare <code>split brain<\/code>, si pu\u00f2 utilizzare il metodo <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/STONITH\">STONITH<\/a><\/noindex> (\u00abShoot The Other Node In The Head\u00bb), che isola o disattiva completamente il nodo problematico. Ci sono anche altri metodi per implementare l'alta disponibilit\u00e0 del cluster: combinazione di VIP e DNS, rilevamento dei servizi e proxy, replica sincrona e altri metodi, ognuno dei quali ha i propri svantaggi e vantaggi.<\/p>\n<p>Ho parlato del nostro approccio alla creazione di un cluster MySQL ad alta disponibilit\u00e0. \u00c8 semplice da implementare e garantisce un livello accettabile di affidabilit\u00e0 nelle attuali condizioni. Con lo sviluppo dell'intero sistema e dell'infrastruttura, questo approccio, senza dubbio, evolver\u00e0.<br \/>\n<br \/>Fonte: <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\/it\/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=\"it_IT\" \/>\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\/it\/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 e VIP come soluzione HA per il cluster MySQL | ProHoster","description":"In Sitimobil utilizziamo il database MySQL come principale deposito di dati permanenti.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/82113","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=82113"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/82113\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/82114"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=82113"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=82113"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=82113"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}