El esquema de la base de datos no es algo que esté escrito en piedra. Está diseñado para una aplicación dada, pero luego los requisitos pueden cambiar y generalmente cambian. Se agregan nuevos módulos y funcionalidades a la aplicación, se recopilan más datos, se realiza la refactorización del código y del modelo de datos. De ahí la necesidad de modificar el esquema de la base de datos para adaptarse a estos cambios; agregar o modificar columnas, crear nuevas tablas o particionar las grandes. Las consultas también cambian a medida que los desarrolladores agregan nuevas formas para que los usuarios interactúen con los datos:las nuevas consultas podrían usar índices nuevos y más eficientes, por lo que nos apresuramos a crearlos para brindar a la aplicación el mejor rendimiento de la base de datos.
Entonces, ¿cómo abordamos mejor un cambio de esquema? ¿Qué herramientas son útiles? ¿Cómo minimizar el impacto en una base de datos de producción? ¿Cuáles son los problemas más comunes con el diseño de esquemas? ¿Qué herramientas pueden ayudarlo a mantenerse al tanto de su esquema? En esta publicación de blog, le brindaremos una breve descripción general de cómo realizar cambios de esquema en MySQL y MariaDB. Tenga en cuenta que no discutiremos los cambios de esquema en el contexto de Galera Cluster. Ya discutimos el aislamiento total de pedidos, las actualizaciones de esquemas continuos y los consejos para minimizar el impacto de RSU en publicaciones de blog anteriores. También analizaremos sugerencias y trucos relacionados con el diseño de esquemas y cómo ClusterControl puede ayudarlo a mantenerse al tanto de todos los cambios de esquema.
Tipos de cambios de esquema
Lo primero es lo primero. Antes de profundizar en el tema, debemos entender cómo MySQL y MariaDB realizan cambios de esquema. Verá, un cambio de esquema no es igual a otro cambio de esquema.
Es posible que haya oído hablar de alteraciones en línea, alteraciones instantáneas o alteraciones en el lugar. Todo esto es el resultado del trabajo que se está realizando para minimizar el impacto de los cambios de esquema en la base de datos de producción. Históricamente, casi todos los cambios de esquema eran de bloqueo. Si ejecutó un cambio de esquema, todas las consultas comenzarán a acumularse, esperando que se complete ALTER. Obviamente, esto planteó serios problemas para las implementaciones de producción. Claro, las personas inmediatamente comienzan a buscar soluciones alternativas, y las discutiremos más adelante en este blog, ya que incluso hoy en día siguen siendo relevantes. Pero también, se comenzó a trabajar para mejorar la capacidad de MySQL para ejecutar DDL (lenguaje de definición de datos) sin mucho impacto en otras consultas.
Cambios instantáneos
A veces no es necesario tocar ningún dato en el tablespace, porque todo lo que se debe cambiar son los metadatos. Un ejemplo aquí será eliminar un índice o cambiar el nombre de una columna. Tales operaciones son rápidas y eficientes. Por lo general, su impacto es limitado. Sin embargo, no está exento de impacto. A veces, lleva un par de segundos realizar el cambio en los metadatos y dicho cambio requiere que se adquiera un bloqueo de metadatos. Este bloqueo es por tabla y puede bloquear otras operaciones que se van a ejecutar en esta tabla. Verá esto como entradas "Esperando el bloqueo de metadatos de la tabla" en la lista de procesos.
Un ejemplo de tal cambio puede ser ADD COLUMN instantáneo, introducido en MariaDB 10.3 y MySQL 8.0. Brinda la posibilidad de ejecutar este cambio de esquema bastante popular sin demora. Tanto MariaDB como Oracle decidieron incluir código de Tencent Game que permite agregar instantáneamente una nueva columna a la tabla. Esto es bajo algunas condiciones específicas; la columna debe agregarse como la última, los índices de texto completo no pueden existir en la tabla, el formato de fila no se puede comprimir; puede encontrar más información sobre cómo funciona la columna de adición instantánea en la documentación de MariaDB. Para MySQL, la única referencia oficial se puede encontrar en el blog mysqlserverteam.com, aunque existe un error para actualizar la documentación oficial.
Cambios en el lugar
Algunos de los cambios requieren la modificación de los datos en el tablespace. Dichas modificaciones se pueden realizar en los datos mismos y no es necesario crear una tabla temporal con una nueva estructura de datos. Dichos cambios, normalmente (aunque no siempre) permiten que se ejecuten otras consultas que tocan la tabla mientras se ejecuta el cambio de esquema. Un ejemplo de tal operación es agregar un nuevo índice secundario a la tabla. Esta operación tardará algún tiempo en realizarse, pero permitirá que se ejecuten DML.
Reconstrucción de tabla
Si no es posible realizar un cambio en el lugar, InnoDB creará una tabla temporal con la nueva estructura deseada. A continuación, copiará los datos existentes en la nueva tabla. Esta operación es la más costosa y es probable (aunque no siempre sucede) que bloquee los DML. Como resultado, dicho cambio de esquema es muy complicado de ejecutar en una tabla grande en un servidor independiente, sin la ayuda de herramientas externas; por lo general, no puede permitirse el lujo de tener su base de datos bloqueada durante largos minutos o incluso horas. Un ejemplo de tal operación sería cambiar el tipo de datos de la columna, por ejemplo de INT a VARCHAR.
Cambios de esquema y replicación
Ok, sabemos que InnoDB permite cambios de esquema en línea y si consultamos la documentación de MySQL, veremos que la mayoría de los cambios de esquema (al menos entre los más comunes) se pueden realizar en línea. ¿Cuál es la razón detrás de dedicar horas de desarrollo para crear herramientas de cambio de esquema en línea como gh-ost? Podemos aceptar que pt-online-schema-change es un remanente de los viejos y malos tiempos, pero gh-ost es un software nuevo.
La respuesta es compleja. Hay dos problemas principales.
Para empezar, una vez que inicia un cambio de esquema, no tiene control sobre él. Puede abortarlo pero no puede pausarlo. No puedes estrangularlo. Como puede imaginar, reconstruir la tabla es una operación costosa e incluso si InnoDB permite que se ejecuten DML, la carga de trabajo de E/S adicional del DDL afecta todas las demás consultas y no hay forma de limitar este impacto a un nivel que sea aceptable para el aplicación.
En segundo lugar, un problema aún más grave es la replicación. Si ejecuta una operación sin bloqueo, que requiere una reconstrucción de la tabla, de hecho no bloqueará los DML, pero esto solo es cierto en el maestro. Supongamos que tal DDL tardó 30 minutos en completarse:la velocidad de ALTER depende del hardware, pero es bastante común ver tales tiempos de ejecución en tablas con un rango de tamaño de 20 GB. Luego se replica a todos los esclavos y, desde el momento en que DDL se inicia en esos esclavos, la replicación esperará a que se complete. No importa si usa MySQL o MariaDB, o si tiene una replicación de subprocesos múltiples. Los esclavos se retrasarán:esperarán esos 30 minutos para que se complete el DDL antes de comenzar a aplicar los eventos binlog restantes. Como puede imaginar, 30 minutos de retraso (a veces, incluso 30 segundos no son aceptables; todo depende de la aplicación) es algo que hace imposible usar esos esclavos para el escalado horizontal. Por supuesto, existen soluciones alternativas:puede realizar cambios de esquema desde la parte inferior hasta la parte superior de la cadena de replicación, pero esto limita seriamente sus opciones. Especialmente si usa la replicación basada en filas, solo puede ejecutar cambios de esquema compatibles de esta manera. Un par de ejemplos de limitaciones de la replicación basada en filas; no puede soltar ninguna columna que no sea la última, no puede agregar una columna en una posición que no sea la última. Tampoco puede cambiar el tipo de columna (por ejemplo, INT -> VARCHAR).
Como puede ver, la replicación agrega complejidad a la forma en que puede realizar cambios de esquema. Las operaciones que no son de bloqueo en el host independiente se vuelven de bloqueo mientras se ejecutan en los esclavos. Echemos un vistazo a un par de métodos que puede usar para minimizar el impacto de los cambios de esquema.
Herramientas de cambio de esquema en línea
Como mencionamos anteriormente, existen herramientas que están destinadas a realizar cambios de esquema. Los más populares son pt-online-schema-change creado por Percona y gh-ost, creado por GitHub. En una serie de publicaciones de blog, los comparamos y discutimos cómo se puede usar gh-ost para realizar cambios de esquema y cómo puede acelerar y reconfigurar una migración en curso. Aquí no entraremos en detalles, pero aún nos gustaría mencionar algunos de los aspectos más importantes del uso de estas herramientas. Para empezar, un cambio de esquema ejecutado a través de pt-osc o gh-ost ocurrirá en todos los nodos de la base de datos a la vez. No hay demora alguna en cuanto a cuándo se aplicará el cambio. Esto hace posible usar esas herramientas incluso para cambios de esquema que son incompatibles con la replicación basada en filas. Los mecanismos exactos sobre cómo esas herramientas rastrean los cambios en la tabla son diferentes (disparadores en pt-osc versus análisis de binlog en gh-ost) pero la idea principal es la misma:se crea una nueva tabla con el esquema deseado y los datos existentes son copiado de la tabla anterior. Mientras tanto, los DML se rastrean (de una forma u otra) y se aplican a la nueva tabla. Una vez que se migran todos los datos, se cambia el nombre de las tablas y la nueva tabla reemplaza a la anterior. Esta es una operación atómica, por lo que no es visible para la aplicación. Ambas herramientas tienen una opción para acelerar la carga y pausar las operaciones. Gh-ost puede detener toda la actividad, pt-osc solo puede detener el proceso de copiar datos entre la tabla antigua y la nueva:los disparadores permanecerán activos y continuarán duplicando datos, lo que agrega algunos gastos generales. Debido a la tabla de cambio de nombre, ambas herramientas tienen algunas limitaciones con respecto a las claves foráneas:no son compatibles con gh-ost, son compatibles parcialmente con pt-osc, ya sea a través de ALTER regular, lo que puede causar un retraso en la replicación (no factible si la tabla secundaria es grande) o por eliminar la tabla anterior antes de cambiar el nombre de la nueva; es peligroso ya que no hay forma de revertir si, por alguna razón, los datos no se copiaron correctamente en la nueva tabla. Los disparadores también son difíciles de soportar.
No son compatibles con gh-ost, pt-osc en MySQL 5.7 y versiones posteriores tienen compatibilidad limitada para tablas con disparadores existentes. Otras limitaciones importantes para las herramientas de cambio de esquema en línea es que debe existir una clave principal o única en la tabla. Se utiliza para identificar filas para copiar entre tablas antiguas y nuevas. Esas herramientas también son mucho más lentas que ALTER directo:un cambio que lleva horas mientras se ejecuta ALTER puede tardar días cuando se realiza con pt-osc o gh-ost.
Por otro lado, como mencionamos, siempre que se cumplan los requisitos y las limitaciones no entren en juego, puede ejecutar todos los cambios de esquema utilizando una de las herramientas. Todo sucederá al mismo tiempo en todos los hosts, por lo que no tiene que preocuparse por la compatibilidad. También tiene cierto nivel de control sobre cómo se ejecuta el proceso (menos en pt-osc, mucho más en gh-ost).
Puede reducir el impacto del cambio de esquema, puede pausarlos y dejar que se ejecuten solo bajo supervisión, puede probar el cambio antes de realizarlo. Puede hacer que rastreen el retraso de la replicación y hagan una pausa en caso de que se detecte un impacto. Esto hace que esas herramientas sean una gran adición al arsenal del DBA mientras trabaja con la replicación de MySQL.
Cambios de esquema continuos
Por lo general, un DBA utilizará una de las herramientas de cambio de esquema en línea. Pero como discutimos anteriormente, bajo algunas circunstancias, no se pueden usar y un alter directo es la única opción viable. Si estamos hablando de MySQL independiente, no tiene otra opción:si el cambio no bloquea, está bien. Si no es así, bueno, no hay nada que puedas hacer al respecto. Pero entonces, no mucha gente ejecuta MySQL como instancias únicas, ¿verdad? ¿Qué hay de la replicación? Como discutimos anteriormente, la alteración directa en el maestro no es factible; en la mayoría de los casos, causará un retraso en el esclavo y esto puede no ser aceptable. Sin embargo, lo que se puede hacer es ejecutar el cambio de manera continua. Puede comenzar con los esclavos y, una vez aplicado el cambio en todos ellos, promover a uno de los esclavos como nuevo maestro, degradar al antiguo maestro a esclavo y ejecutar el cambio en él. Claro, el cambio tiene que ser compatible pero, a decir verdad, los casos más comunes en los que no puede usar los cambios de esquema en línea es por falta de clave principal o única. Para todos los demás casos, existe algún tipo de solución, especialmente en pt-online-schema-change ya que gh-ost tiene limitaciones más estrictas. Es una solución alternativa que llamaría "más o menos" o "lejos de ser ideal", pero hará el trabajo si no tiene otra opción para elegir. Lo que también es importante, la mayoría de las limitaciones se pueden evitar si supervisa su esquema y detecta los problemas antes de que crezca la tabla. Incluso si alguien crea una tabla sin una clave principal, no es un problema ejecutar una alteración directa que toma medio segundo o menos, ya que la tabla está casi vacía.
Si crece, se convertirá en un problema grave, pero depende del DBA detectar este tipo de problemas antes de que realmente comiencen a crear problemas. Cubriremos algunos consejos y trucos sobre cómo asegurarse de que detectará estos problemas a tiempo. También compartiremos consejos genéricos sobre cómo diseñar sus esquemas.
Consejos y trucos
Diseño del esquema
Como mostramos en esta publicación, las herramientas de cambio de esquema en línea son muy importantes cuando se trabaja con una configuración de replicación, por lo tanto, es muy importante asegurarse de que su esquema esté diseñado de tal manera que no limite sus opciones para realizar cambios de esquema. Hay tres aspectos importantes. En primer lugar, debe existir una clave primaria o única:debe asegurarse de que no haya tablas sin una clave principal en su base de datos. Debe monitorear esto regularmente, de lo contrario, puede convertirse en un problema grave en el futuro. En segundo lugar, debe considerar seriamente si usar claves externas es una buena idea. Claro, tienen sus usos, pero también agregan sobrecarga a su base de datos y pueden dificultar el uso de herramientas de cambio de esquema en línea. Las relaciones pueden ser impuestas por la aplicación. Incluso si significa más trabajo, aún puede ser una mejor idea que comenzar a usar claves foráneas y limitarse severamente a los tipos de cambios de esquema que se pueden realizar. Tercero, desencadenantes. La misma historia que con las claves foráneas. Son una buena característica, pero pueden convertirse en una carga. Debe considerar seriamente si las ganancias de usarlos superan las limitaciones que plantean.
Seguimiento de cambios en el esquema
La gestión de cambios de esquema no se trata solo de ejecutar cambios de esquema. También debe estar al tanto de la estructura de su esquema, especialmente si no es el único que realiza los cambios.
ClusterControl proporciona a los usuarios herramientas para realizar un seguimiento de algunos de los problemas de diseño de esquemas más comunes. Puede ayudarlo a realizar un seguimiento de las tablas que no tienen claves principales:
Como discutimos anteriormente, la captura temprana de tales tablas es muy importante ya que las claves principales deben agregarse mediante la modificación directa.
ClusterControl también puede ayudarlo a rastrear índices duplicados. Por lo general, no querrá tener múltiples índices que sean redundantes. En el ejemplo anterior, puede ver que hay un índice en (k, c) y también hay un índice en (k). Cualquier consulta que pueda usar el índice creado en la columna 'k' también puede usar un índice compuesto creado en las columnas (k, c). Hay casos en los que es beneficioso mantener índices redundantes, pero debe abordarlo caso por caso. A partir de MySQL 8.0, es posible probar rápidamente si realmente se necesita un índice o no. Puede hacer que un índice redundante sea "invisible" ejecutando:
ALTER TABLE sbtest.sbtest1 ALTER INDEX k_1 INVISIBLE;Esto hará que MySQL ignore ese índice y, a través de la monitorización, podrás comprobar si hubo algún impacto negativo en el rendimiento de la base de datos. Si todo funciona según lo planeado durante algún tiempo (un par de días o incluso semanas), puede planear eliminar el índice redundante. En caso de que haya detectado que algo no está bien, siempre puede volver a habilitar este índice ejecutando:
ALTER TABLE sbtest.sbtest1 ALTER INDEX k_1 VISIBLE;Esas operaciones son instantáneas y el índice está allí todo el tiempo, y aún se mantiene; solo que el optimizador no lo tendrá en cuenta. Gracias a esta opción, eliminar índices en MySQL 8.0 será una operación mucho más segura. En las versiones anteriores, volver a agregar un índice eliminado incorrectamente podría llevar horas, si no días, en tablas grandes.
ClusterControl también puede informarle sobre las tablas MyISAM.
Si bien MyISAM aún puede tener sus usos, debe tener en cuenta que no es un motor de almacenamiento transaccional. Como tal, puede introducir fácilmente inconsistencias de datos entre nodos en una configuración de replicación.
Otra característica muy útil de ClusterControl es uno de los informes operativos:un informe de cambio de esquema.
En un mundo ideal, un DBA revisa, aprueba e implementa todos los cambios de esquema. Por desgracia, este no es siempre el caso. Tal proceso de revisión simplemente no va bien con el desarrollo ágil. Además de eso, la proporción de desarrollador a DBA generalmente es bastante alta, lo que también puede convertirse en un problema, ya que los DBA tendrían dificultades para no convertirse en un cuello de botella. Es por eso que no es raro ver cambios de esquema realizados fuera del conocimiento del DBA. Sin embargo, el DBA suele ser el responsable del rendimiento y la estabilidad de la base de datos. Gracias al Informe de cambios de esquema, ahora pueden realizar un seguimiento de los cambios de esquema.
Al principio se necesita alguna configuración. En un archivo de configuración para un clúster dado (/etc/cmon.d/cmon_X.cnf), debe definir en qué host ClusterControl debe realizar un seguimiento de los cambios y qué esquemas deben verificarse.
schema_change_detection_address=10.0.0.126
schema_change_detection_databases=sbtestUna vez hecho esto, puede programar un informe para que se ejecute periódicamente. Una salida de ejemplo puede ser como la siguiente:
Como puede ver, dos tablas han cambiado desde la ejecución anterior del informe. En el primero, se ha creado un nuevo índice compuesto en las columnas (k, c). En la segunda tabla, se agregó una columna.
En la ejecución posterior, obtuvimos información sobre la nueva tabla, que se creó sin ningún índice o clave principal. Usando este tipo de información, podemos actuar fácilmente cuando sea necesario y resolver los problemas antes de que realmente comiencen a convertirse en bloqueadores.
