¿Cómo podemos hacer que MySQL vuelva a ser excelente o actualizar MySQL con Orchestrator?

En esta publicación de blog, analizamos la actualización de MySQL con Orchestrator.

Hace poco tuve un cliente, Vida 360, que querían actualizar de Percona Server 5.5 a Percona Server 5.6 e implementar GTID en su entorno de transacciones de alto nivel. Tenían co-maestros y varios esclavos lectores.

Orchestrator nos ha facilitado mucho este trabajo. Mi colega, Tibi, publicó recientemente en Orchestrator aquí y aquí.

Daniel de Life360 vio a Orchestrator y se interesó mucho. Así es como instaló Orchestrator en sus propias palabras:

Hice una prueba inicial con las cajas extraviadas proporcionadas en él. Repo del orquestadorpara ver cómo configurar el agentes y usar el servidor de Orchestrator para hacer lo que queramos.

Luego pasé a instalar el servidor de Orchestrator, el backend de Orchestrator en RDS y a implementar clientes en esclavos y maestros en nuestros casos MySQL de Amazon VPC.

Una vez que se realizó la instalación del servidor, los clientes se detectaron automáticamente a través del descubrimiento CNAME de los maestros y los agentes hablaron con el servidor (tardó un tiempo ya que CNAMES no funcionó como se esperaba, pero esto se solucionó en la nueva versión) del servidor).

Nos sorprendió mucho la cantidad de acciones que puede realizar a través del propio orquestador, como: transferir esclavos a un maestro diferente arrastrando y soltando, activando GTID en un nodo con solo presionar un botón, configurando una conmutación por error basada en GTID, tomar LVM. instantáneas con el agente orquestador, etc.

Seguimos adelante y probamos el cambio maestro en arrastrar y soltar, y después de algunos intentos exitosos, incluso lo llevamos a donde estaba inicialmente. Después de estas pruebas, estábamos lo suficientemente seguros de que podíamos usar Orchestrator como una de nuestras principales herramientas para ayudar con la próxima actualización.

Aquí hay una captura de pantalla de la configuración inicial:

imagen 02

Manjot: Una vez que Daniel tuvo la configuración de Orchestrator, quiso aprovechar para ayudar con la actualización de MySQL. Decidimos crear un plan que funcionara dentro de sus limitaciones y siempre teniendo en cuenta las mejores prácticas.

Primero, instalamos Percona Server 5.6 nuevo en nuestro esclavo de seguridad dedicado. Ese primer esclavo 5.6 se creó con MyDumper para obtener compatibilidad avanzada y sin espacio de tabla heredado. Dado que MyDumper ya estaba instalado con el servicio de respaldo de Percona que tiene Life360, esto fue bastante fácil de hacer.

La reconstrucción del esclavo MyDumper funciona de la siguiente manera:

Para realizar una copia de seguridad de mydumper:

  1. Vaya a la carpeta de copia de seguridad deseada
  2. Instale mydumper (sudo apt-get install mydumper)
  3. mydumper -t 8 -L mydumper.log –comprimir

Para restaurar:

  1. Asegúrese de que MyDumper esté instalado: sudo apt-get install mydumper
  2. Copie las copias de seguridad de MyDumper en una copia de seguridad de directorio
  3. Exporte su BACKUP_DIR como env var
  4. Haga esto para restaurar con MyLoader (desde https://gist.github.com/Dnile/4658b338d4a101cbe2eeb5080ebddf8e):

Una vez que se capturó el primer esclavo 5.6, usamos Xtrabackup para la copia de seguridad 5.6 y luego restauramos a cada esclavo, pasando por el grupo de esclavos leyendo uno a la vez.

Una vez que se han actualizado todos los esclavos, creamos un nuevo maestro 5.6 y lo replicamos fuera de nuestro maestro principal 5.5.

Luego movimos todos los esclavos para replicar el nuevo maestro 5.6.

Life360 tenía los trabajos cron largos ejecutándose en el segundo maestro 5.5. Movimos la aplicación cron para escribir a maestro primario 5.5 y cerramos todas las tablas. Luego firmamos la respuesta en el segundo co-profesor. Daniel firmó MySQL y lo desmanteló.

Luego movimos todas las aplicaciones escritas al nuevo maestro 5.6. Si bien Orchestrator puede usar scripts externos para mover direcciones IP, aquí usamos un proceso manual para cambiar los DSN de la aplicación y la configuración de HAProxy.

En el maestro 5.5 restante, usamos Orchestrator para configurarlo solo para lectura.

imagen 01

Daniel dice que esto no sirvió de mucho para eliminar las conexiones que aún estaban abiertas en este servidor.

En el nuevo maestro, usamos la parada del esclavo y restablecimos los botones del esclavo en el panel del orquestador para que el maestro anterior ya no lo esclavice.

Una vez que algunas de las miles de conexiones se movieron al nuevo maestro, firmamos MySQL en el Maestro 5.5, que se encargó del resto y la aplicación se volvió a conectar «con gracia» al nuevo Maestro 5.6.

Ha habido algún tiempo de anotación desde que algunas conexiones no colapsaron hasta que se cerraron porque php-fpm se negó a dejarlas ir. También hay siempre un alto volumen de transacciones en este entorno.

En este punto, nuestra topología se ve así (ignore los íconos de globo por ahora):

imagen 00

Pero como siempre Daniel quería MOAR. Era el momento de GTID. Si bien es posible que hayamos hecho esto durante la actualización, Life360 quería administrar el riesgo y no realizar demasiados cambios de producción a la vez.

Seguimos la guía de Percona, Implementación de GTID en línea, pero usamos Orchestrator para mezclar maestros antiguos y nuevos y deshabilitar la activación y desactivación de solo lectura. Esto hizo que nuestro trabajo fuera mucho más fácil y rápido, y nos salvó de cualquier tiempo de inactividad.

Los globos en la captura de pantalla de topología anterior muestran que los esclavos ahora usan la replicación GTID.

Orchestrator hace que las actualizaciones y los cambios sean mucho más fáciles que antes, solo tenga cuidado y comprenda lo que está haciendo en segundo plano.

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