{"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\/es\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql","title":{"rendered":"Orchestrator y VIP como soluci\u00f3n HA para el cl\u00faster MySQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>En Sitimobil utilizamos la base de datos MySQL como nuestro principal almacenamiento de datos persistentes. Tenemos varios cl\u00fasteres de bases de datos para distintos servicios y objetivos.<\/p>\n<p>La disponibilidad continua del maestro es un indicador cr\u00edtico del funcionamiento de todo el sistema y sus partes individuales. La recuperaci\u00f3n autom\u00e1tica del cl\u00faster en caso de fallo del maestro reduce significativamente el tiempo de respuesta a incidentes y el tiempo de inactividad del sistema. En este art\u00edculo, revisar\u00e9 el esquema de alta disponibilidad (HA) del cl\u00faster MySQL basado en <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\">MySQL Orchestrator<\/a><\/noindex> y direcciones IP virtuales (VIP).<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator y VIP como soluci\u00f3n HA para el cl\u00faster 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>Soluci\u00f3n HA basada en VIP<\/h1>\n<p>\nPrimero, har\u00e9 un breve resumen sobre nuestra arquitectura de almacenamiento de datos.<\/p>\n<p>Utilizamos un esquema cl\u00e1sico de replicaci\u00f3n con un \u00fanico maestro, disponible para escritura, y m\u00faltiples r\u00e9plicas, que se utilizan solo para lectura. El cl\u00faster puede contener un maestro intermedio: un nodo que es simult\u00e1neamente r\u00e9plica y maestro para otros. Los clientes se conectan a las r\u00e9plicas a trav\u00e9s de HAProxy, lo que permite distribuir la carga de manera uniforme y escalar f\u00e1cilmente. El uso de HAProxy se debe a razones hist\u00f3ricas, y ahora estamos en proceso de migraci\u00f3n a ProxySQL.<\/p>\n<p>La replicaci\u00f3n se lleva a cabo en modo semis\u00edncrono basado en <code>GTID<\/code>. Esto significa que al menos una r\u00e9plica debe registrar la transacci\u00f3n en el registro antes de que se considere exitosa. Este modo de replicaci\u00f3n garantiza un equilibrio \u00f3ptimo entre rendimiento y conservaci\u00f3n de datos en caso de fallo del nodo principal. Principalmente, todos los cambios se transmiten del maestro a las r\u00e9plicas mediante <code>Row Based Replication (RBR)<\/code>, pero algunos nodos pueden tener <code>mixed binlog format<\/code>.<\/p>\n<p>El Orchestrator actualiza peri\u00f3dicamente el estado de la topolog\u00eda del cl\u00faster, analiza la informaci\u00f3n recibida y, en caso de problemas, puede iniciar el procedimiento de recuperaci\u00f3n autom\u00e1tica. Este procedimiento est\u00e1 a cargo del desarrollador, ya que se puede implementar de diversas maneras: bas\u00e1ndose en VIP, DNS, utilizando servicios de descubrimiento o mecanismos personalizados. <\/p>\n<p>Una de las formas m\u00e1s sencillas de recuperar el maestro en caso de fallo es utilizar direcciones VIP flotantes.<\/p>\n<p>Lo que necesitas saber sobre esta soluci\u00f3n antes de continuar:<\/p>\n<ul>\n<li>VIP es una direcci\u00f3n IP que no est\u00e1 vinculada a una interfaz de red f\u00edsica espec\u00edfica. En caso de que un nodo falle o durante el mantenimiento programado, podemos transferir el VIP a otro recurso con un tiempo de inactividad m\u00ednimo.\n<\/li>\n<li>Liberar y emitir una direcci\u00f3n IP virtual son operaciones baratas y r\u00e1pidas.\n<\/li>\n<li>Para trabajar con VIP se requiere acceso al servidor por SSH, o el uso de utilidades especiales, como <code>keepalived<\/code>.\n<\/li>\n<\/ul>\n<p>\nConsideremos posibles problemas con nuestro maestro y presentemos c\u00f3mo debe funcionar el mecanismo de recuperaci\u00f3n autom\u00e1tica.<\/p>\n<h4>Se perdi\u00f3 la conectividad de red con el maestro, o surgi\u00f3 un problema a nivel de hardware, y el servidor no est\u00e1 disponible.<\/h4>\n<p><\/p>\n<ol>\n<li>El orquestador actualiza la topolog\u00eda del cl\u00faster, cada r\u00e9plica informa sobre la falta de disponibilidad del maestro. El orquestador inicia el proceso de elecci\u00f3n de una r\u00e9plica adecuada para convertirse en el nuevo maestro y comienza la recuperaci\u00f3n.\n<\/li>\n<li>Intentamos retirar el VIP del viejo maestro - sin \u00e9xito.\n<\/li>\n<li>La r\u00e9plica asume el rol de maestro. La topolog\u00eda se reestructura.\n<\/li>\n<li>Agregamos una nueva interfaz de red con VIP. Dado que no se pudo retirar el VIP, en segundo plano iniciamos el env\u00edo peri\u00f3dico de un <b>gratuitous ARP<\/b>. Este tipo de solicitud\/respuesta permite actualizar en los switches conectados la tabla de correspondencia entre las direcciones IP y MAC, notificando as\u00ed sobre el traslado de nuestro VIP. Esto minimiza la probabilidad de <code>split brain<\/code> al volver el viejo maestro. \n<\/li>\n<li>Todas las nuevas conexiones se redirigen de inmediato al nuevo maestro. Las conexiones antiguas terminan sin \u00e9xito, y se realizan reintentos a la base de datos a nivel de aplicaci\u00f3n.\n<\/li>\n<\/ol>\n<p><\/p>\n<h4>El servidor funciona en modo normal, hubo una falla a nivel de SGBD.<\/h4>\n<p>\nEl algoritmo es an\u00e1logo al caso anterior: actualizaci\u00f3n de la topolog\u00eda e inicio del proceso de recuperaci\u00f3n. Dado que el servidor est\u00e1 disponible, liberamos exitosamente el VIP del viejo maestro, lo transferimos al nuevo y enviamos varias solicitudes ARP. El posible retorno del viejo maestro no debe afectar el cl\u00faster reestructurado y el funcionamiento de la aplicaci\u00f3n.<\/p>\n<h4>Otros problemas<\/h4>\n<p>\nFallas de r\u00e9plicas o maestros intermedios <em>no conducen<\/em> a acciones autom\u00e1ticas y requieren intervenci\u00f3n manual.<\/p>\n<p>La interfaz de red virtual siempre se agrega temporalmente, es decir, despu\u00e9s de reiniciar el servidor, el VIP no se asigna autom\u00e1ticamente. Cada instancia de la BD se inicia por defecto en modo solo lectura; el orquestador cambia autom\u00e1ticamente el nuevo maestro a modo escritura y trata de establecer <code>solo lectura<\/code> en el antiguo maestro. Estas acciones est\u00e1n destinadas a disminuir la probabilidad de <code>split brain<\/code>.<\/p>\n<p>Durante el proceso de recuperaci\u00f3n pueden surgir problemas, los cuales tambi\u00e9n se deben notificar a trav\u00e9s de la interfaz de usuario del orquestador adem\u00e1s de los medios de monitoreo est\u00e1ndar. Hemos ampliado la API REST agregando esta posibilidad (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/pull\/1088\">PR<\/a><\/noindex> actualmente est\u00e1 en revisi\u00f3n).<\/p>\n<p>El esquema general de la soluci\u00f3n HA se presenta a continuaci\u00f3n.<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrator y VIP como soluci\u00f3n HA para el cl\u00faster MySQL\" src=\"\/wp-content\/uploads\/2020\/05\/485dbbc8f2b1a7595f5fa4f36ad92f7e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Selecci\u00f3n de un nuevo maestro<\/h1>\n<p>\nEl orquestador es lo suficientemente inteligente y trata de elegir <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/blob\/5126b849ae4f655e1cbe0fbddfa0d7299674f712\/go\/inst\/instance_utils.go#L112\">la r\u00e9plica m\u00e1s adecuada<\/a><\/noindex> como nuevo maestro seg\u00fan los siguientes criterios:<\/p>\n<ul>\n<li>retraso de la r\u00e9plica respecto al maestro;\n<\/li>\n<li>versi\u00f3n de MySQL del maestro y de la r\u00e9plica;\n<\/li>\n<li>tipo de replicaci\u00f3n (RBR, SBR o mixta);\n<\/li>\n<li>ubicaci\u00f3n en uno o distintos centros de datos;\n<\/li>\n<li>presencia de <code>GTID errante<\/code> \u2014 transacciones que se han ejecutado en la r\u00e9plica y que faltan en el maestro;\n<\/li>\n<li>tambi\u00e9n se tienen en cuenta las reglas personalizadas de selecci\u00f3n.\n<\/li>\n<\/ul>\n<p>\nNo cada r\u00e9plica es un candidato ideal para ser maestro. Por ejemplo, la r\u00e9plica puede usarse para crear copias de seguridad de datos, o el servidor puede tener una configuraci\u00f3n de hardware m\u00e1s d\u00e9bil. El orquestador <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/blob\/master\/docs\/topology-recovery.md#adding-promotion-rules\">soporta<\/a><\/noindex> reglas manuales, mediante las cuales se pueden ajustar las preferencias para la selecci\u00f3n de candidatos desde los m\u00e1s preferidos hasta los ignorados.<\/p>\n<h1>Tiempo de respuesta y recuperaci\u00f3n<\/h1>\n<p>\nEn caso de un incidente, es importante minimizar el tiempo de inactividad del sistema; de ah\u00ed que consideremos los par\u00e1metros de MySQL que afectan la construcci\u00f3n y actualizaci\u00f3n de la topolog\u00eda del cl\u00faster por parte del orquestador:<\/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 cantidad de segundos durante los cuales la r\u00e9plica espera la llegada de nuevos datos o la se\u00f1al de latido del maestro antes de que la conexi\u00f3n se considere perdida y se realice la reconexi\u00f3n. Cuanto menor sea el valor, m\u00e1s r\u00e1pido podr\u00e1 la r\u00e9plica determinar que la conexi\u00f3n con el maestro se ha interrumpido. Establecemos este valor en 5 segundos.\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 cantidad de segundos entre los intentos de reconexi\u00f3n. En caso de problemas de red, un valor bajo de este par\u00e1metro permitir\u00e1 reconectarse r\u00e1pidamente y evitar el inicio del proceso de recuperaci\u00f3n del cl\u00faster. Se recomienda un valor de 1 segundo.\n<\/li>\n<li><code>MASTER_RETRY_COUNT<\/code> \u2014 n\u00famero m\u00e1ximo de intentos de reconexi\u00f3n. \n<\/li>\n<li><code>MASTER_HEARTBEAT_PERIOD<\/code> \u2014 intervalo en segundos, despu\u00e9s del cual el maestro env\u00eda una se\u00f1al de latido. Por defecto es la mitad del valor de <code>slave_net_timeout<\/code>.\n<\/li>\n<\/ul>\n<p>\nPar\u00e1metros del orquestador:<\/p>\n<ul>\n<li><code>DelayMasterPromotionIfSQLThreadNotUpToDate<\/code> \u2014 si es igual a <code>true<\/code>, el rol de maestro no se aplicar\u00e1 en el replicador candidato hasta que el hilo SQL del replicador haya ejecutado todas las transacciones no aplicadas del Relay Log. Usamos esta opci\u00f3n para no perder transacciones en condiciones de retraso de todos los replicadores candidatos.\n<\/li>\n<li><code>InstancePollSeconds<\/code> \u2014 frecuencia de construcci\u00f3n y actualizaci\u00f3n de la topolog\u00eda.\n<\/li>\n<li><code>RecoveryPollSeconds<\/code> \u2014 frecuencia de an\u00e1lisis de la topolog\u00eda. Si se detecta un problema, se inicia la recuperaci\u00f3n de la topolog\u00eda. Esto es<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\/blob\/548265494b3107ca2581d6ccee059e062a759b77\/go\/config\/config.go#L45\"> una constante<\/a><\/noindex>, igual a 1 segundo.\n<\/li>\n<\/ul>\n<p>\nCada nodo del cl\u00faster es sondeado por el orquestador una vez cada <code>InstancePollSeconds<\/code> segundos. Al detectar un problema, el estado del cl\u00faster se actualiza forzosamente<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\/blob\/548265494b3107ca2581d6ccee059e062a759b77\/go\/logic\/topology_recovery.go#L1409\"> , y luego se toma una decisi\u00f3n final sobre la recuperaci\u00f3n. Experimentando con varios par\u00e1metros de la base de datos y del orquestador, hemos logrado reducir la duraci\u00f3n de la respuesta y la recuperaci\u00f3n a 30 segundos.<\/a><\/noindex>Banco de pruebas<\/p>\n<h1>Comenzamos las pruebas del esquema de HA con el desarrollo de un<\/h1>\n<p>\nbanco de pruebas local <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ParshinPavel\/mysql-ha-sandbox\">y su posterior implementaci\u00f3n en entornos de prueba y producci\u00f3n. El banco local est\u00e1 completamente automatizado basado en Docker y permite experimentar con la configuraci\u00f3n del orquestador y de la red, escalar el cl\u00faster de 2-3 servidores a varias decenas y realizar ejercicios en un entorno seguro.<\/a><\/noindex> Durante los ejercicios, elegimos uno de los m\u00e9todos de simulaci\u00f3n de problemas: eliminar instant\u00e1neamente al maestro usando <\/p>\n<p>kill -9 <code>, finalizar suavemente el proceso y detener el servidor (<\/code>docker-compose stop<code>), simular problemas de red usando<\/code>iptables -j REJECT <code>iptables -j DROP<\/code> o <code>. Esperamos los siguientes resultados:<\/code>el orquestador detectar\u00e1 problemas con el maestro y actualizar\u00e1 la topolog\u00eda en no m\u00e1s de 10 segundos;<\/p>\n<ul>\n<li>se iniciar\u00e1 autom\u00e1ticamente el procedimiento de recuperaci\u00f3n: la configuraci\u00f3n de red cambiar\u00e1, el rol de maestro se transferir\u00e1 al replicador, la topolog\u00eda se reconstruir\u00e1;\n<\/li>\n<li>se iniciar\u00e1 autom\u00e1ticamente el procedimiento de recuperaci\u00f3n: se cambiar\u00e1 la configuraci\u00f3n de red, el rol de maestro pasar\u00e1 a la r\u00e9plica y la topolog\u00eda se reestructurar\u00e1;\n<\/li>\n<li>la nueva maestro estar\u00e1 disponible para escritura, las r\u00e9plicas en vivo no se perder\u00e1n durante el proceso de reconstrucci\u00f3n;\n<\/li>\n<li>los datos comenzar\u00e1n a escribirse en el nuevo maestro y a replicarse;\n<\/li>\n<li>el tiempo total de recuperaci\u00f3n ser\u00e1 de no m\u00e1s de 30 segundos.\n<\/li>\n<\/ul>\n<p>\nComo saben, el sistema puede comportarse de manera diferente en entornos de prueba y producci\u00f3n debido a la configuraci\u00f3n diferente del \"hardware\" y la red, diferencias en la carga sint\u00e9tica y real, etc. Por eso, peri\u00f3dicamente realizamos ejercicios en condiciones reales, verificando c\u00f3mo se comporta el sistema ante la p\u00e9rdida de conectividad de red o la degradaci\u00f3n de sus partes individuales. En el futuro, queremos construir una infraestructura completamente id\u00e9ntica para ambos entornos y automatizar su prueba.<\/p>\n<h1>Conclusiones<\/h1>\n<p>\nEl funcionamiento del nodo principal del sistema de almacenamiento de datos es una de las principales tareas del equipo SRE y de operaciones. La implementaci\u00f3n de un orquestador y soluciones de alta disponibilidad basadas en VIP ha permitido lograr los siguientes resultados:<\/p>\n<ul>\n<li>detecci\u00f3n confiable de problemas con la topolog\u00eda del cl\u00faster de base de datos;\n<\/li>\n<li>respuesta autom\u00e1tica y r\u00e1pida a incidentes relacionados con el maestro, lo que reduce el tiempo de inactividad del sistema.\n<\/li>\n<\/ul>\n<p>\nSin embargo, la soluci\u00f3n tiene sus limitaciones y desventajas:<\/p>\n<ul>\n<li>escalar el esquema de HA a varios centros de datos requerir\u00e1 una red L2 \u00fanica entre ellos;\n<\/li>\n<li>antes de asignar VIP al nuevo maestro, necesitamos liberarlo en el viejo. El proceso es secuencial, lo que aumenta el tiempo de recuperaci\u00f3n;\n<\/li>\n<li>liberar VIP requiere acceso SSH al servidor, o cualquier otro m\u00e9todo de invocaci\u00f3n de procedimientos remotos. Dado que el servidor o la base de datos est\u00e1 experimentando problemas que provocaron el proceso de recuperaci\u00f3n, no podemos estar seguros de que la liberaci\u00f3n de VIP ser\u00e1 exitosa. Esto puede llevar a la aparici\u00f3n de dos servidores con la misma direcci\u00f3n IP virtual y un problema. <code>split brain<\/code>.\n<\/li>\n<\/ul>\n<p>\nPara evitar <code>split brain<\/code>, se puede utilizar el m\u00e9todo <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/STONITH\">STONITH<\/a><\/noindex> (\u201cShoot The Other Node In The Head\u201d), que a\u00edsla o apaga completamente el nodo problem\u00e1tico. Existen tambi\u00e9n otros m\u00e9todos para implementar alta disponibilidad en el cl\u00faster: una combinaci\u00f3n de VIP y DNS, detecci\u00f3n de servicios y proxies, replicaci\u00f3n s\u00edncrona y otros m\u00e9todos que tienen sus desventajas y ventajas.<\/p>\n<p>He hablado sobre nuestro enfoque para crear un cl\u00faster MySQL tolerante a fallos. Es f\u00e1cil de implementar y proporciona un nivel aceptable de confiabilidad en las condiciones actuales. A medida que toda la sistema en general y la infraestructura en particular evolucionen, este enfoque sin duda tambi\u00e9n evolucionar\u00e1.<br \/>\n<br \/>Fuente: <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\/es\/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=\"es_ES\" \/>\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\/es\/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\udd47Orchestrador y VIP como soluci\u00f3n de alta disponibilidad para el cl\u00faster MySQL | ProHoster","description":"En Sitimobil utilizamos la base de datos MySQL como nuestro principal almacenamiento de datos persistentes.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/82113","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=82113"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/82113\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/82114"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=82113"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=82113"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=82113"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}