{"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\/da\/blog\/administrirovanie\/orchestrator-dlya-mysql-pochemu-bez-nego-nelzya-stroit-otkazoustojchivyj-proekt","title":{"rendered":"Orchestrator til MySQL: hvorfor det er umuligt at bygge et fejltolerant projekt uden det","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Enhver stor projekt startede med et par servere. F\u00f8rst var der \u00e9n DB-server, og s\u00e5 blev der tilf\u00f8jet slaver for at skalere l\u00e6sningen. Og her stopper det! Der er \u00e9n master og mange slaver; hvis en af slaverne g\u00e5r ned, er alt fint, men hvis masteren g\u00e5r ned \u2014 s\u00e5 bliver det problematisk: nedetid, administratorer, der sveder for at f\u00e5 serveren op at k\u00f8re. Hvad skal man g\u00f8re? Reserv\u00e9r masteren. Min kollega Pavel har allerede skrevet om dette, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/citymobil\/blog\/491044\/\">artiklen<\/a><\/noindex>, s\u00e5 jeg vil ikke gentage det. I stedet vil jeg fort\u00e6lle, hvorfor du absolut har brug for en Orchestrator til MySQL!<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nLad os starte med det vigtigste sp\u00f8rgsm\u00e5l: \"Hvordan skifter vi koden til den nye maskine, hvis masteren g\u00e5r ned?\".<\/p>\n<ul>\n<li>Skemaet med VIP (Virtual IP) kan jeg bedst lide, og det vil vi tale om nedenfor. Det er det enkleste og mest oplagte, selvom det har en klar begr\u00e6nsning: den master, vi vil reservere, skal v\u00e6re i L2-segmentet med den nye maskine, s\u00e5 man kan glemme den anden datacenter. Og rent ud sagt, hvis man f\u00f8lger reglen om, at en stor L2 er en skidt id\u00e9, fordi L2 kun er pristrygt, mens der er L3 mellem reolerne, s\u00e5 har et s\u00e5dant skema endnu flere begr\u00e6nsninger.<\/li>\n<li>Man kan skrive DNS-navnet ind i koden og opl\u00f8se det via \/etc\/hosts. I virkeligheden vil opl\u00f8sningen ikke finde sted. Fordelen ved skemaet: der er ingen af de begr\u00e6nsninger, der kendetegner den f\u00f8rste metode, s\u00e5 man kan ogs\u00e5 organisere cross-datacenter. Men s\u00e5 opst\u00e5r det \u00e5benlyse sp\u00f8rgsm\u00e5l, hvor hurtigt vi via Puppet-Ansible kan overf\u00f8re \u00e6ndringen til \/etc\/hosts.<\/li>\n<li>Den anden metode kan \u00e6ndres en smule: p\u00e5 alle webserverne installerer vi en caching DNS, som koden vil bruge til at kommunikerede med master-databasen. Man kan s\u00e6tte TTL til 60 for denne post i DNS. Det virker som en god metode, hvis det implementeres korrekt.<\/li>\n<li>Skemaet med service discovery, som involverer anvendelse af Consul og etcd.<\/li>\n<li>En interessant mulighed med <noindex><a rel=\"nofollow\" href=\"https:\/\/proxysql.com\/\">ProxySQL<\/a><\/noindex>. Al trafik til MySQL skal g\u00e5 gennem ProxySQL, som selv kan bestemme, hvem der er master lige nu. Forresten kan man l\u00e6se om en af anvendelserne af dette produkt i min <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/citymobil\/blog\/501730\/\">artikel<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\nForfatteren af Orchestrator, der arbejdede i Github, implementerede f\u00f8rst det f\u00f8rste skema med VIP og derefter \u00e6ndrede det til skemaet med Consul.<\/p>\n<p>Typisk infrastruktur skema:<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator til MySQL: hvorfor det er umuligt at bygge et fejltolerant projekt uden det\" src=\"\/wp-content\/uploads\/2020\/05\/b08220e7aa6336229cbbfedd78afdcc3.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nLad mig straks beskrive de \u00e5benlyse situationer, der skal overvejes:<\/p>\n<ul>\n<li>VIP-adressen m\u00e5 ikke v\u00e6re opf\u00f8rt i konfigurationen p\u00e5 nogen af serverne. Lad os forestille os en situation: masteren genstarter, og mens den boot'er op, g\u00e5r Orchestrator over i failover-tilstand og g\u00f8r en af slaverne til master; derefter starter den gamle master op igen, og nu er VIP aktiv p\u00e5 to maskiner. Det er skidt.<\/li>\n<li>For the orchestrator, you will need to write a script that interacts with the old master and the new master. On the old one, you should execute ifdown, and on the new master \u2014 ifup vip. It would also be good to include in this script that in the case of failover, the port on the switch of the old master is simply turned off to avoid any split brain.<\/li>\n<li>After the Orchestrator has invoked your script to first remove the VIP and\/or turn off the port on the switch, and then on the new master called the script to bring up the VIP, do not forget to use the arping command to notify everyone that the new VIP is now here.<\/li>\n<li>All slaves must have read_only=1, and as soon as you promote a slave to a master, it should switch to read_only=0.<\/li>\n<li>Remember that any slave we choose can become a master (the Orchestrator has a whole mechanism for preference, which slave to consider a candidate for the new master first, which second, and which slave should definitely not be chosen as a master under any circumstances). If a slave becomes a master, its load will remain as a slave's load and the master's load will be added, which needs to be considered.<\/li>\n<\/ul>\n<p>\nWhy do you absolutely need an Orchestrator if you don't have one?<\/p>\n<ul>\n<li>The Orchestrator has a very convenient graphical interface displaying the entire topology (see the screenshot below).<\/li>\n<li>Orchestrator can monitor which slaves are lagging behind and where replication has actually failed (we have scripts attached to Orchestrator for sending SMS).<\/li>\n<li>Orchestrator tells you which slaves have a GTID errant error.<\/li>\n<\/ul>\n<p>\nOrchestrator Interface:<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator til MySQL: hvorfor det er umuligt at bygge et fejltolerant projekt uden det\" src=\"\/wp-content\/uploads\/2020\/05\/5129a85ad1c0a5db8e3ecf501cff0d0d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nWhat is GTID errant?<\/p>\n<p>There are two main requirements for the Orchestrator to work:<\/p>\n<ul>\n<li>It is necessary that pseudo GTID is enabled on all MySQL cluster machines; we have GTID enabled.<\/li>\n<li>It is required that there is a single type of binary logs everywhere, statement can be used. We had a configuration where the master and most slaves were using Row, while two historically remained in Mixed mode. As a result, these slaves were simply not accepted by the Orchestrator into the new master.<\/li>\n<\/ul>\n<p>\nRemember that the most important aspect of a production slave is its consistency with the master! If both the master and the slave have Global Transaction ID (GTID) enabled, then through the gtid_subset function, you can find out if the same data modification queries have indeed been executed on these machines. More details can be read about this. <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\/\">her<\/a><\/noindex>.<\/p>\n<p>S\u00e5ledes viser Orchestrator dig gennem GTID-fejlen, at der er transaktioner p\u00e5 slaven, som ikke findes p\u00e5 masteren. Hvordan kan dette ske?<\/p>\n<ul>\n<li>Read_only=1 er ikke aktiveret p\u00e5 slaven, s\u00e5 en bruger har tilsluttet sig og udf\u00f8rt en \u00e6ndringsanmodning.<\/li>\n<li>Super_read_only=1 er ikke aktiveret p\u00e5 slaven, derfor er admin, forvekslende serverne, g\u00e5et ind og udf\u00f8rt en anmodning der.<\/li>\n<li>Hvis du har taget begge de foreg\u00e5ende punkter i betragtning, er der endnu en finurlighed: i MySQL registreres anmodningen om at flush binlogs ogs\u00e5 i binloggen, s\u00e5 ved den f\u00f8rste flush p\u00e5 masteren og p\u00e5 alle slaver vil der opst\u00e5 en GTID-fejl. Hvordan undg\u00e5r man dette? I versionen perona-5.7.25-28 er der en indstilling, binlog_skip_flush_commands=1, som forbyder at skrive flush til binloggerne. Der findes mere information p\u00e5 mysql.com. <noindex><a rel=\"nofollow\" href=\"https:\/\/bugs.mysql.com\/bug.php?id=88720\">fejl i projektet Chromium<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\nFor at opsummere alt det ovenst\u00e5ende. Hvis du endnu ikke \u00f8nsker at bruge Orchestrator i failover-tilstand, s\u00e5 s\u00e6t det i overv\u00e5gningsmodus. S\u00e5 vil du altid have et overblik over interaktionerne mellem MySQL-maskinerne og visuel information om, hvilken type replikation der er p\u00e5 hver maskine, om slaver er forsinkede, og vigtigst af alt \u2014 hvor konsistente de er med masteren!<\/p>\n<p>Et \u00e5benlyst sp\u00f8rgsm\u00e5l: \u201eHvordan skal Orchestrator fungere?\u201c. Den skal v\u00e6lge en ny master blandt de nuv\u00e6rende slaver, og derefter genforbinde alle slaver til den (det er netop derfor GTID er n\u00f8dvendigt; hvis man bruger den gamle mekanisme med binlog_name og binlog_pos, s\u00e5 er det simpelthen umuligt at skifte en slave fra den nuv\u00e6rende master til den nye!). F\u00f8r vi fik Orchestrator, m\u00e5tte jeg en gang g\u00f8re alt dette manuelt. Den gamle master fr\u00f8s p\u00e5 grund af en defekt Adaptec-controller, og der var omkring 10 slaver. Jeg m\u00e5tte flytte VIP fra masteren til en af slaverne og genforbinde alle de \u00f8vrige slaver til den. Hvor mange konsoller m\u00e5tte jeg \u00e5bne, hvor mange samtidige kommandoer skulle jeg indtaste ... Jeg m\u00e5tte vente indtil klokken 3 om natten, lette belastningen p\u00e5 alle slaver, undtagen to, g\u00f8re den f\u00f8rste maskine til master, straks tilslutte den anden maskine, s\u00e5 tilslutte alle andre slaver til den nye master og genoprette belastningen. Alt i alt, et mareridt ...<\/p>\n<p>Hvordan fungerer Orchestrator, n\u00e5r den skifter til failover-tilstand? Det er nemmest at vise ved at tage udgangspunkt i en situation, hvor vi \u00f8nsker at g\u00f8re en mere kraftfuld og moderne maskine til master i stedet for den nuv\u00e6rende. <\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator til MySQL: hvorfor det er umuligt at bygge et fejltolerant projekt uden det\" src=\"\/wp-content\/uploads\/2020\/05\/d2afe9c74b33765e55641b34def3145e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nIllustrationen viser midten af processen. Hvad er allerede blevet gjort p\u00e5 dette tidspunkt? Vi sagde, at vi \u00f8nskede at g\u00f8re en slave til en ny master, Orchestrator begyndte bare at genkoble alle andre slaver til den, mens den nye master fungerer som en transitmaskine. I et s\u00e5dant setup opst\u00e5r der ikke fejl, alle slaver fungerer, Orchestrator tager VIP fra den gamle master, flytter det til den nye, s\u00e6tter read_only=0 og glemmer den gamle master. S\u00e5dan! Nedetiden for vores service er tiden til at flytte VIP, det tager 2-3 sekunder.<\/p>\n<p>Det var alt for i dag, tak allesammen. Snart kommer den anden artikel om Orchestrator. I den velkendte sovjetiske film \"Garagen\" sagde en karakter: \"Jeg ville ikke g\u00e5 i rekognoscering med ham!\" S\u00e5 ja, Orchestrator, jeg ville g\u00e5 i rekognoscering med dig!<br \/>\n<br \/>Kilde: <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.3 - 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\/da\/blog\/administrirovanie\/orchestrator-dlya-mysql-pochemu-bez-nego-nelzya-stroit-otkazoustojchivyj-proekt\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\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\/da\/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\udd47Orchestrator til MySQL: hvorfor det er umuligt at bygge et fejltolerant projekt uden det | ProHoster","description":"Enhver stor projekt startede med et par servere. F\u00f8rst var der \u00e9n DB-server, derefter kom der slaver til for at skalere l\u00e6sningen. Og her \u2013 stop!","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/orchestrator-dlya-mysql-pochemu-bez-nego-nelzya-stroit-otkazoustojchivyj-proekt","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/82116","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=82116"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/82116\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/82117"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=82116"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=82116"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=82116"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}