Las pruebas de lanzamiento suelen ser uno de los pasos de todo el proceso de implementación. Usted escribe el código y luego verifica cómo se comporta en un entorno de prueba y luego, finalmente, implementa el nuevo código en la producción. Las bases de datos son internas para cualquier tipo de aplicación y, por lo tanto, es importante verificar cómo los cambios relacionados con la base de datos alteran la aplicación. Es posible verificarlo de un par de formas; uno de ellos sería utilizar una réplica dedicada. Echemos un vistazo a cómo se puede hacer.
Obviamente, no desea que este proceso sea manual; debe ser parte de los procesos de CI/CD de su empresa. Según la aplicación, el entorno y los procesos exactos que tenga implementados, puede usar réplicas creadas ad hoc o réplicas que siempre forman parte del entorno de la base de datos.
La forma en que funciona Galera Cluster es que maneja los cambios de esquema de una manera específica. Es posible ejecutar un cambio de esquema en un solo nodo en el clúster, pero es complicado, ya que no admite todos los cambios de esquema posibles y afectará la producción si algo sale mal. Dicho nodo tendría que reconstruirse completamente usando SST, lo que significa que uno de los nodos restantes de Galera tendrá que actuar como donante y transferir todos sus datos a través de la red.
Una alternativa será usar una réplica o incluso un Galera Cluster adicional completo que actúe como una réplica. Obviamente, el proceso debe automatizarse para conectarlo a la tubería de desarrollo. Hay muchas maneras de hacer esto:scripts o numerosas herramientas de orquestación de infraestructura como Ansible, Chef, Puppet o Salt stack. No los describiremos en detalle, pero nos gustaría que mostraras los pasos necesarios para que todo el proceso funcione correctamente, y te dejaremos la implementación en una de las herramientas.
Automatización de pruebas de lanzamiento
En primer lugar, queremos poder implementar una nueva base de datos fácilmente. Debe aprovisionarse con los datos recientes, y esto se puede hacer de muchas maneras:puede copiar los datos de la base de datos de producción en el servidor de prueba; eso es lo más simple de hacer. Alternativamente, puede usar la copia de seguridad más reciente; este enfoque tiene beneficios adicionales de probar la restauración de la copia de seguridad. La verificación de la copia de seguridad es imprescindible en cualquier tipo de implementación seria, y la reconstrucción de las configuraciones de prueba es una excelente manera de verificar que el proceso de restauración funcione. También le ayuda a cronometrar el proceso de restauración:saber cuánto tiempo lleva restaurar su copia de seguridad ayuda a evaluar correctamente la situación en un escenario de recuperación ante desastres.
Una vez que se aprovisionan los datos en la base de datos, es posible que desee configurar ese nodo como una réplica de su clúster principal. Tiene sus pros y sus contras. Si pudiera volver a ejecutar todo su tráfico en el nodo independiente, sería perfecto; en tal caso, no es necesario configurar la replicación. Algunos de los balanceadores de carga, como ProxySQL, le permiten duplicar el tráfico y enviar su copia a otra ubicación. Por otro lado, la replicación es la siguiente mejor opción. Sí, no puede ejecutar escrituras directamente en ese nodo, lo que lo obliga a planificar cómo volverá a ejecutar las consultas, ya que el enfoque más simple de simplemente responder no funcionará. Por otro lado, todas las escrituras eventualmente se ejecutarán a través del subproceso SQL, por lo que solo tiene que planificar cómo manejar las consultas SELECT.
Según el cambio exacto, es posible que desee probar el proceso de cambio de esquema. Los cambios de esquema son bastante comunes y pueden tener un impacto grave en el rendimiento de la base de datos. Por lo tanto, es importante verificarlos antes de aplicarlos a la producción. Queremos ver el tiempo necesario para ejecutar el cambio y verificar si el cambio se puede aplicar en los nodos por separado o se requiere para realizar el cambio en toda la topología al mismo tiempo. Esto nos dirá qué proceso debemos usar para un cambio de esquema dado.
Uso de ClusterControl para mejorar la automatización de las pruebas de lanzamiento
ClusterControl viene con un conjunto de funciones que se pueden usar para ayudarlo a automatizar las pruebas de lanzamiento. Echemos un vistazo a lo que ofrece. Para que quede claro, las funciones que vamos a mostrar están disponibles de varias maneras. La forma más sencilla es usar la interfaz de usuario, pero no es necesario lo que desea hacer si tiene en mente la automatización. Hay dos formas más de hacerlo:interfaz de línea de comandos para ClusterControl y API RPC. En ambos casos, los trabajos se pueden activar desde scripts externos, lo que le permite conectarlos a sus procesos de CI/CD existentes. También le ahorrará mucho tiempo, ya que implementar el clúster puede ser solo una cuestión de ejecutar un comando en lugar de configurarlo manualmente.
Implementación del clúster de prueba
En primer lugar, ClusterControl viene con una opción para implementar un nuevo clúster y aprovisionarlo con los datos de la base de datos existente. Esta función por sí sola le permite implementar fácilmente el aprovisionamiento del servidor de ensayo.
Como puede ver, siempre que tenga una copia de seguridad creada, puede crear un nuevo clúster y aprovisionarlo utilizando los datos de la copia de seguridad:
Como podemos ver, hay un breve resumen de lo que sucederá. Si hace clic en Continuar, continuará.
Como siguiente paso, debe definir la conectividad SSH:debe estar lista antes de que ClusterControl pueda implementar los nodos.
Finalmente, debe elegir (entre otros) el proveedor, la versión y los nombres de host de los nodos que desea usar en el clúster. Eso es todo.
El comando CLI que lograría lo mismo se ve así:
s9s cluster --create --cluster-type=galera --nodes="10.0.0.156;10.0.0.157;10.0.0.158" --vendor=percona --cluster-name=PXC --provider-version=8.0 --os-user=root --os-key-file=/root/.ssh/id_rsa --backup-id=6Configuración de ProxySQL para duplicar el tráfico
Si tenemos un clúster implementado, es posible que deseemos enviarle el tráfico de producción para verificar cómo el nuevo esquema maneja el tráfico existente. Una forma de hacerlo es usando ProxySQL.
El proceso es fácil. Primero, debe agregar los nodos a ProxySQL. Deben pertenecer a un grupo de host separado que aún no esté en uso. Asegúrese de que el usuario del monitor ProxySQL pueda acceder a ellos.
Una vez que haya hecho esto y tenga todos (o algunos) sus nodos configurados en el grupo de host, puede editar las reglas de consulta y definir el Mirror Hostgroup (está disponible en las opciones avanzadas). Si desea hacerlo para todo el tráfico, probablemente desee editar todas sus reglas de consulta de esta manera. Si desea reflejar solo las consultas SELECT, debe editar las reglas de consulta adecuadas. Una vez hecho esto, su clúster de prueba debería comenzar a recibir tráfico de producción.
Implementación de un clúster como esclavo
Como discutimos anteriormente, una solución alternativa sería crear un nuevo clúster que actuará como una réplica de la configuración existente. Con tal enfoque podemos tener todas las escrituras probadas automáticamente, usando la replicación. Los SELECT se pueden probar utilizando el enfoque que describimos anteriormente:duplicar a través de ProxySQL.
La implementación de un clúster esclavo es bastante sencilla.
Seleccione el trabajo Crear clúster esclavo.
Tiene que decidir cómo quiere tener el conjunto de replicación. Puede transferir todos los datos del maestro a los nuevos nodos.
Como alternativa, puede utilizar una copia de seguridad existente para aprovisionar el nuevo clúster. Esto ayudará a reducir la carga de trabajo en el nodo maestro:en lugar de transferir todos los datos, solo se deberán transferir las transacciones que se ejecutaron entre el momento en que se creó la copia de seguridad y el momento en que se configuró la replicación.
El resto es seguir el asistente de implementación estándar, definiendo la conectividad SSH, la versión, el proveedor, los hosts, etc. Una vez implementado, verá el clúster en la lista.
La solución alternativa a la interfaz de usuario es lograr esto a través de RPC.
{
"command": "create_cluster",
"job_data": {
"cluster_name": "",
"cluster_type": "galera",
"company_id": null,
"config_template": "my.cnf.80-pxc",
"data_center": 0,
"datadir": "/var/lib/mysql",
"db_password": "pass",
"db_user": "root",
"disable_firewall": true,
"disable_selinux": true,
"enable_mysql_uninstall": true,
"generate_token": true,
"install_software": true,
"port": "3306",
"remote_cluster_id": 6,
"software_package": "",
"ssh_keyfile": "/root/.ssh/id_rsa",
"ssh_port": "22",
"ssh_user": "root",
"sudo_password": "",
"type": "mysql",
"user_id": 5,
"vendor": "percona",
"version": "8.0",
"nodes": [
{
"hostname": "10.0.0.155",
"hostname_data": "10.0.0.155",
"hostname_internal": "",
"port": "3306"
},
{
"hostname": "10.0.0.159",
"hostname_data": "10.0.0.159",
"hostname_internal": "",
"port": "3306"
},
{
"hostname": "10.0.0.160",
"hostname_data": "10.0.0.160",
"hostname_internal": "",
"port": "3306"
}
],
"with_tags": []
}
}Avanzando
Si está interesado en obtener más información sobre las formas en que puede integrar sus procesos con ClusterControl, nos gustaría señalarle la documentación, donde tenemos una sección completa sobre el desarrollo de soluciones donde ClusterControl juega un papel papel importante:
https://docs.severalnines.com/docs/clustercontrol/developer-guide/cmon-rpc/
https://docs.severalnines.com/docs/clustercontrol/user-guide-cli/
Esperamos que haya encontrado este breve blog informativo y útil. Si tiene alguna pregunta relacionada con la integración de ClusterControl en su entorno, comuníquese con nosotros y haremos todo lo posible para ayudarlo.
