{"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\/fr\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql","title":{"rendered":"Orchestrator et VIP comme solution HA pour un cluster MySQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Chez Citymobil, nous utilisons la base de donn\u00e9es MySQL comme principal stockage des donn\u00e9es permanentes. Nous avons plusieurs clusters de bases de donn\u00e9es pour diff\u00e9rents services et objectifs.<\/p>\n<p>La disponibilit\u00e9 continue du ma\u00eetre est un indicateur critique de la fonctionnalit\u00e9 de l'ensemble du syst\u00e8me et de ses diff\u00e9rentes parties. La r\u00e9cup\u00e9ration automatique du cluster en cas de panne du ma\u00eetre r\u00e9duit consid\u00e9rablement le temps de r\u00e9ponse aux incidents et le temps d'arr\u00eat du syst\u00e8me. Dans cet article, je vais examiner le sch\u00e9ma de haute disponibilit\u00e9 (HA) du cluster MySQL bas\u00e9 sur <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\">MySQL Orchestrator<\/a><\/noindex> et les adresses IP virtuelles (VIP).<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator et VIP comme solution HA pour un cluster MySQL\" src=\"\/wp-content\/uploads\/2020\/05\/a76ef93caee0fc13d2afb12c25a25531.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Solution HA bas\u00e9e sur VIP<\/h1>\n<p>\nJe vais d'abord expliquer bri\u00e8vement ce qu'est notre syst\u00e8me de stockage de donn\u00e9es.<\/p>\n<p>Nous utilisons un sch\u00e9ma classique de r\u00e9plication avec un seul ma\u00eetre accessible en \u00e9criture et de nombreuses r\u00e9pliques utilis\u00e9es uniquement pour la lecture. Le cluster peut contenir un ma\u00eetre interm\u00e9diaire \u2014 un n\u0153ud qui est \u00e0 la fois une r\u00e9plique et un ma\u00eetre pour d'autres. Les clients acc\u00e8dent aux r\u00e9pliques via HAProxy, ce qui permet de r\u00e9partir uniform\u00e9ment la charge et de se d\u00e9velopper facilement. L'utilisation de HAProxy est due \u00e0 des raisons historiques, et nous sommes actuellement en train de migrer vers ProxySQL.<\/p>\n<p>La r\u00e9plication est effectu\u00e9e en mode semi-synchrone bas\u00e9 sur <code>GTID<\/code>. Cela signifie qu'au moins une r\u00e9plique doit enregistrer la transaction dans le journal avant qu'elle ne soit consid\u00e9r\u00e9e comme r\u00e9ussie. Ce mode de r\u00e9plication offre un \u00e9quilibre optimal entre performance et int\u00e9grit\u00e9 des donn\u00e9es en cas de d\u00e9faillance du n\u0153ud principal. En g\u00e9n\u00e9ral, tous les changements sont transmis du ma\u00eetre aux r\u00e9pliques \u00e0 l'aide de <code>Row Based Replication (RBR)<\/code>, mais certains n\u0153uds peuvent avoir <code>mixed binlog format<\/code>.<\/p>\n<p>L'orchestrateur met r\u00e9guli\u00e8rement \u00e0 jour l'\u00e9tat de la topologie du cluster, analyse les informations re\u00e7ues et, en cas de probl\u00e8me, peut d\u00e9clencher le processus de r\u00e9cup\u00e9ration automatique. Le d\u00e9veloppeur est responsable de ce processus, car il peut \u00eatre impl\u00e9ment\u00e9 de diff\u00e9rentes mani\u00e8res : bas\u00e9 sur VIP, DNS, en utilisant des services de d\u00e9couverte ou des m\u00e9canismes faits maison. <\/p>\n<p>Un des moyens simples de r\u00e9cup\u00e9rer le ma\u00eetre en cas de panne est d'utiliser des adresses VIP flottantes.<\/p>\n<p>Voici ce que vous devez savoir sur cette solution avant de continuer :<\/p>\n<ul>\n<li>Le VIP est une adresse IP qui n'est pas li\u00e9e \u00e0 une interface r\u00e9seau physique sp\u00e9cifique. En cas de d\u00e9faillance d'un n\u0153ud ou lors de travaux planifi\u00e9s, nous pouvons basculer le VIP sur une autre ressource avec un temps d'arr\u00eat minimal.\n<\/li>\n<li>La lib\u00e9ration et l'attribution d'une adresse IP virtuelle sont des op\u00e9rations peu co\u00fbteuses et rapides.\n<\/li>\n<li>Pour travailler avec un VIP, un acc\u00e8s au serveur par SSH est n\u00e9cessaire, ou l'utilisation d'outils sp\u00e9cialis\u00e9s, par exemple, <code>keepalived<\/code>.\n<\/li>\n<\/ul>\n<p>\nExaminons les probl\u00e8mes possibles avec notre ma\u00eetre et envisageons comment le m\u00e9canisme de restauration automatique devrait fonctionner.<\/p>\n<h4>La connectivit\u00e9 r\u00e9seau avec le ma\u00eetre est perdue, ou il y a un probl\u00e8me au niveau du mat\u00e9riel, et le serveur est inaccessible.<\/h4>\n<p><\/p>\n<ol>\n<li>L'orchestrateur met \u00e0 jour la topologie du cluster, chaque r\u00e9plique signale l'inaccessibilit\u00e9 du ma\u00eetre. L'orchestrateur lance le processus de s\u00e9lection d'une r\u00e9plique appropri\u00e9e pour devenir le nouveau ma\u00eetre et commence la restauration.\n<\/li>\n<li>Nous essayons de retirer le VIP de l'ancien ma\u00eetre \u2014 sans succ\u00e8s.\n<\/li>\n<li>La r\u00e9plique passe au r\u00f4le de ma\u00eetre. La topologie est reconstruite.\n<\/li>\n<li>Nous ajoutons une nouvelle interface r\u00e9seau avec un VIP. Comme nous n'avons pas pu retirer le VIP, nous lan\u00e7ons en arri\u00e8re-plan l'envoi p\u00e9riodique de requ\u00eates <b>gratuitous ARP<\/b>. Ce type de requ\u00eate\/r\u00e9ponse permet de mettre \u00e0 jour la table de correspondance des adresses IP et MAC sur les commutateurs connect\u00e9s, en avisant ainsi de la relocation de notre VIP. Cela minimise la probabilit\u00e9 de <code>split brain<\/code> lors du retour de l'ancien ma\u00eetre. \n<\/li>\n<li>Toutes les nouvelles connexions sont imm\u00e9diatement redirig\u00e9es vers le nouveau ma\u00eetre. Les anciennes connexions \u00e9chouent, entra\u00eenant des reprises d'appels \u00e0 la base de donn\u00e9es au niveau de l'application.\n<\/li>\n<\/ol>\n<p><\/p>\n<h4>Le serveur fonctionne normalement, il y a eu une d\u00e9faillance au niveau de la SGBD.<\/h4>\n<p>\nL'algorithme est similaire au cas pr\u00e9c\u00e9dent : mise \u00e0 jour de la topologie et lancement du processus de restauration. \u00c9tant donn\u00e9 que le serveur est accessible, nous lib\u00e9rons avec succ\u00e8s le VIP sur l'ancien ma\u00eetre, le transf\u00e9rons sur le nouveau et envoyons plusieurs requ\u00eates ARP. Le retour possible de l'ancien ma\u00eetre ne doit pas affecter le cluster reconstruit et le fonctionnement de l'application.<\/p>\n<h4>Autres probl\u00e8mes<\/h4>\n<p>\nLa d\u00e9faillance des r\u00e9pliques ou des ma\u00eetres interm\u00e9diaires <em>ne conduit pas<\/em> \u00e0 des actions automatiques et n\u00e9cessite une intervention manuelle.<\/p>\n<p>L'interface r\u00e9seau virtuelle est toujours ajout\u00e9e temporairement, c'est-\u00e0-dire qu'apr\u00e8s le red\u00e9marrage du serveur, la VIP n'est pas automatiquement attribu\u00e9e. Chaque instance de la base de donn\u00e9es d\u00e9marre par d\u00e9faut en mode lecture seule, l'orchest\u00e9rateur bascule automatiquement le nouveau ma\u00eetre en mode \u00e9criture et essaie de d\u00e9finir <code>lecture seule<\/code> sur l'ancien ma\u00eetre. Ces actions visent \u00e0 r\u00e9duire la probabilit\u00e9 <code>split brain<\/code>.<\/p>\n<p>Des probl\u00e8mes peuvent survenir lors du processus de r\u00e9cup\u00e9ration, qu'il convient \u00e9galement de signaler via l'interface utilisateur de l'orchest\u00e9rateur en plus des outils de monitoring standard. Nous avons \u00e9tendu l'API REST en ajoutant cette possibilit\u00e9 (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/pull\/1088\">PR<\/a><\/noindex> est actuellement en cours d'examen).<\/p>\n<p>Le sch\u00e9ma g\u00e9n\u00e9ral de la solution HA est pr\u00e9sent\u00e9 ci-dessous.<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator et VIP comme solution HA pour un cluster MySQL\" src=\"\/wp-content\/uploads\/2020\/05\/485dbbc8f2b1a7595f5fa4f36ad92f7e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Choix du nouveau ma\u00eetre<\/h1>\n<p>\nL'orchest\u00e9rateur est assez intelligent et essaie de choisir <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/blob\/5126b849ae4f655e1cbe0fbddfa0d7299674f712\/go\/inst\/instance_utils.go#L112\">la r\u00e9plique la plus appropri\u00e9e<\/a><\/noindex> comme nouveau ma\u00eetre selon les crit\u00e8res suivants :<\/p>\n<ul>\n<li>le retard de la r\u00e9plique par rapport au ma\u00eetre ;\n<\/li>\n<li>la version de MySQL du ma\u00eetre et de la r\u00e9plique ;\n<\/li>\n<li>le type de r\u00e9plication (RBR, SBR ou mixte) ;\n<\/li>\n<li>la localisation dans un ou plusieurs centres de donn\u00e9es ;\n<\/li>\n<li>la pr\u00e9sence <code>GTID errant<\/code> \u2014 transactions qui ont \u00e9t\u00e9 effectu\u00e9es sur la r\u00e9plique et qui sont absentes sur le ma\u00eetre ;\n<\/li>\n<li>des r\u00e8gles de s\u00e9lection utilisateur sont \u00e9galement prises en compte.\n<\/li>\n<\/ul>\n<p>\nChaque r\u00e9plique n'est pas un candidat id\u00e9al pour devenir ma\u00eetre. Par exemple, la r\u00e9plique peut \u00eatre utilis\u00e9e pour des sauvegardes de donn\u00e9es, ou le serveur peut avoir une configuration mat\u00e9rielle plus faible. L'orchest\u00e9rateur <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/blob\/master\/docs\/topology-recovery.md#adding-promotion-rules\">prend en charge<\/a><\/noindex> permet des r\u00e8gles manuelles gr\u00e2ce auxquelles vous pouvez d\u00e9finir vos pr\u00e9f\u00e9rences de s\u00e9lection des candidats, des plus pr\u00e9f\u00e9r\u00e9s aux plus ignor\u00e9s.<\/p>\n<h1>Temps de r\u00e9ponse et de r\u00e9cup\u00e9ration<\/h1>\n<p>\nEn cas d'incident, il est important de minimiser le temps d'arr\u00eat du syst\u00e8me, nous allons donc examiner les param\u00e8tres MySQL qui influent sur la construction et la mise \u00e0 jour de la topologie du cluster par l'orchest\u00e9rateur :<\/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 le nombre de secondes pendant lesquelles la r\u00e9plique attend la r\u00e9ception de nouvelles donn\u00e9es ou d'un signal heartbeat du ma\u00eetre, avant que la connexion ne soit consid\u00e9r\u00e9e comme perdue et qu'un reconnection soit effectu\u00e9e. Plus la valeur est faible, plus la r\u00e9plique sera capable de d\u00e9terminer rapidement que la connexion avec le ma\u00eetre est rompue. Nous fixons cette valeur \u00e0 5 secondes.\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 nombre de secondes entre les tentatives de reconnection. En cas de probl\u00e8mes r\u00e9seau, une valeur basse de ce param\u00e8tre permettra une reconnexion rapide et \u00e9vitera le lancement du processus de r\u00e9cup\u00e9ration du cluster. La valeur recommand\u00e9e est de 1 seconde.\n<\/li>\n<li><code>MASTER_RETRY_COUNT<\/code> \u2014 nombre maximal de tentatives de reconnexion. \n<\/li>\n<li><code>MASTER_HEARTBEAT_PERIOD<\/code> \u2014 intervalle en secondes apr\u00e8s lequel le ma\u00eetre envoie un signal de heartbeat. Par d\u00e9faut, il est \u00e9gal \u00e0 la moiti\u00e9 de la valeur <code>slave_net_timeout<\/code>.\n<\/li>\n<\/ul>\n<p>\nParam\u00e8tres de l'orchestre :<\/p>\n<ul>\n<li><code>DelayMasterPromotionIfSQLThreadNotUpToDate<\/code> \u2014 s'il est \u00e9gal \u00e0 <code>true<\/code>, alors le r\u00f4le de ma\u00eetre ne sera pas appliqu\u00e9 au r\u00e9plique candidate tant que le fil SQL de la r\u00e9plique n'a pas ex\u00e9cut\u00e9 toutes les transactions non appliqu\u00e9es du Relay Log. Nous utilisons cette option pour ne pas perdre de transactions lors de retards de toutes les r\u00e9pliques candidates.\n<\/li>\n<li><code>InstancePollSeconds<\/code> \u2014 fr\u00e9quence de construction et de mise \u00e0 jour de la topologie.\n<\/li>\n<li><code>RecoveryPollSeconds<\/code> \u2014 fr\u00e9quence d'analyse de la topologie. En cas de d\u00e9tection d'un probl\u00e8me, la r\u00e9cup\u00e9ration de la topologie est lanc\u00e9e. C'est<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\/blob\/548265494b3107ca2581d6ccee059e062a759b77\/go\/config\/config.go#L45\"> une constante<\/a><\/noindex>, \u00e9gale \u00e0 1 seconde.\n<\/li>\n<\/ul>\n<p>\nChaque n\u0153ud du cluster est interrog\u00e9 par l'orchestre une fois toutes les <code>InstancePollSeconds<\/code> secondes. En cas de d\u00e9tection d'un probl\u00e8me, l'\u00e9tat du cluster est forc\u00e9<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\/blob\/548265494b3107ca2581d6ccee059e062a759b77\/go\/logic\/topology_recovery.go#L1409\"> \u00e0 \u00eatre mis \u00e0 jour<\/a><\/noindex>, puis une d\u00e9cision finale est prise sur l'ex\u00e9cution de la r\u00e9cup\u00e9ration. En exp\u00e9rimentant avec divers param\u00e8tres de BD et d'orchestre, nous avons r\u00e9ussi \u00e0 r\u00e9duire la dur\u00e9e de r\u00e9ponse et de r\u00e9cup\u00e9ration \u00e0 30 secondes.<\/p>\n<h1>Stand de test<\/h1>\n<p>\nNous avons commenc\u00e9 le test de l'architecture HA par le d\u00e9veloppement d'un <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ParshinPavel\/mysql-ha-sandbox\">environnement de test local<\/a><\/noindex> et son d\u00e9ploiement ult\u00e9rieur dans les environnements de test et de production. L'environnement local est enti\u00e8rement automatis\u00e9 sur la base de Docker et permet d'exp\u00e9rimenter avec la configuration de l'orchestre et du r\u00e9seau, de mettre \u00e0 l'\u00e9chelle le cluster de 2-3 serveurs \u00e0 plusieurs dizaines et de mener des exercices dans un environnement s\u00e9curis\u00e9. <\/p>\n<p>Lors des exercices, nous choisissons l'une des m\u00e9thodes d'\u00e9mulation de probl\u00e8me : tirer instantan\u00e9ment le ma\u00eetre avec <code>kill -9<\/code>, arr\u00eater le processus en douceur et arr\u00eater le serveur (<code>docker-compose stop<\/code>), simuler des probl\u00e8mes de r\u00e9seau avec <code>iptables -j REJECT<\/code> ou <code>iptables -j DROP<\/code>. Nous nous attendons \u00e0 ces r\u00e9sultats :<\/p>\n<ul>\n<li>l'orchestre d\u00e9tectera les probl\u00e8mes avec le ma\u00eetre et mettra \u00e0 jour la topologie en moins de 10 secondes ;\n<\/li>\n<li>la proc\u00e9dure de r\u00e9cup\u00e9ration d\u00e9marrera automatiquement : la configuration r\u00e9seau changera, le r\u00f4le de ma\u00eetre passera \u00e0 la r\u00e9plique, la topologie sera reconstruite ;\n<\/li>\n<li>le nouveau ma\u00eetre sera disponible pour l'\u00e9criture, les r\u00e9pliques vivantes ne seront pas perdues pendant le processus de reconstruction;\n<\/li>\n<li>les donn\u00e9es commenceront \u00e0 \u00eatre \u00e9crites sur le nouveau ma\u00eetre et \u00e0 \u00eatre r\u00e9pliqu\u00e9es;\n<\/li>\n<li>le temps total de r\u00e9tablissement sera de 30 secondes maximum.\n<\/li>\n<\/ul>\n<p>\nComme vous le savez, le syst\u00e8me peut se comporter diff\u00e9remment dans les environnements de test et de production en raison de la configuration diff\u00e9rente du mat\u00e9riel et du r\u00e9seau, des variations de charge synth\u00e9tique et r\u00e9elle, etc. C'est pourquoi nous organisons p\u00e9riodiquement des exercices en conditions r\u00e9elles, v\u00e9rifiant comment le syst\u00e8me se comporte en cas de perte de connectivit\u00e9 r\u00e9seau ou de d\u00e9gradation de certaines de ses parties. \u00c0 l'avenir, nous souhaitons construire une infrastructure compl\u00e8tement identique pour les deux environnements et automatiser ses tests.<\/p>\n<h1>Conclusions<\/h1>\n<p>\nLe bon fonctionnement du n\u0153ud principal du syst\u00e8me de stockage de donn\u00e9es est l'un des objectifs principaux de l'\u00e9quipe SRE et des op\u00e9rations. La mise en \u0153uvre d'un orchestrateur et d'une solution HA bas\u00e9e sur VIP a permis d'obtenir les r\u00e9sultats suivants :<\/p>\n<ul>\n<li>d\u00e9tection fiable des probl\u00e8mes de topologie du cluster de bases de donn\u00e9es;\n<\/li>\n<li>r\u00e9ponse automatique et rapide aux incidents li\u00e9s au ma\u00eetre, ce qui r\u00e9duit le temps d'arr\u00eat du syst\u00e8me.\n<\/li>\n<\/ul>\n<p>\nCependant, la solution a ses limites et inconv\u00e9nients :<\/p>\n<ul>\n<li>l'\u00e9volutivit\u00e9 du sch\u00e9ma HA sur plusieurs centres de donn\u00e9es n\u00e9cessitera la pr\u00e9sence d'un r\u00e9seau L2 unique entre eux;\n<\/li>\n<li>avant d'attribuer le VIP au nouveau ma\u00eetre, nous devons le lib\u00e9rer sur l'ancien. Le processus est s\u00e9quentiel, ce qui augmente le temps de r\u00e9tablissement;\n<\/li>\n<li>lib\u00e9rer le VIP n\u00e9cessite un acc\u00e8s SSH au serveur, ou tout autre moyen d'appeler des proc\u00e9dures distantes. \u00c9tant donn\u00e9 que le serveur ou la base de donn\u00e9es rencontre des probl\u00e8mes ayant entra\u00een\u00e9 le processus de r\u00e9cup\u00e9ration, nous ne pouvons pas \u00eatre s\u00fbrs que la lib\u00e9ration du VIP se d\u00e9roulera avec succ\u00e8s. Cela pourrait conduire \u00e0 l'apparition de deux serveurs avec la m\u00eame adresse IP virtuelle et \u00e0 des probl\u00e8mes. <code>split brain<\/code>.\n<\/li>\n<\/ul>\n<p>\nPour \u00e9viter <code>split brain<\/code>, on peut utiliser la m\u00e9thode <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/STONITH\">STONITH<\/a><\/noindex> (\u00ab Shoot The Other Node In The Head \u00bb), qui isole ou d\u00e9connecte compl\u00e8tement le n\u0153ud probl\u00e9matique. Il existe d'autres moyens de mettre en \u0153uvre la haute disponibilit\u00e9 d'un cluster : combinaison de VIP et DNS, d\u00e9couverte de services et services proxy, r\u00e9plication synchrone et d'autres m\u00e9thodes, qui ont leurs inconv\u00e9nients et avantages.<\/p>\n<p>J'ai parl\u00e9 de notre approche pour cr\u00e9er un cluster MySQL r\u00e9silient. Il est facile \u00e0 mettre en \u0153uvre et offre un niveau de fiabilit\u00e9 acceptable dans les conditions actuelles. Au fur et \u00e0 mesure que l'ensemble du syst\u00e8me et l'infrastructure \u00e9voluent, cette approche \u00e9voluera sans aucun doute.<br \/>\n<br \/>Source : <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/citymobil\/blog\/491044\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412 \u0421\u0438\u0442\u0438\u043c\u043e\u0431\u0438\u043b \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c \u0431\u0430\u0437\u0443 \u0434\u0430\u043d\u043d\u044b\u0445 MySQL \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0433\u043e \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u044b\u0445 \u0434\u0430\u043d\u043d\u044b\u0445. \u0423 \u043d\u0430\u0441 \u0435\u0441\u0442\u044c \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u043e\u0432 \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445 \u043f\u043e\u0434 \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u044b \u0438 \u0446\u0435\u043b\u0438. \u041f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u0430\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u044c \u043c\u0430\u0441\u0442\u0435\u0440\u0430 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043a\u0440\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u043c \u043f\u043e\u043a\u0430\u0437\u0430\u0442\u0435\u043b\u0435\u043c \u0440\u0430\u0431\u043e\u0442\u043e\u0441\u043f\u043e\u0441\u043e\u0431\u043d\u043e\u0441\u0442\u0438 \u0432\u0441\u0435\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u0438 \u0435\u0435 \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u044b\u0445 \u0447\u0430\u0441\u0442\u0435\u0439. \u0410\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0435 \u0432\u043e\u0441\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0435 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u043e\u0442\u043a\u0430\u0437\u0430 \u043c\u0430\u0441\u0442\u0435\u0440\u0430 \u0441\u0438\u043b\u044c\u043d\u043e \u0441\u043d\u0438\u0436\u0430\u0435\u0442 \u0432\u0440\u0435\u043c\u044f \u0440\u0435\u0430\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u043d\u0430 \u0438\u043d\u0446\u0438\u0434\u0435\u043d\u0442 \u0438 \u0432\u0440\u0435\u043c\u044f \u043f\u0440\u043e\u0441\u0442\u043e\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u044b. [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":82114,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-82113","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412 \u0421\u0438\u0442\u0438\u043c\u043e\u0431\u0438\u043b \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c \u0431\u0430\u0437\u0443 \u0434\u0430\u043d\u043d\u044b\u0445 MySQL \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0433\u043e \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u044b\u0445 \u0434\u0430\u043d\u043d\u044b\u0445.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"fr_FR\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Orchestrator \u0438 VIP \u043a\u0430\u043a HA-\u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u0434\u043b\u044f \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 MySQL | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412 \u0421\u0438\u0442\u0438\u043c\u043e\u0431\u0438\u043b \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c \u0431\u0430\u0437\u0443 \u0434\u0430\u043d\u043d\u044b\u0445 MySQL \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0433\u043e \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u044b\u0445 \u0434\u0430\u043d\u043d\u044b\u0445.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/fr\/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 et VIP en tant que solution HA pour le cluster MySQL | ProHoster","description":"Chez Citimobil, nous utilisons la base de donn\u00e9es MySQL comme principal stockage de donn\u00e9es permanentes.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Orchestrator \u0438 VIP \u043a\u0430\u043a HA-\u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u0434\u043b\u044f \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 MySQL | ProHoster","og:description":"\u0412 \u0421\u0438\u0442\u0438\u043c\u043e\u0431\u0438\u043b \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c \u0431\u0430\u0437\u0443 \u0434\u0430\u043d\u043d\u044b\u0445 MySQL \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0433\u043e \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u044b\u0445 \u0434\u0430\u043d\u043d\u044b\u0445.","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-05-19T11:42:51+00:00","article:modified_time":"2020-05-19T11:42:51+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"82113","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:44:23","updated":"2022-09-28 00:08:45","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/82113","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=82113"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/82113\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/82114"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=82113"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=82113"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=82113"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}