Actualizar su base de datos para clústeres basados en Galera como Percona XtraDB Cluster (PXC) o MariaDB Galera Cluster puede ser un desafío, especialmente para un entorno basado en producción. No puede darse el lujo de perder el estado de su alta disponibilidad y ponerlo en riesgo.
Un procedimiento de actualización debe estar bien documentado e, idealmente, la documentación, las pruebas rigurosas y la evaluación comparativa deben realizarse antes de las actualizaciones. Lo que es más importante, la seguridad y las mejoras también deben identificarse en función del registro de cambios de la actualización de la versión de su base de datos.
Con todas las preocupaciones, la automatización ayuda a lograr un proceso de actualización más eficiente y ayuda a evitar errores humanos y mejora el RTO.
Cómo administrar el proceso de actualización del clúster PXC/MariaDB Galera
Actualizar su PXC/MariaDB Galera Cluster requiere una documentación adecuada y un flujo de proceso que enumere las cosas que se deben hacer y qué hacer en caso de que las cosas vayan mal. Eso significa que se debe diseñar un Plan de Continuidad Comercial que también cubra su Plan de Recuperación de Desastres. No puede permitirse perder su negocio en caso de problemas.
Lo habitual es comenzar primero con el entorno de prueba. El entorno de prueba debe tener exactamente la misma configuración y configuración que su entorno de producción. No puede continuar directamente con la actualización del entorno de producción, ya que no está seguro de qué efecto e impacto tendrá si las cosas no se ajustan al plan.
Trabajar con un entorno de producción es muy delicado, por lo que, en la mayoría de los casos, siempre existe una ventana de tiempo de inactividad y mantenimiento para evitar un impacto drástico.
Hay dos tipos de actualización para PCX o MariaDB Galera Cluster que debe tener en cuenta. Estas son la actualización de versión principal y la actualización de versión secundaria o, a menudo, se las denomina actualización en el lugar. Una actualización en el lugar es donde puede actualizar la versión de su base de datos a su versión secundaria más reciente utilizando los mismos datos binarios de su base de datos. No habrá cambios físicos en los datos en sí, sino solo en su base de datos binaria o en los paquetes de software subyacentes.
Actualización de PCX o MariaDB Galera Cluster a una versión principal
Actualizar a una versión principal puede ser un desafío, especialmente para un entorno de producción. Implica un tipo complejo de configuración de base de datos y características especiales integradas de PXC o MariaDB Galera Cluster. Los datos espaciotemporales, con marca de tiempo, datos de máquinas o cualquier dato multifacético son muy conservadores y sensibles a las actualizaciones. No puede aplicar una actualización local para este proceso porque se habrían realizado muchos cambios importantes. A menos que tenga datos muy pequeños o datos que consistan en idempotentes o datos que se puedan generar fácilmente, puede ser seguro hacerlo siempre que sepa que el impacto no afectará sus datos.
Si su volumen de datos es grande, entonces es mejor automatizar el proceso de actualización. Sin embargo, puede que no sea una solución ideal para automatizar toda la secuencia en el proceso de actualización porque pueden surgir problemas inesperados durante la fase de actualización principal. Lo mejor es automatizar pasos y procesos repetitivos con resultados conocidos en una actualización importante. En cualquier momento, se requiere un recurso para evaluar si el proceso de automatización es seguro para evitar interrupciones en el proceso de actualización. Las pruebas automatizadas después de la actualización son igualmente importantes y deben incluirse como parte del proceso posterior a la actualización.
Actualización de PCX o MariaDB Galera Cluster a una versión secundaria
Una actualización de versión menor denominada actualización en el lugar suele ser un enfoque más seguro para realizar un proceso de actualización. Esto se debe a que los cambios más comunes para esta versión son parches o mejoras de seguridad y exploits, errores (generalmente graves) o problemas de compatibilidad que requieren parches, especialmente si el hardware actual o el sistema operativo tenían cambios aplicados que también pueden causar que la base de datos no funcione. funcionar correctamente. Aunque el impacto por lo general se puede recuperar con un efecto mínimo, sigue siendo imprescindible que busque y lea el registro de cambios que se envió a la actualización de la versión secundaria específica.
Implementar el trabajo para realizar el proceso de actualización es un ejemplo ideal para la automatización. El flujo habitual es muy repetitivo y, en su mayoría, no causa daño a su PXC o MariaDB Galera Cluster existente. Lo que más importa es que después de la actualización, se procederá a realizar pruebas automatizadas para determinar que la instalación, la configuración, la eficiencia y la funcionalidad no se rompan.
¡Evita los fiascos! ¡Prepárate, hazlo automatizado!
Un cliente nuestro se comunicó con nosotros para pedirnos ayuda porque, después de la actualización menor de la base de datos, una función que están usando en la base de datos no funciona correctamente. Pidieron pasos y procesos sobre cómo bajar de categoría y qué tan seguro será. Sus clientes se quejaban de que su aplicación no funcionaba en absoluto, y generalizaban que no era útil.
Incluso por una falla tan pequeña, un cliente enojado podría hacer un comentario negativo sobre su producto. La lección aprendida de este escenario es que fallar en la prueba después de una actualización lleva a suponer que todas las funciones en una base de datos funcionan como se esperaba.
Suponga que tiene planes para automatizar el proceso de actualización, luego tome nota de que el tipo de proceso de automatización varía según el tipo de actualizaciones que debe realizar. Como se mencionó anteriormente, una actualización importante versus una actualización menor tiene diferentes enfoques distintos. Por lo tanto, es posible que la configuración de su autómata no se aplique a ambas actualizaciones de software de base de datos.
Automatización después del proceso de actualización
En este punto, se espera que haya realizado su proceso de actualización, idealmente, a través de la automatización. Ahora que su base de datos está lista para recibir conexiones de clientes, debe seguir con una fase de prueba rigurosa.
Ejecutar mysql_upgrade
Es muy importante y extremadamente recomendable ejecutar mysql_upgrade una vez que se haya completado el proceso de actualización. mysql_upgrade busca incompatibilidades con el servidor MySQL actualizado haciendo lo siguiente:
-
Actualiza las tablas del sistema en el esquema mysql para que pueda aprovechar nuevos privilegios o capacidades que podrían han sido agregados.
-
Actualiza el esquema de rendimiento y el esquema del sistema.
-
Examina esquemas de usuario.
mysql_upgrade determina si una tabla tiene problemas tales como incompatibilidades debido a cambios en la versión más reciente después de la actualización e intenta resolverlo reparando la tabla. De lo contrario, si falla, su prueba de automatización tendrá que fallar y no debe continuar con otra cosa. Tiene que ser investigado primero y hacer una reparación manual.
Comprobar registros de errores
Una vez que se realiza mysql_upgrade, debe verificar y verificar los errores que ocurrieron. Puede poner esto en una secuencia de comandos y verificar si hay etiquetas de "error" o "advertencia" en los registros de errores. Es muy importante determinar si existe tal. Su prueba automatizada debe tener la capacidad de detectar trampas de error, o puede esperar a que continúe una entrada del usuario si el error es mínimo o esperado; de lo contrario, detenga el proceso de actualización.
Realizar una prueba unitaria
Un entorno de base de datos TDD (Test Driven Development) es un enfoque de desarrollo de software en el que hay una serie de casos de prueba para validar y determinar si la validación es verdadera (aprobada) o falsa (falla). Algo como lo que tenemos en la siguiente captura de pantalla:
Imagen cortesía de guru99.com
Este es un tipo de prueba unitaria que ayuda a evitar errores no deseados o errores lógicos en su aplicación y en su base de datos. Recuerde, si hay datos no válidos almacenados en la base de datos, eso dañaría todos los análisis y transacciones comerciales, especialmente si se trata de cálculos financieros complejos o ecuaciones matemáticas.
Si pregunta, ¿es realmente necesario realizar una prueba unitaria después de la actualización? ¡Por supuesto que es! No necesariamente tiene que ejecutar esto en el entorno de producción. Durante las fases de prueba, es decir, al actualizar primero su control de calidad, el entorno de desarrollo/prueba, debe aplicarse en esa área. Los datos deben ser una copia exacta al menos o casi igual a su entorno de producción. Su objetivo aquí es evitar resultados no deseados y resultados lógicos definitivamente incorrectos. Por supuesto, debe cuidar bien sus datos y determinar si los resultados pasan la prueba de validación.
Si tiene la intención de continuar con su producción, hágalo. Sin embargo, no sea tan rígido como su fase de prueba aplicada en el entorno de control de calidad, desarrollo o ensayo. Esto se debe a que debe planificar su tiempo en función de la ventana de mantenimiento disponible y evitar demoras y RTO más largos.
Según mi experiencia, durante la fase de actualización, los clientes seleccionan un enfoque más rápido que será importante para determinar si dicha característica brinda el resultado correcto. Además, puede tener un script para automatizar la prueba de un conjunto de funciones lógicas comerciales o procedimientos almacenados, ya que ayuda a almacenar en caché las consultas y calentar su base de datos.
Al prepararse para la prueba unitaria de su base de datos, evite reinventar la rueda. En su lugar, eche un vistazo a las herramientas disponibles que puede elegir si es bueno para sus requisitos y necesidades. Consulte Selenium o visite este blog.
Verificar la identidad de las consultas
La herramienta más común que puede usar es pt-upgrade de Percona. Verifica que los resultados de la consulta sean idénticos en diferentes servidores. Ejecuta consultas basadas en los registros proporcionados y la conexión suministrada (o llamada DSN), luego compara los resultados e informa cualquier diferencia significativa. Ofrece más que eso como sus opciones para recopilar o analizar las consultas, como a través de tcpdump, por ejemplo.
Usar pt-upgrade es fácil. Por ejemplo, puede ejecutar con el siguiente comando:
## Comparing via slow log for the given hosts
pt-upgrade h=host1 h=host2 slow.log
## or use fingerprints, useful for debugging purposes
pt-upgrade --fingerprints --run-time=1h mysqld-slow.log h=127.0.0.1,P=5091 h=127.0.0.1,P=5517
## or with tcpdump,
tcpdump -i eth0 port 3306 -s 65535 -x -n -q -tttt \
| pt-query-digest --type tcpdump --no-report --print \
| pt-upgrade h=host1 h=host2Es una buena práctica que una vez que se haya realizado una actualización, especialmente una actualización importante, se use pt-upgrade para continuar y realizar un análisis de consultas que identifique las diferencias según los resultados. Es una buena práctica hacer esto durante la fase de prueba mientras lo hace en sus controles de calidad o en su entorno de ensayo y desarrollo para que pueda decidir si es más seguro continuar. Puede agregar esto a su herramienta de automatización y ejecutarlo como un libro de jugadas una vez que esté listo para realizar su trabajo.
¿Cómo automatizar el proceso de prueba?
En nuestros blogs anteriores, presentamos diferentes formas de automatizar sus bases de datos. Las herramientas más comunes que están de moda son estas herramientas de software de implementación IaC (Infraestructura como código). Puede usar Puppet, Chef, SaltStack o Ansible para hacer el trabajo.
Mi preferencia siempre ha sido Ansible para realizar mis pruebas automatizadas, me permite crear libros de jugadas según su rol de trabajo. Por supuesto, no puedo crear un autómata completo que haga todas las cosas porque la situación y el entorno varían. En función de los tipos de actualización proporcionados anteriormente (actualización mayor frente a menor), debe diferenciar su proceso. Incluso si es solo una actualización en el lugar, aún debe asegurarse de que sus libros de jugadas realicen el trabajo correcto.
¡ClusterControl es su amigo de automatización de bases de datos!
ClusterControl es una buena opción para realizar pruebas básicas y automatizadas. ClusterControl no es un marco para pruebas; no es una herramienta para proporcionar pruebas unitarias. Sin embargo, es una herramienta de administración y monitoreo de bases de datos que incorpora muchas implementaciones automatizadas basadas en los activadores solicitados por el usuario o administrador del software.
ClusterControl ofrece actualizaciones de versiones menores, lo que brinda comodidad a los administradores de bases de datos cuando realizan actualizaciones. También hace mysql_upgrade sobre la marcha. Por lo tanto, no necesita realizarlo manualmente. ClusterControl también detecta nuevas versiones para actualizar y recomienda los siguientes pasos a seguir. En caso de falla, la actualización no continuará.
Este es un ejemplo del trabajo de actualización menor:
Si observa detenidamente, mysql_upgrade se ejecuta correctamente. Si bien no recomienda y realiza una actualización automática del maestro, es porque no es el enfoque correcto para continuar. En ese caso, debe promocionar el nuevo esclavo y luego degradar al maestro como esclavo para realizar la actualización.
Conclusión
Lo mejor de ClusterControl es que puede incorporar la verificación de registros de errores, realizar una prueba unitaria, verificar la identidad de las consultas mediante la creación de asesores. No es difícil hacerlo. Puede consultar nuestro blog anterior Uso de ClusterControl Advisor para crear comprobaciones para SELinux y Meltdown/Spectre:primera parte. Esto ejemplifica cómo puede aprovechar y activar el siguiente trabajo una vez que se ejecuta la actualización. ClusterControl tiene alertas o alarmas integradas que pueden integrarse a sus sistemas de alerta de terceros favoritos para notificarle el estado actual de sus pruebas automatizadas.
