En uno de los blogs anteriores, cubrimos las nuevas características que están saliendo en MariaDB 10.4. Mencionamos allí que en esta versión se incluirá una nueva versión de Galera Cluster. En esta publicación de blog, repasaremos las funciones de Galera Cluster 26.4.0 (o Galera 4), las revisaremos rápidamente y exploraremos cómo afectarán su configuración cuando trabaje con MariaDB Galera Cluster.
Replicación de transmisión
Galera Cluster no es de ninguna manera un reemplazo directo para MySQL independiente. La forma en que funciona la certificación del conjunto de escritura introdujo varias limitaciones y casos extremos que pueden limitar seriamente la capacidad de migrar a Galera Cluster. Las tres limitaciones más comunes son...
- Problemas con transacciones largas
- Problemas con grandes transacciones
- Problemas con puntos calientes en las tablas
Lo bueno de ver es que Galera 4 presenta Streaming Replication, que puede ayudar a reducir estas limitaciones. Revisemos el estado actual con un poco más de detalle.
Transacciones de larga duración
En este caso estamos hablando de tiempos, que definitivamente son problemáticos en Galera. Lo principal que hay que entender es que Galera replica las transacciones como conjuntos de escritura. Esos conjuntos de escritura están certificados en los miembros del clúster, lo que garantiza que todos los nodos puedan aplicar un conjunto de escritura dado. El problema es que los bloqueos se crean en el nodo local, no se replican en el clúster, por lo tanto, si su transacción tarda varios minutos en completarse y si está escribiendo en más de un nodo de Galera, con el tiempo es cada vez más probable que en uno de los nodos restantes, algunas transacciones modificarán algunas de las filas actualizadas en su transacción de larga duración. Esto hará que la certificación falle y la transacción de larga duración deberá revertirse. En resumen, dado que envía escrituras a más de un nodo en el clúster, cuanto mayor sea la transacción, más probable es que falle la certificación debido a algún conflicto.
Puntos de acceso
Con eso nos referimos a las filas, que se actualizan con frecuencia. Por lo general, es una especie de contador que se actualiza una y otra vez. El culpable del problema es el mismo que en las transacciones largas:las filas se bloquean solo localmente. Nuevamente, si envía escrituras a más de un nodo, es probable que el mismo contador se modifique al mismo tiempo en más de un nodo, causando conflictos y haciendo que la certificación falle.
Para ambos problemas, hay una solución:puede enviar sus escrituras a un solo nodo en lugar de distribuirlas en todo el clúster. Puede usar proxies para eso:ClusterControl implementa HAProxy y ProxySQL, ambos se pueden configurar para que las escrituras se envíen a un solo nodo. Si no puede enviar escrituras a un solo nodo, debe aceptar que verá conflictos de certificación y reversiones de vez en cuando. En general, la aplicación debe poder manejar las reversiones desde la base de datos; no hay forma de evitarlo, pero es aún más importante cuando la aplicación funciona con Galera Cluster.
Aún así, enviar el tráfico a un nodo no es suficiente para manejar el tercer problema.
Grandes Transacciones
Lo que es importante tener en cuenta es que el conjunto de escritura se envía para su certificación solo cuando se completa la transacción. Luego, el conjunto de escritura se envía a todos los nodos y se lleva a cabo el proceso de certificación. Esto impone límites sobre el tamaño de una sola transacción, ya que Galera, al preparar el conjunto de escritura, lo almacena en el búfer en memoria. Las transacciones demasiado grandes reducirán el rendimiento del clúster. Por lo tanto, se han introducido dos variables:wsrep_max_ws_rows, que limita el número de filas por transacción (aunque se puede establecer en 0 - ilimitado) y, más importante:wsrep_max_ws_size, que se puede configurar hasta 2 GB. Por lo tanto, la transacción más grande que puede ejecutar con Galera Cluster es de hasta 2 GB de tamaño. Además, debe tener en cuenta que la certificación y la aplicación de la transacción grande también lleva tiempo, lo que crea un "retraso":lectura tras escritura, ese nodo de acceso diferente al que realizó inicialmente la transacción, lo más probable es que resulte en datos incorrectos como el la transacción aún se está aplicando.
Galera 4 viene con Streaming Replication, que se puede usar para mitigar todos esos problemas. La principal diferencia será que el conjunto de escritura ahora se puede dividir en partes; ya no será necesario esperar a que finalice toda la transacción antes de que se repliquen los datos. Esto puede hacer que se pregunte:¿cómo se vería la certificación en tal caso? En resumen, la certificación se realiza sobre la marcha:cada fragmento se certifica y todas las filas involucradas se bloquean en todos los nodos del clúster. Este es un cambio serio en la forma en que funciona Galera:hasta ahora, los bloqueos se creaban localmente, con bloqueos de replicación de transmisión que se crearán en todos los nodos. Esto ayuda en los casos que discutimos anteriormente:bloquear filas a medida que ingresan fragmentos de transacciones, ayuda a reducir la probabilidad de que la transacción tenga que revertirse. Las transacciones en conflicto ejecutadas localmente no podrán obtener los bloqueos que necesitan y tendrán que esperar a que la transacción de replicación se complete y libere los bloqueos de fila.
En el caso de los puntos de acceso, con la replicación de transmisión es posible obtener bloqueos en todos los nodos al actualizar la fila. Otras consultas que deseen actualizar la misma fila tendrán que esperar a que se libere el bloqueo antes de ejecutar sus cambios.
Las transacciones grandes se beneficiarán de la replicación de transmisión porque ya no será necesario esperar a que finalice toda la transacción ni estarán limitadas por el tamaño de la transacción:las transacciones grandes se dividirán en fragmentos. También ayuda a utilizar mejor la red:en lugar de enviar 2 GB de datos a la vez, los mismos 2 GB de datos se pueden dividir en fragmentos y enviar durante un período de tiempo más prolongado.
Hay dos opciones de configuración para la replicación de transmisión:wsrep_trx_fragment_size, que indica el tamaño que debe tener un fragmento (de manera predeterminada, se establece en 0, lo que significa que la replicación de transmisión está deshabilitada) y wsrep_trx_fragment_unit, que indica qué fragmento es realmente. Por defecto son bytes, pero también pueden ser 'declaraciones' o 'filas'. Esas variables pueden (y deben) configurarse a nivel de sesión, lo que permite al usuario decidir qué consulta en particular debe replicarse mediante la replicación de transmisión. Establecer la unidad en 'declaraciones' y el tamaño en 1 permite, por ejemplo, usar la replicación de transmisión solo para una sola consulta que, por ejemplo, actualiza un punto de acceso.
Por supuesto, existen inconvenientes al ejecutar la replicación de transmisión, principalmente debido al hecho de que ahora se bloquean todos los nodos del clúster. Si ha visto una gran transacción retroceder durante mucho tiempo, ahora dicha transacción tendrá que retroceder en todos los nodos. Obviamente, la mejor práctica es reducir el tamaño de una transacción tanto como sea posible para evitar reversiones que tarden horas en completarse. Otro inconveniente es que, por motivos de recuperación tras bloqueo, los conjuntos de escritura creados a partir de cada fragmento se almacenan en la tabla wsrep_schema.SR en todos los nodos, lo que, en cierto modo, implementa un búfer de doble escritura, lo que aumenta la carga en el clúster. Por lo tanto, debe decidir cuidadosamente qué transacción debe replicarse mediante la replicación de transmisión y, siempre que sea factible, debe seguir las mejores prácticas de tener transacciones pequeñas y cortas o dividir la transacción grande en lotes más pequeños.
Bloqueos de respaldo
Finalmente, los usuarios de MariaDB podrán beneficiarse de los bloqueos de respaldo para SST. La idea detrás de SST ejecutado usando (para MariaDB) mariabackup es que todo el conjunto de datos debe transferirse, sobre la marcha, y los registros de rehacer se recopilan en segundo plano. Luego, se debe adquirir un bloqueo global, asegurándose de que no se produzca escritura, se debe recopilar y almacenar la posición final del registro de rehacer. Históricamente, para MariaDB, la parte de bloqueo se realizaba mediante FLUSH TABLES CON READ LOCK, que cumplía su función, pero bajo una gran carga era bastante difícil de adquirir. También es bastante pesado:no solo las transacciones tienen que esperar a que se libere el bloqueo, sino que también los datos deben vaciarse en el disco. Ahora, con MariaDB 10.4, será posible usar un BLOQUEO DE RESPALDO menos intrusivo, que no requerirá que se vacíen los datos, solo se bloquearán las confirmaciones durante la duración del bloqueo. Esto debería significar operaciones SST menos intrusivas, lo que definitivamente es bueno escuchar. Todos los que tuvieron que ejecutar su Galera Cluster en modo de emergencia, en un nodo, manteniendo los dedos cruzados para que SST no afecte las operaciones del clúster, deberían estar más que felices de escuchar acerca de esta mejora.
Lecturas causales desde la aplicación
Galera 4 introdujo tres nuevas funciones destinadas a ayudar a agregar soporte para lecturas causales en las aplicaciones:WSREP_LAST_WRITTEN_GTID(), que devuelve el GTID de la última escritura realizada por el cliente, WSREP_LAST_SEEN_GTID(), que devuelve el GTID de la última transacción de escritura observada por el cliente y WSREP_SYNC_WAIT_UPTO_GTID(), que bloqueará al cliente hasta que el GTID pasado a la función se confirme en el nodo. Claro, puede aplicar lecturas causales en Galera incluso ahora, pero al utilizar esas funciones será posible implementar una lectura tras escritura segura en aquellas partes de la aplicación donde se necesita, sin necesidad de realizar cambios en la configuración de Galera.
Actualización a MariaDB Galera 10.4
Si desea probar Galera 4, está disponible en la versión candidata más reciente para MariaDB 10.4. Según la documentación de MariaDB, en este momento no hay forma de realizar una actualización en vivo de 10.3 Galera a 10.4. Debe detener todo el clúster 10.3, actualizarlo a 10.4 y luego volver a iniciarlo. Este es un bloqueador serio y esperamos que esta limitación se elimine en una de las próximas versiones. Es de suma importancia tener la opción de una actualización en vivo y para eso tanto MariaDB 10.3 como MariaDB 10.4 tendrán que coexistir en el mismo Galera Cluster. Otra opción, que también puede ser adecuada, es configurar la replicación asíncrona entre el antiguo y el nuevo Galera Cluster.
Realmente esperamos que haya disfrutado de esta breve revisión de las características de MariaDB 10.4 Galera Cluster, esperamos ver la replicación de transmisión en entornos de producción reales. También esperamos que esos cambios ayuden a aumentar aún más la adopción de Galera. Después de todo, la replicación de transmisión resuelve muchos problemas que pueden evitar que las personas migren a Galera.
