{"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\/nl\/blog\/administrirovanie\/orchestrator-dlya-mysql-pochemu-bez-nego-nelzya-stroit-otkazoustojchivyj-proekt","title":{"rendered":"Orchestrator voor MySQL: waarom het essentieel is voor het bouwen van een fouttolerant project","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Elk groot project begon met een paar servers. Eerst was er \u00e9\u00e9n DB-server, daarna kwamen er slaven bij om het lezen te schalen. En dan \u2014 stop! Er is \u00e9\u00e9n master en veel slaven; als \u00e9\u00e9n van de slaven wegvalt, is dat geen probleem, maar als de master wegvalt \u2014 dan is het slecht: downtime, en beheerders proberen de server weer online te krijgen. Wat te doen? Reserveer de master. Mijn collega Pavel heeft hier al over geschreven, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/citymobil\/blog\/491044\/\">artikel<\/a><\/noindex>, ik zal het niet herhalen. In plaats daarvan zal ik uitleggen waarom je absoluut een Orchestrator voor MySQL nodig hebt!<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nLaten we beginnen met de belangrijkste vraag: 'Hoe schakelen we de code over naar de nieuwe machine als de master wegvalt?'<\/p>\n<ul>\n<li>Het schema met VIP (Virtual IP) bevalt me het meest, daar zullen we verderop over praten. Het is de eenvoudigste en meest voor de hand liggende oplossing, maar er is een duidelijk beperking: de master die we willen reserveren, moet zich op hetzelfde L2-segment bevinden als de nieuwe machine, wat betekent dat je het tweede datacenter kunt vergeten. En eigenlijk, als je de regel volgt dat een groot L2 slecht is, omdat L2 alleen op de rack is en tussen racks L3, dan heeft zo'n schema nog meer beperkingen.<\/li>\n<li>Je kunt de DNS-naam in de code opnemen en deze resolven via \/etc\/hosts. In werkelijkheid zal er geen resolutie zijn. Voordeel van het schema: er is geen beperking zoals bij de eerste methode, zodat je ook cross-DC's kunt organiseren. Maar dan rijst de voor de hand liggende vraag, hoe snel we via Puppet-Ansible de wijziging in \/etc\/hosts kunnen aanbrengen.<\/li>\n<li>Een tweede methode kan een beetje worden gewijzigd: op alle webservers installeren we een cache DNS, waarlangs de code naar de master-database zal gaan. Je kunt een TTL van 60 voor deze record in DNS instellen. Het lijkt erop dat het, bij een goede implementatie, een goede methode is.<\/li>\n<li>Schema met service discovery, dat het gebruik van Consul en etcd impliceert.<\/li>\n<li>Interesant idee met <noindex><a rel=\"nofollow\" href=\"https:\/\/proxysql.com\/\">ProxySQL<\/a><\/noindex>. We moeten al het verkeer naar MySQL via ProxySQL leiden; ProxySQL kan zelf bepalen wie de master is. Over een van de toepassingen van dit product kun je trouwens lezen in mijn <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/citymobil\/blog\/501730\/\">artikel<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\nDe auteur van Orchestrator, die bij Github werkt, heeft eerst het eerste schema met VIP ge\u00efmplementeerd en daarna omgevormd naar het schema met consul.<\/p>\n<p>Typisch infrastructuurschema:<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator voor MySQL: waarom het essentieel is voor het bouwen van een fouttolerant project\" src=\"\/wp-content\/uploads\/2020\/05\/b08220e7aa6336229cbbfedd78afdcc3.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nIk zal meteen de voor de hand liggende situaties beschrijven die je in aanmerking moet nemen:<\/p>\n<ul>\n<li>Het VIP-adres mag op geen enkele server in de configuratie staan. Laten we een situatie voorstellen: de master is opnieuw opgestart, en terwijl hij opstart, gaat Orchestrator over in failover-modus en maakt een van de slaven tot master; vervolgens komt de oude master weer online, en nu is het VIP op twee machines. Dat is slecht.<\/li>\n<li>Voor de orchestrator moet er een script worden geschreven dat contact maakt met de oude master en de nieuwe master. Op de oude master moet ifdown worden uitgevoerd, en op de nieuwe master ifup vip. Het zou ook goed zijn om in dit script op te nemen dat in het geval van failover de poort op de switch van de oude master simpelweg wordt uitgeschakeld, om split-brain te voorkomen.<\/li>\n<li>Nadat de Orchestrator uw script heeft aangeroepen om eerst de VIP af te nemen en\/of de poort op de switch uit te schakelen, en vervolgens het script op de nieuwe master heeft aangeroepen om de VIP weer op te zetten, vergeet dan niet om met het commando arping aan iedereen te laten weten dat de nieuwe VIP hier nu is.<\/li>\n<li>Op alle slaves moet read_only=1 staan, en zodra u de slave promoot tot master, moet read_only=0 staan.<\/li>\n<li>Vergeet niet dat elke slave die we hebben gekozen voor deze rol een master kan worden (de Orchestrator heeft een volledig mechanisme voor voorkeur om te bepalen welke slave als eerste kandidaat voor de nieuwe master moet worden beschouwd, welke als tweede, en welke slave in geen geval als master moet worden gekozen). Als een slave master wordt, blijft de belasting van de slave bestaan en komt daar de belasting van de master bij, dit moet worden meegenomen in de overweging.<\/li>\n<\/ul>\n<p>\nWaarom heeft u Orchestrator echt nodig als u het niet heeft?<\/p>\n<ul>\n<li>De Orchestrator heeft een gebruiksvriendelijke grafische interface die de hele topologie weergeeft (zie de screenshot hieronder).<\/li>\n<li>Orchestrator kan bijhouden welke slaves achterlopen en waar de replicatie helemaal is mislukt (we hebben scripts aan de Orchestrator gekoppeld om SMS te verzenden).<\/li>\n<li>Orchestrator vertelt u op welke slaves er een GTID errant fout is.<\/li>\n<\/ul>\n<p>\nInterface van Orchestrator:<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator voor MySQL: waarom het essentieel is voor het bouwen van een fouttolerant project\" src=\"\/wp-content\/uploads\/2020\/05\/5129a85ad1c0a5db8e3ecf501cff0d0d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nWat is eigenlijk een GTID errant?<\/p>\n<p>Er zijn twee belangrijkste vereisten voor het functioneren van de Orchestrator:<\/p>\n<ul>\n<li>Op alle machines van het MySQL-cluster moet pseudo GTID zijn ingeschakeld, bij ons is GTID ingeschakeld.<\/li>\n<li>Er moet overal \u00e9\u00e9n type binlogs zijn, statement is mogelijk. Wij hadden een configuratie waarbij de master en de meeste slaves Row hadden, maar op twee is historisch gezien het Mixed-modus overgebleven. Als gevolg hiervan wilde Orchestrator deze slaves gewoon niet verbinden met de nieuwe master.<\/li>\n<\/ul>\n<p>\nVergeet niet dat het belangrijkste in een productie-slave zijn consistentie met de master is! Als u zowel op de master als op de slave een Global Transaction ID (GTID) heeft ingeschakeld, kunt u met de functie gtid_subset controleren of op deze machines daadwerkelijk dezelfde gegevenswijzigende verzoeken zijn uitgevoerd. Meer hierover kunt u lezen. <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\/\">here<\/a><\/noindex>.<\/p>\n<p>Op deze manier laat Orchestrator je via de GTID foutmelding zien dat er op de slave transacties zijn die niet op de master aanwezig zijn. Hoe kan dit gebeuren?<\/p>\n<ul>\n<li>Op de slave is read_only=1 niet ingeschakeld, iemand is aangesloten en heeft een wijzigingsopdracht uitgevoerd.<\/li>\n<li>Op de slave is super_read_only=1 niet ingeschakeld, waardoor een administrator, zich vergisend in de server, is binnengekomen en daar een opdracht heeft uitgevoerd.<\/li>\n<li>Als je beide voorgaande punten hebt overwogen, is er nog een truc: in MySQL komt een opdracht om de binlogs te flushen ook in de binlogs terecht, dus bij de eerste flush op de master zullen ook alle slaves een GTID foutmelding krijgen. Hoe voorkom je dit? In perona-5.7.25-28 is de instelling binlog_skip_flush_commands=1 ge\u00efntroduceerd, die het verbiedt om flush-commando's in de binlogs te schrijven. Op de website mysql.com is dit geregistreerd. <noindex><a rel=\"nofollow\" href=\"https:\/\/bugs.mysql.com\/bug.php?id=88720\">bug<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\nSamenvattend, als je Orchestrator nog niet in failovermodus wilt gebruiken, zet het dan in observatiemodus. Dan heb je altijd een overzichtskaart van de interactie tussen MySQL-machines en visuele informatie over het type replicatie op elke machine, of de slaves achterlopen, en het allerbelangrijkste \u2014 hoe consistent ze zijn met de master!<\/p>\n<p>Een voor de hand liggende vraag: \"Hoe zou Orchestrator moeten werken?\" Het zou een nieuwe master moeten kiezen uit de huidige slaves en vervolgens alle slaves opnieuw op deze master moeten aansluiten (daarvoor is GTID nodig; als je het oude mechanisme met binlog_name en binlog_pos zou gebruiken, zou het simpelweg onmogelijk zijn om de slave van de huidige master naar de nieuwe te schakelen!). Voordat we Orchestrator hadden, moest ik dit een keer handmatig doen. De oude master liep vast door een defecte Adaptec-controller, en er waren ongeveer 10 slaves. Ik moest de VIP van de master naar een van de slaves overzetten en alle andere slaves opnieuw verbinding maken met deze slave. Hoeveel consoles moest ik openen, hoeveel gelijktijdige opdrachten moest ik invoeren... Ik moest wachten tot 3 uur 's nachts, de belasting van alle slaves behalve twee verminderen, de eerste machine van de twee als master instellen, meteen de tweede machine eraan koppelen, dan alle andere slaves aan de nieuwe master koppelen en de belasting terugbrengen. Kortom, vreselijk...<\/p>\n<p>Hoe werkt Orchestrator wanneer het overgaat naar failovermodus? Dit kan het gemakkelijkst worden getoond aan de hand van een situatie waarin we een krachtiger, moderner apparaat als master willen instellen dan datgene wat we nu hebben. <\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator voor MySQL: waarom het essentieel is voor het bouwen van een fouttolerant project\" src=\"\/wp-content\/uploads\/2020\/05\/d2afe9c74b33765e55641b34def3145e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nDe afbeelding toont het midden van het proces. Wat is er tot dit moment al gedaan? We hebben gezegd dat we een bepaalde slave een nieuwe master willen maken, de Orchestrator begon gewoon alle andere slaves opnieuw aan te sluiten, terwijl de nieuwe master de rol van transitmachine vervult. Bij deze opzet ontstaan er geen fouten, alle slaves functioneren, de Orchestrator haalt de VIP van de oude master, verplaatst deze naar de nieuwe, maakt deze read_only=0 en vergeet de oude master. En dat is het! De downtime van onze service is de tijd die nodig is om de VIP over te dragen, dat is 2-3 seconden.<\/p>\n<p>Dat was het voor vandaag, bedankt allemaal. Binnenkort komt het tweede artikel over de Orchestrator. In de bekende Sovjetfilm \"Garage\" zei een personage: \"Met hem zou ik niet op verkenning gaan!\" Welnu, Orchestrator, met jou zou ik wel op verkenning gaan!<br \/>\n<br \/>Bron: <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\/nl\/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=\"nl_NL\" \/>\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\/nl\/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 voor MySQL: waarom je het niet kunt bouwen zonder een failover-bestendig project | ProHoster","description":"Elk groot project begon met een paar servers. Eerst was er \u00e9\u00e9n DB-server, daarna werden er slaves toegevoegd om de leescapaciteit te schalen. En toen \u2014 stop!","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/orchestrator-dlya-mysql-pochemu-bez-nego-nelzya-stroit-otkazoustojchivyj-proekt","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/82116","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=82116"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/82116\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/82117"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=82116"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=82116"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=82116"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}