Panorama de alta disponibilidad de MySQL en 2017 (bebés)

Esta publicación es la tercera de una serie que se centra en las soluciones MySQL de alta disponibilidad disponibles en 2017.

El primer lugar ha mirado a las personas mayores, las tecnologías que existen desde hace más de diez años. La segunda publicación fue sobre adultos, las últimas y más maduras tecnologías. En esta publicación, analizamos las soluciones emergentes de MySQL de alta disponibilidad. Las soluciones de alta disponibilidad de MySQL “bebé” que he elegido para el blog son replicación de grupo, apoderado y almacenamiento distribuido.

replicación de grupo

La réplica del grupo es la respuesta de Oracle a Galera. El término «clúster InnoDB» significa un clúster que utiliza la replicación de grupo. El objetivo es ofrecer una funcionalidad similar, especialmente la función casi síncrona.

A primera vista, la implementación de la replicación del grupo parece bastante elegante. La base es el modo de replicación GTID. Los nodos en un clúster InnoDB comparten una sola secuencia UUID. Para controlar el retraso de la replicación, Oracle agregó una capa de control de flujo. Mientras que Galera requiere la unanimidad, la replicación del grupo requiere solo una mayoría. El protocolo mayoritario en uso se deriva de paxos. Un protocolo mayoritario hace que el clúster sea más resistente a un nodo lento.

Al igual que Galera, cuando agrega control de flujo necesita archivos. La replicación de grupo tiene dos archivos. Hay una fila para el proceso de certificación y una fila para los aplicantes. Lo interesante del enfoque de Oracle es la presencia de un mecanismo de regulación. Cuando un nodo solicita el control de flujo, en lugar de detener el proceso de nuevas transacciones como Galera, la tasa de transacción se estrangula. Eso puede ayudarlo a cumplir con los estrictos requisitos de SLA de tiempo.

Debido a que la lógica de replicación de grupos es bastante similar a la de Galera, sufren las mismas limitaciones: grandes transacciones, latencia y colas activas. La replicación del grupo es reciente. La primera versión de GA es la 5.7.17, a partir de diciembre de 2016. Entonces, es natural que tenga varios bordes afilados. No voy a entrar en demasiados detalles aquí, pero si estás interesado sigue leyendo aquí, aquí. Estoy convencido que con el tiempo la replicación del grupo será más limpia. Algo de automatización, como el proceso Galera SST, también sería bienvenido.

Dado que la tecnología es reciente, no conozco un cliente de Percona que utilice replicación grupal en producción.

apoderados

Los proxies inteligentes pueden verse como otro tipo de futura solución MySQL de alta disponibilidad. No es estrictamente MySQL. De hecho, esta solución es más que una mezcla de otras soluciones.

El principio es simple: conéctese a un proxy y el proxy lo dirigirá a un servidor MySQL válido. El proxy monitoreará el estado de los servidores back-end y posiblemente incluso tomará medidas sobre ellos. Por supuesto, la capa de proxy no debe convertirse en un único punto de falla. Debe haber más de un host proxy para la alta disponibilidad básica. Si se utiliza más de un proxy al mismo tiempo, acordarán el estado de los servidores back-end. Por ejemplo, en un clúster que utiliza la replicación asíncrona de MySQL, si los proxies no envían tráfico de escritura al mismo host, las cosas se desordenarán rápidamente.

Hay pocas maneras de lograr esto. La solución más simple es una configuración activo-pasivo donde solo un proxy está activo en un momento dado. Necesitará algo de lógica para determinar si el servidor proxy está disponible o no. Las opciones típicas utilizan herramientas como keepalived o marcapasos.

Una segunda opción es hacer que los proxies acuerden una forma determinista de identificar un nodo escritor. Por ejemplo, con un clúster basado en Galera, todo el nodo de back-end con la menor wsrep_local_index podría ser el nodo escritor.

Finalmente, los apoderados podían hablar y coordinarse. Tal enfoque es prometedor. Podría permitir que un solo proxy monitoree e informe a sus pares de los resultados. También permite acciones coordinadas en el clúster cuando se detecta una falla.

Actualmente, hay varias opciones de proxy:

  • ProxySQL: un código abierto que comprende el protocolo MySQL y puede dividir R / W, almacenamiento en caché de consultas, fragmentación, firewall de SQL, etc. nivel alfa la funcionalidad, la duplicación, apuntan a la necesidad de comunicación entre servidores proxy.
  • MaxScale: Ya no es completamente de código abierto (BSL), pero comprende el protocolo MySQL. Puede hacer split R/W, sharding, binlog serve, SQL firewalling, etc.
  • Enrutador MySQL: MySQL Router es un proxy de código abierto desarrollado por Oracle para InnoDB Cluster (replicación de grupo). Comprenda el protocolo MySQL y también admita el nuevo protocolo X. Puede dividir R / W.
  • HAProxy: HAProxy es un popular proxy TCP de código abierto. No entiendo el protocolo MySQL. Se necesitan secuencias de comandos de ayuda, que responden a solicitudes HTTP, para calcular el estado del nodo.

De estos proxies de código abierto, solo hay dos proxies comerciales conocidos. Tungsteno y EscalaArco. Ambas tecnologías son maduras y no «bebés» en términos de edad y tracción. Además de eso, también existen numerosas soluciones de equilibrio de carga basadas en hardware.

La importancia de los proxies en MySQL de alta disponibilidad ha llevado a Percona a incluir ProxySQL en las últimas versiones de Percona XtraDB Cluster. En colaboración con el mantenedor de ProxySQL, René Cannaò, se han agregado funciones para que ProxySQL conozca el estado de Percona XtraDB Cluster.

Los proxies ya se implementan a menudo en soluciones MySQL de alta disponibilidad. A menudo, los servidores proxy solo realizan un tipo de trabajo de equilibrio de carga. Comenzamos a considerar la implementación del uso de proxies para cosas más avanzadas como la división de lectura/escritura y la fragmentación.

Almacenamiento distribuido

Configuración de replicación mediante almacenamiento distribuido

Esta solución MySQL de alta disponibilidad es un proyecto que me interesa. Es justo decir que es más un «feto» que un verdadero «bebé», ya que no conozco a nadie que lo use en la producción. Puede ver esta solución como un enfoque de almacenamiento común sobre los esteroides.

La solución más sencilla requiere un clúster de Ceph de tres nodos. Los nodos también ejecutan MySQL y datadir es un dispositivo de bloqueo Ceph RBD. Los datos en Ceph se replican automáticamente en varios hosts. Esta replicación de datos integrada es un componente importante de la solución. Además, Ceph RBD admite instantáneas y clones. Un clon es una copia de todo el conjunto de datos que consume solo los datos que han cambiado (delta) en términos de almacenamiento. Nuestros tres servidores MySQL no usan tres copias completas del conjunto de datos, solo una copia completa y dos deltas. A medida que pasa el tiempo, los deltas crecen. Cuando son demasiado grandes, podemos simplemente generar nuevas instantáneas y clones y volver al primer día. Generar una nueva instantánea y un clon toma unos segundos y no es necesario que detenga MySQL.

El caso de uso obvio para el enfoque de almacenamiento distribuido es una carga de trabajo de lectura intensiva en un conjunto de datos muy grande. La configuración puede manejar muchos scripts. Cuanto mayor sea la carga de escritura, más frecuente será una instantánea refrescante. Tenga en cuenta que actualizar una instantánea de un conjunto de datos de 10 TB lleva un poco más de tiempo que actualizar un conjunto de datos de 1 GB.

Para ello, escribí un script SST para Percona XtraDB Cluster que funciona con Ceph. Hice un blog aquí. También escribí una instantánea/clon de Ceph guardar guion que puede proporcionar un esclavo de una instantánea maestra. Escribo un blog sobre cómo usar este script de guardado de Ceph en un futuro cercano.

Yendo más allá con el almacenamiento distribuido, muchas instancias de MySQL pueden usar las mismas páginas de datos. Ceph se usaría como un almacén de objetos distribuidos para las páginas de InnoDB. Esto le permitiría construir una base de datos como Aurora de código abierto. Junto con la replicación de Galería o Grupo, puede tener un clúster de MySQL de alta disponibilidad que comparte una sola copia del conjunto de datos.

Empecé a modificar MySQL, en realidad Percona Server para MySQL 5.7, para agregar soporte para Ceph/Rados. Rados es el protocolo del almacén de objetos de Ceph. También se requiere mucho esfuerzo para hacer el trabajo. Mi trabajo principal no es el desarrollo, por lo que el progreso es lento. Mi trabajo se puede encontrar (aquí). La fuente se compila con éxito, pero MySQL no se inicia por completo. Necesito depurar dónde las cosas iban mal.

Agregar una función a MySQL es una excelente manera de aprender los entresijos de MySQL. Realmente agradecería cualquier ayuda si usted está interesado en este proyecto.

Conclusiones

Con base en los tres artículos de esta serie, cubrimos el panorama de 2017 de las soluciones MySQL de alta disponibilidad. El primer foco en los antiguos, «antiguos», consiste en: replicación, almacenamiento compartido y NDB. El segundo artículo trató sobre las soluciones que son más nuevas y tienen buena tracción: Galera y RDS Aurora. La conclusión de la serie es el artículo actual, que analizó lo que podría surgir en términos de soluciones MySQL de alta disponibilidad.

El objetivo principal de esta serie es ayudarlo a planificar la implementación de MySQL de manera altamente disponible. Espero que pueda usarse para obtener consejos y trucos para obtener soluciones mejores y más efectivas.

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario