{"id":82116,"date":"2020-05-19T13:42:54","date_gmt":"2020-05-19T11:42:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/orchestrator-dlya-mysql-pochemu-bez-nego-nelzya-stroit-otkazoustojchivyj-proekt"},"modified":"2020-05-19T13:42:54","modified_gmt":"2020-05-19T11:42:54","slug":"orchestrator-dlya-mysql-pochemu-bez-nego-nelzya-stroit-otkazoustojchivyj-proekt","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/orchestrator-dlya-mysql-pochemu-bez-nego-nelzya-stroit-otkazoustojchivyj-proekt","title":{"rendered":"Orchestrator per MySQL: perch\u00e9 non si pu\u00f2 costruire un progetto ad alta disponibilit\u00e0 senza di lui","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Qualsiasi progetto di grandi dimensioni inizia con un paio di server. Inizialmente c'era un server DB, poi sono stati aggiunti dei repliche per scalare la lettura. E qui \u2014 stop! C\u2019\u00e8 un solo master e molte repliche; se una delle repliche si guasta va bene, ma se si guasta il master \u2014 \u00e8 un problema: downtime, gli amministratori si affannano a ripristinare il server. Cosa fare? Riservare il master. Il mio collega Pavel ne ha gi\u00e0 parlato. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/citymobil\/blog\/491044\/\">articolo<\/a><\/noindex>, non la ripeter\u00f2. Invece, vi dir\u00f2 perch\u00e9 avete assolutamente bisogno di Orchestrator per MySQL!<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nIniziamo con la domanda principale: \u00abCome faremo a switchare il codice su una nuova macchina quando il master si guasta?\u00bb.<\/p>\n<ul>\n<li>Mi piace di pi\u00f9 lo schema con VIP (Virtual IP), di cui parleremo di seguito. \u00c8 il pi\u00f9 semplice e ovvio, anche se presenta un chiaro limite: il master che intendiamo riservare deve trovarsi nello stesso segmento L2 della nuova macchina, quindi possiamo dimenticare il secondo centro dati. D\u2019altronde, se seguiamo la regola che un grande L2 \u00e8 un male, perch\u00e9 l'L2 \u00e8 solo su rack, mentre tra i rack c\u2019\u00e8 L3, e questo schema ha ancor pi\u00f9 limitazioni.<\/li>\n<li>Possiamo inserire il nome DNS nel codice e risolverlo tramite \/etc\/hosts. In realt\u00e0 non ci sar\u00e0 una risoluzione. Il vantaggio di questo schema \u00e8 che non ha il limite caratteristico del primo metodo, quindi possiamo anche organizzare cross-Datacenter. Ma allora sorge la domanda ovvia: quanto velocemente porteremo la modifica in \/etc\/hosts tramite Puppet-Ansible.<\/li>\n<li>Possiamo modificare un po' il secondo metodo: su tutti i server web possiamo installare un DNS caching, attraverso il quale il codice acceder\u00e0 al database master. Possiamo impostare un TTL di 60 per questa voce nel DNS. Sembra che, se implementato correttamente, sia un buon metodo.<\/li>\n<li>Schema con service discovery, che prevede l'uso di Consul e etcd.<\/li>\n<li>Un'opzione interessante con <noindex><a rel=\"nofollow\" href=\"https:\/\/proxysql.com\/\">ProxySQL<\/a><\/noindex>. Bisogna far passare tutto il traffico MySQL attraverso ProxySQL, che \u00e8 in grado di determinare chi \u00e8 attualmente il master. A proposito, su una delle modalit\u00e0 di utilizzo di questo prodotto \u00e8 possibile leggere nel mio <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/citymobil\/blog\/501730\/\">abbiamo chiarito il corretto completamento dei programmi che utilizzano il mediastreamer.<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\nL'autore di Orchestrator, lavorando su Github, ha inizialmente implementato il primo schema con VIP, per poi cambiare a uno schema con consul.<\/p>\n<p>Schema tipico dell'infrastruttura:<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator per MySQL: perch\u00e9 non si pu\u00f2 costruire un progetto ad alta disponibilit\u00e0 senza di lui\" src=\"\/wp-content\/uploads\/2020\/05\/b08220e7aa6336229cbbfedd78afdcc3.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nDescriver\u00f2 subito le situazioni ovvie che devono essere considerate:<\/p>\n<ul>\n<li>L'indirizzo VIP non dovrebbe essere configurato in nessun file di configurazione su nessuno dei server. Immaginiamo la situazione: il master si \u00e8 riavviato, e mentre si avvia, Orchestrator \u00e8 passato alla modalit\u00e0 failover e ha fatto diventare master una delle repliche; poi \u00e8 tornato in funzione il vecchio master, e ora il VIP \u00e8 su due macchine. Questo \u00e8 un problema.<\/li>\n<li>Per l'orchestratore sar\u00e0 necessario scrivere uno script per interagire con il vecchio master e il nuovo master. Sul vecchio \u00e8 necessario eseguire ifdown, mentre sul nuovo master \u2014 ifup vip. Sarebbe utile anche inserire in questo script che nel caso di failover la porta dello switch del vecchio master venga semplicemente spenta, per evitare qualsiasi split-brain.<\/li>\n<li>Dopo che l'Orchestratore ha chiamato il vostro script, per prima cosa per rimuovere il VIP e\/o spegnere la porta dello switch, e poi ha chiamato il script per alzare il VIP sul nuovo master, non dimenticate di usare il comando arping per avvisare tutti che il nuovo VIP \u00e8 ora qui.<\/li>\n<li>Tutti gli slave devono avere read_only=1 e non appena promuovete uno slave a master, deve diventare read_only=0.<\/li>\n<li>Non dimenticate che qualsiasi slave che abbiamo scelto pu\u00f2 diventare master (l'Orchestratore ha un intero meccanismo di preferenza per decidere quale slave considerare come candidato a nuovo master in prima istanza, quale in seconda, e quale slave non deve mai essere scelto come master). Se uno slave diventa master, manterr\u00e0 il carico dello slave e aggiunger\u00e0 il carico del master, questo deve essere tenuto in considerazione.<\/li>\n<\/ul>\n<p>\nPerch\u00e9 avete assolutamente bisogno dell'Orchestratore se non lo avete?<\/p>\n<ul>\n<li>L'Orchestratore ha un'interfaccia grafica molto comoda che mostra tutta la topologia (vedi screenshot qui sotto).<\/li>\n<li>L'Orchestratore pu\u00f2 monitorare quali slave sono indietro e dove la replicazione si \u00e8 interrotta del tutto (abbiamo script collegati all'Orchestratore per inviare SMS).<\/li>\n<li>L'Orchestratore ti dice su quali slave c'\u00e8 un errore GTID errant.<\/li>\n<\/ul>\n<p>\nInterfaccia dell'Orchestratore:<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator per MySQL: perch\u00e9 non si pu\u00f2 costruire un progetto ad alta disponibilit\u00e0 senza di lui\" src=\"\/wp-content\/uploads\/2020\/05\/5129a85ad1c0a5db8e3ecf501cff0d0d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nCos'\u00e8 GTID errant?<\/p>\n<p>Ci sono due requisiti principali per il funzionamento dell'Orchestratore:<\/p>\n<ul>\n<li>\u00c8 necessario che su tutte le macchine del cluster MySQL sia abilitato il pseudo GTID, noi abbiamo attivato GTID.<\/li>\n<li>\u00c8 necessario che ci sia un solo tipo di binlog ovunque, si pu\u00f2 usare statement. Avevamo una configurazione in cui sul master e sulla maggior parte degli slave era Row, mentre su due storicamente era rimasto il modo Mixed. Di conseguenza, questi slave l'Orchestratore non ha proprio voluto collegarli al nuovo master.<\/li>\n<\/ul>\n<p>\nRicorda che la cosa pi\u00f9 importante in un production-slave \u00e8 la sua coerenza con il master! Se sia sul master che sullo slave \u00e8 abilitato il Global Transaction ID (GTID), allora attraverso la funzione gtid_subset puoi scoprire se davvero su queste macchine sono state eseguite le stesse query per modificare i dati. Puoi approfondire questo argomento. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.percona.com\/blog\/2014\/05\/19\/errant-transactions-major-hurdle-for-gtid-based-failover-in-mysql-5-6\/\">qui<\/a><\/noindex>.<\/p>\n<p>In questo modo, Orchestrator ti mostra tramite l'errore GTID errante che ci sono transazioni sullo slave che non sono presenti sul master. Perch\u00e9 succede questo?<\/p>\n<ul>\n<li>Lo slave non ha read_only=1 abilitato, qualcuno si \u00e8 connesso ed ha eseguito una richiesta di modifica dei dati.<\/li>\n<li>Lo slave non ha super_read_only=1 abilitato, quindi un admin, confondendo il server, \u00e8 entrato e ha eseguito una richiesta l\u00ec.<\/li>\n<li>Se hai considerato entrambi i punti precedenti, c'\u00e8 un ulteriore trucco: in MySQL la richiesta di flush dei binlog finisce anch'essa nel binlog, quindi al primo flush sul master e su tutti gli slave apparir\u00e0 GTID errante. Come evitarlo? Nella versione perona-5.7.25-28 \u00e8 stata introdotta l'impostazione binlog_skip_flush_commands=1, che impedisce la scrittura di flush nei binlog. Sul sito mysql.com c'\u00e8 documentata <noindex><a rel=\"nofollow\" href=\"https:\/\/bugs.mysql.com\/bug.php?id=88720\">bug<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\nRiassumendo quanto detto. Se al momento non desideri utilizzare Orchestrator in modalit\u00e0 failover, impostalo in modalit\u00e0 monitoraggio. In questo modo avrai sempre sotto gli occhi una mappa delle interazioni tra le macchine MySQL e informazioni chiare sul tipo di replicazione su ciascuna macchina, se gli slave sono in ritardo e, soprattutto, quanto sono coerenti con il master!<\/p>\n<p>Una domanda ovvia: \u00abCome dovrebbe funzionare Orchestrator?\u00bb. Dovrebbe selezionare un nuovo master tra gli attuali slave e poi ricollegare tutti gli slave a esso (questo \u00e8 esattamente il motivo per cui \u00e8 necessario il GTID; se si utilizzasse il vecchio meccanismo con binlog_name e binlog_pos, il passaggio dello slave dall'attuale master al nuovo sarebbe semplicemente impossibile!). Prima che avessimo Orchestrator, una volta mi \u00e8 toccato fare tutto questo manualmente. Il vecchio master si bloccava a causa del controller Adaptec difettoso, e aveva circa 10 slave. Dovevo trasferire il VIP dal master a uno degli slave e ricollegare tutti gli altri slave a esse. Quante console ho dovuto aprire, quante comandi simultanei ho dovuto inserire\u2026 Ho dovuto aspettare fino alle 3 del mattino, ridurre il carico su tutti gli slave, tranne due, rendere la prima macchina delle due il master, connettere immediatamente la seconda macchina, quindi collegare tutti gli altri slave al nuovo master e ripristinare il carico. Insomma, un incubo\u2026<\/p>\n<p>Come funziona Orchestrator quando passa in modalit\u00e0 failover? \u00c8 pi\u00f9 facile mostrarlo con un esempio di situazione in cui vogliamo rendere master una macchina pi\u00f9 potente e moderna di quella attuale. <\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator per MySQL: perch\u00e9 non si pu\u00f2 costruire un progetto ad alta disponibilit\u00e0 senza di lui\" src=\"\/wp-content\/uploads\/2020\/05\/d2afe9c74b33765e55641b34def3145e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nL'immagine rappresenta la met\u00e0 del processo. Cosa era gi\u00e0 stato fatto fino a questo momento? Abbiamo detto che vogliamo rendere un qualche slave il nuovo master, Orchestrator ha iniziato semplicemente a riconnettere tutti gli altri slave a esso, mentre il nuovo master svolge il ruolo di macchina di transito. Con questo schema non si verificano errori, tutti gli slave funzionano, Orchestrator rimuove il VIP dal vecchio master, lo trasferisce al nuovo, imposta read_only=0 e dimentica il vecchio master. Tutto qui! Il downtime del nostro servizio \u00e8 il tempo di trasferimento del VIP, che \u00e8 di 2-3 secondi.<\/p>\n<p>Tutto qui per oggi, grazie a tutti. Presto ci sar\u00e0 un secondo articolo su Orchestrator. In un famoso film sovietico \"Garage\", un personaggio ha detto: \"Non andrei con lui in missione di esplorazione!\" Ecco, Orchestrator, io con te andrei in missione di esplorazione!<br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/citymobil\/blog\/501994\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041b\u044e\u0431\u043e\u0439 \u043a\u0440\u0443\u043f\u043d\u044b\u0439 \u043f\u0440\u043e\u0435\u043a\u0442 \u043d\u0430\u0447\u0438\u043d\u0430\u043b\u0441\u044f \u0441 \u043f\u0430\u0440\u044b \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432. C\u043d\u0430\u0447\u0430\u043b\u0430 \u0431\u044b\u043b \u043e\u0434\u0438\u043d DB-\u0441\u0435\u0440\u0432\u0435\u0440, \u043f\u043e\u0442\u043e\u043c \u043a \u043d\u0435\u043c\u0443 \u0434\u043e\u0431\u0430\u0432\u0438\u043b\u0438\u0441\u044c \u0441\u043b\u0435\u0439\u0432\u044b, \u0447\u0442\u043e\u0431\u044b \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0447\u0442\u0435\u043d\u0438\u0435. \u0418 \u0442\u0443\u0442 \u2014 \u0441\u0442\u043e\u043f! \u041c\u0430\u0441\u0442\u0435\u0440 \u043e\u0434\u0438\u043d, \u0430 \u0441\u043b\u0435\u0439\u0432\u043e\u0432 \u043c\u043d\u043e\u0433\u043e; \u0435\u0441\u043b\u0438 \u0443\u0439\u0434\u0435\u0442 \u043e\u0434\u0438\u043d \u0438\u0437 \u0441\u043b\u0435\u0439\u0432\u043e\u0432, \u0442\u043e \u0432\u0441\u0451 \u0431\u0443\u0434\u0435\u0442 \u0445\u043e\u0440\u043e\u0448\u043e, \u0430 \u0435\u0441\u043b\u0438 \u0443\u0439\u0434\u0435\u0442 \u043c\u0430\u0441\u0442\u0435\u0440 \u2014 \u0431\u0443\u0434\u0435\u0442 \u043f\u043b\u043e\u0445\u043e: \u0434\u0430\u0443\u043d\u0442\u0430\u0439\u043c, \u0430\u0434\u043c\u0438\u043d\u044b \u0432 \u043c\u044b\u043b\u0435 \u043f\u043e\u0434\u043d\u0438\u043c\u0430\u044e\u0442 \u0441\u0435\u0440\u0432\u0435\u0440. \u0427\u0442\u043e \u0434\u0435\u043b\u0430\u0442\u044c? \u0420\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u043c\u0430\u0441\u0442\u0435\u0440. \u041c\u043e\u0439 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":82117,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-82116","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=\"\u041b\u044e\u0431\u043e\u0439 \u043a\u0440\u0443\u043f\u043d\u044b\u0439 \u043f\u0440\u043e\u0435\u043a\u0442 \u043d\u0430\u0447\u0438\u043d\u0430\u043b\u0441\u044f \u0441 \u043f\u0430\u0440\u044b \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432. C\u043d\u0430\u0447\u0430\u043b\u0430 \u0431\u044b\u043b \u043e\u0434\u0438\u043d DB-\u0441\u0435\u0440\u0432\u0435\u0440, \u043f\u043e\u0442\u043e\u043c \u043a \u043d\u0435\u043c\u0443 \u0434\u043e\u0431\u0430\u0432\u0438\u043b\u0438\u0441\u044c \u0441\u043b\u0435\u0439\u0432\u044b, \u0447\u0442\u043e\u0431\u044b \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0447\u0442\u0435\u043d\u0438\u0435. \u0418 \u0442\u0443\u0442 \u2014 \u0441\u0442\u043e\u043f!\" \/>\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-dlya-mysql-pochemu-bez-nego-nelzya-stroit-otkazoustojchivyj-proekt\" \/>\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 \u0434\u043b\u044f MySQL: \u043f\u043e\u0447\u0435\u043c\u0443 \u0431\u0435\u0437 \u043d\u0435\u0433\u043e \u043d\u0435\u043b\u044c\u0437\u044f \u0441\u0442\u0440\u043e\u0438\u0442\u044c \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u044b\u0439 \u043f\u0440\u043e\u0435\u043a\u0442 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041b\u044e\u0431\u043e\u0439 \u043a\u0440\u0443\u043f\u043d\u044b\u0439 \u043f\u0440\u043e\u0435\u043a\u0442 \u043d\u0430\u0447\u0438\u043d\u0430\u043b\u0441\u044f \u0441 \u043f\u0430\u0440\u044b \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432. C\u043d\u0430\u0447\u0430\u043b\u0430 \u0431\u044b\u043b \u043e\u0434\u0438\u043d DB-\u0441\u0435\u0440\u0432\u0435\u0440, \u043f\u043e\u0442\u043e\u043c \u043a \u043d\u0435\u043c\u0443 \u0434\u043e\u0431\u0430\u0432\u0438\u043b\u0438\u0441\u044c \u0441\u043b\u0435\u0439\u0432\u044b, \u0447\u0442\u043e\u0431\u044b \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0447\u0442\u0435\u043d\u0438\u0435. \u0418 \u0442\u0443\u0442 \u2014 \u0441\u0442\u043e\u043f!\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/orchestrator-dlya-mysql-pochemu-bez-nego-nelzya-stroit-otkazoustojchivyj-proekt\" \/>\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:54+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-05-19T11:42:54+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\udd47Orchestratore per MySQL: perch\u00e9 non si pu\u00f2 costruire un progetto a prova di guasto senza di esso | ProHoster","description":"Qualsiasi grande progetto \u00e8 iniziato con un paio di server. Inizialmente c'era un server DB, poi si sono aggiunti degli slave per scalare la lettura. E qui \u2014 stop!","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/orchestrator-dlya-mysql-pochemu-bez-nego-nelzya-stroit-otkazoustojchivyj-proekt","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 \u0434\u043b\u044f MySQL: \u043f\u043e\u0447\u0435\u043c\u0443 \u0431\u0435\u0437 \u043d\u0435\u0433\u043e \u043d\u0435\u043b\u044c\u0437\u044f \u0441\u0442\u0440\u043e\u0438\u0442\u044c \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u044b\u0439 \u043f\u0440\u043e\u0435\u043a\u0442 | ProHoster","og:description":"\u041b\u044e\u0431\u043e\u0439 \u043a\u0440\u0443\u043f\u043d\u044b\u0439 \u043f\u0440\u043e\u0435\u043a\u0442 \u043d\u0430\u0447\u0438\u043d\u0430\u043b\u0441\u044f \u0441 \u043f\u0430\u0440\u044b \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432. C\u043d\u0430\u0447\u0430\u043b\u0430 \u0431\u044b\u043b \u043e\u0434\u0438\u043d DB-\u0441\u0435\u0440\u0432\u0435\u0440, \u043f\u043e\u0442\u043e\u043c \u043a \u043d\u0435\u043c\u0443 \u0434\u043e\u0431\u0430\u0432\u0438\u043b\u0438\u0441\u044c \u0441\u043b\u0435\u0439\u0432\u044b, \u0447\u0442\u043e\u0431\u044b \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0447\u0442\u0435\u043d\u0438\u0435. \u0418 \u0442\u0443\u0442 \u2014 \u0441\u0442\u043e\u043f!","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/orchestrator-dlya-mysql-pochemu-bez-nego-nelzya-stroit-otkazoustojchivyj-proekt","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:54+00:00","article:modified_time":"2020-05-19T11:42:54+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"82116","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:22","updated":"2022-10-07 20:28:08","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\/82116","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=82116"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/82116\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/82117"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=82116"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=82116"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=82116"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}