{"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 il cluster MySQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>In Sitimobil utilizziamo il database MySQL come principale repository di dati permanenti. Abbiamo diversi cluster di database per vari servizi e obiettivi.<\/p>\n<p>La disponibilit\u00e0 continua 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 downtime del sistema. In questo articolo esaminer\u00f2 lo schema per garantire l'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 il 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 cosa rappresenta il nostro sistema di archiviazione dei dati.<\/p>\n<p>Utilizziamo uno schema di replica classico con un master disponibile in scrittura e molteplici repliche utilizzate solo in lettura. Il cluster pu\u00f2 contenere un master intermedio, un nodo che \u00e8 sia una replica che un master per altri. I client accedono alle repliche tramite HAProxy, che consente di distribuire uniformemente il carico e di scalare facilmente. L'uso di HAProxy \u00e8 motivato da ragioni storiche, e ora siamo in fase di migrazione verso ProxySQL.<\/p>\n<p>La replica avviene in modalit\u00e0 semisincrona basata su <code>GTID<\/code>. Ci\u00f2 significa che almeno una replica deve registrare la transazione nel log prima che venga considerata completata. Questa modalit\u00e0 di replica assicura un equilibrio ottimale tra prestazioni e integrit\u00e0 dei dati in caso di guasto del nodo principale. Fondamentalmente, 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 ricevute e, in caso di problemi, pu\u00f2 avviare la procedura di ripristino automatico. La responsabilit\u00e0 per la procedura stessa ricade sullo sviluppatore, poich\u00e9 pu\u00f2 essere implementata in vari modi: utilizzando VIP, DNS, servizi di discovery, o meccanismi personalizzati. <\/p>\n<p>Uno dei metodi semplici per ripristinare il master in caso di guasto \u00e8 l'uso di indirizzi VIP flottanti.<\/p>\n<p>Ecco cosa bisogna sapere su questa soluzione prima di procedere:<\/p>\n<ul>\n<li>Un VIP \u00e8 un indirizzo IP non legato a una specifica interfaccia di rete fisica. Quando un nodo si guasta o durante la manutenzione programmata, possiamo trasferire il VIP su una risorsa diversa 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 necessario avere accesso al server via SSH, oppure utilizzare strumenti specifici, come <code>keepalived<\/code>.\n<\/li>\n<\/ul>\n<p>\nEsaminiamo i potenziali problemi con il nostro master e vediamo come dovrebbe funzionare il meccanismo di ripristino automatico.<\/p>\n<h4>Connessione di rete persa con il master, oppure si \u00e8 verificato un problema hardware e il server non \u00e8 accessibile.<\/h4>\n<p><\/p>\n<ol>\n<li>L'orchestratore sta aggiornando la topologia del cluster, ogni replica segnala l'inaccessibilit\u00e0 del master. L'orchestratore avvia il processo di selezione di una replica adatta a diventare il nuovo master e inizia il ripristino.\n<\/li>\n<li>Tentiamo di rimuovere il VIP dal vecchio master, senza successo.\n<\/li>\n<li>La replica passa al ruolo di master. La topologia viene ristrutturata.\n<\/li>\n<li>Aggiungiamo una nuova interfaccia di rete con VIP. Poich\u00e9 non siamo riusciti a rimuovere il VIP, avviamo in background l'invio periodico di una richiesta. <b>gratuitous ARP<\/b>. Questo tipo di richiesta\/risposta consente di aggiornare la tabella di corrispondenza degli indirizzi IP e MAC sui switch collegati, notificando cos\u00ec il trasferimento del nostro VIP. Questo minimizza la probabilit\u00e0 di <code>split brain<\/code> al ritorno del vecchio master. \n<\/li>\n<li>T tutte le nuove connessioni vengono immediatamente reindirizzate al nuovo master. Le vecchie connessioni falliscono, vengono effettuati tentativi ripetuti al DB a livello di applicazione.\n<\/li>\n<\/ol>\n<p><\/p>\n<h4>Il server \u00e8 operativo 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, rilasciamo con successo il VIP dal vecchio master, lo trasferiamo sul nuovo e inviamo alcune richieste ARP. Il possibile ritorno del vecchio master non dovrebbe influire sul cluster ricostruito e sul funzionamento dell'applicazione.<\/p>\n<h4>Altri problemi<\/h4>\n<p>\nGuasti delle repliche o dei master intermedi <em>non porta<\/em> a azioni automatiche e richiede intervento manuale.<\/p>\n<p>L'interfaccia di rete virtuale viene sempre aggiunta temporaneamente, cio\u00e8 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 in scrittura e prova a impostare <code>sola lettura<\/code> sul vecchio master. Queste azioni mirano a ridurre la probabilit\u00e0 <code>split brain<\/code>.<\/p>\n<p>Nel processo di ripristino possono sorgere problemi, che dovrebbero essere notificati tramite l'interfaccia utente dell'orchestratore oltre ai normali strumenti di monitoraggio. Abbiamo ampliato il REST API, aggiungendo tale possibilit\u00e0 (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/pull\/1088\">PR<\/a><\/noindex> \u00e8 attualmente in fase di revisione).<\/p>\n<p>Lo schema generale della soluzione HA \u00e8 mostrato di seguito.<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator e VIP come soluzione HA per il cluster MySQL\" src=\"\/wp-content\/uploads\/2020\/05\/485dbbc8f2b1a7595f5fa4f36ad92f7e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Selezione 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 in base ai seguenti criteri:<\/p>\n<ul>\n<li>ritardo della replica rispetto al master;\n<\/li>\n<li>versione di MySQL del master e della replica;\n<\/li>\n<li>tipo di replicazione (RBR, SBR o mixed);\n<\/li>\n<li>posizione nello stesso o in diversi data center;\n<\/li>\n<li>presenza <code>GTID errante<\/code> \u2014 transazioni eseguite sulla replica e assenti nel master;\n<\/li>\n<li>sono anch'essi considerati regole di selezione utente.\n<\/li>\n<\/ul>\n<p>\nNon ogni replica \u00e8 un candidato ideale per diventare master. Ad esempio, una replica potrebbe essere utilizzata per il backup dei dati, oppure il server ha una configurazione hardware meno potente. 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 possono essere usate per configurare le proprie preferenze di selezione dei candidati, dalla pi\u00f9 preferita a quella ignorata.<\/p>\n<h1>Tempo di risposta e recupero<\/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 il quale la replica attende l'arrivo di nuovi dati o di un segnale heartbeat dal master, prima che la connessione venga considerata persa e venga eseguita una riconnessione. Minore \u00e8 il valore, pi\u00f9 rapidamente la replica potr\u00e0 rilevare che il collegamento con il master \u00e8 stato interrotto. 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 una riconnessione rapida e prevenir\u00e0 l'avvio del processo di ripristino del cluster. Il valore consigliato \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 intervallo in secondi dopo il quale il master invia un segnale 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>, la funzione master non verr\u00e0 applicata alla replica candidata fino a quando il thread SQL della replica non avr\u00e0 applicato tutte le transazioni non applicate dal Relay Log. Utilizziamo questa opzione per non perdere transazioni in condizioni di ritardo di tutte le repliche candidate.\n<\/li>\n<li><code>InstancePollSeconds<\/code> \u2014 frequenza di costruzione e aggiornamento della topologia.\n<\/li>\n<li><code>RecoveryPollSeconds<\/code> \u2014 frequenza di analisi della topologia. In caso di problemi, si avvia il ripristino della topologia. Questo<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\/blob\/548265494b3107ca2581d6ccee059e062a759b77\/go\/config\/config.go#L45\"> \u00e8 una costante<\/a><\/noindex>, pari a 1 secondo.\n<\/li>\n<\/ul>\n<p>\nOgni nodo del cluster viene interrogato dall'orchestratore una volta ogni <code>InstancePollSeconds<\/code> secondi. In caso di problemi, 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 si prende una decisione finale sul ripristino. Sperimentando con diversi parametri del DB e dell'orchestratore, siamo riusciti a ridurre il tempo di risposta e ripristino a 30 secondi.<\/p>\n<h1>Banchi di prova<\/h1>\n<p>\nAbbiamo avviato il test della configurazione HA sviluppando un <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ParshinPavel\/mysql-ha-sandbox\">banco di prova<\/a><\/noindex> e successivamente implementandolo negli ambienti di test e di produzione. Il banco di prova locale \u00e8 completamente automatizzato usando 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 emulazione del problema: abbattere immediatamente il master con <code>kill -9<\/code>, terminare delicatamente il processo e fermare il server (<code>docker-compose stop<\/code>), simulare problemi di rete usando <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 meno di 10 secondi;\n<\/li>\n<li>si avvier\u00e0 automaticamente la procedura di recupero: la configurazione di rete cambier\u00e0, il ruolo di master passer\u00e0 a una replica, la topologia verr\u00e0 ricostruita;\n<\/li>\n<li>il nuovo master sar\u00e0 disponibile per la scrittura, le repliche attive non andranno perse durante la ricostruzione;\n<\/li>\n<li>i dati inizieranno a essere scritti nel nuovo master e a essere replicati;\n<\/li>\n<li>il tempo totale di recupero sar\u00e0 di non pi\u00f9 di 30 secondi.\n<\/li>\n<\/ul>\n<p>\nCome sapete, il sistema pu\u00f2 comportarsi in modo diverso nell'ambiente di test e in produzione a causa della diversa configurazione dell'hardware e della rete, delle differenze nel carico sintetico e reale, ecc. Pertanto, periodicamente conduciamo esercitazioni in condizioni reali, verificando come si comporta il sistema in caso di perdita di connettivit\u00e0 di rete o degrado di singole parti. In futuro vogliamo costruire un'infrastruttura completamente identica per entrambi gli ambienti e automatizzare il suo test.<\/p>\n<h1>Conclusioni<\/h1>\n<p>\nLa funzionalit\u00e0 del nodo principale del sistema di archiviazione dati \u00e8 una delle priorit\u00e0 per il team SRE e per l'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 DB;\n<\/li>\n<li>risposta automatica e rapida agli incidenti relativi al master, riducendo cos\u00ec il tempo di inattivit\u00e0 del sistema.\n<\/li>\n<\/ul>\n<p>\nTuttavia, la soluzione presenta alcune limitazioni e svantaggi:<\/p>\n<ul>\n<li>la scalabilit\u00e0 dello schema HA su pi\u00f9 DC richieder\u00e0 una rete L2 unificata tra di essi;\n<\/li>\n<li>prima di assegnare il VIP al nuovo master, dobbiamo liberarlo dal 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 un altro metodo per chiamare procedure remote. Poich\u00e9 il server o il DB sta affrontando problemi che hanno avviato il processo di ripristino, non possiamo essere certi che la liberazione del VIP avr\u00e0 successo. Questo potrebbe portare alla creazione di due server con lo stesso indirizzo IP virtuale e al problema <code>split brain<\/code>.\n<\/li>\n<\/ul>\n<p>\nPer evitare <code>split brain<\/code>, \u00e8 possibile utilizzare il metodo <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/STONITH\">STONITH<\/a><\/noindex> (\u00abSpara L'altro Nodo Nella Testa\u00bb), che isola completamente o disabilita il nodo problematico. Esistono anche altre modalit\u00e0 per implementare l'alta disponibilit\u00e0 del cluster: una combinazione di VIP e DNS, rilevamento dei servizi e servizi proxy, replica sincrona e altri metodi, ciascuno con i propri vantaggi e svantaggi.<\/p>\n<p>Ho parlato del nostro approccio alla creazione di un cluster MySQL tollerante ai guasti. \u00c8 semplice da implementare e offre un livello accettabile di affidabilit\u00e0 nelle condizioni attuali. Man mano che l'intero sistema e l'infrastruttura in particolare si evolvono, questo approccio, senza dubbio, si svilupper\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 4.9.10 - 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. \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.\" \/>\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) 4.9.10\" \/>\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. \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.\" \/>\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 \u0421it\u0438\u043c\u043e\u0431\u0438\u043b utilizziamo MySQL come principale repository di dati permanenti. Abbiamo diversi cluster di database per vari servizi e scopi. La disponibilit\u00e0 continua del master \u00e8 un indicatore critico della funzionalit\u00e0 dell'intero sistema e delle sue parti. Il ripristino automatico del cluster in caso di guasto del master riduce notevolmente il tempo di reazione agli incidenti e il downtime del sistema.","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. \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.","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"},"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}]}}