MySQL Galera Cluster 4.0 es el nuevo chico en el bloque de base de datos con características nuevas muy interesantes. Actualmente está disponible solo como parte de MariaDB 10.4, pero en el futuro también funcionará con MySQL 5.6, 5.7 y 8.0. En esta publicación de blog, nos gustaría repasar algunas de las nuevas funciones que se incluyeron con Galera Cluster 4.0.
Replicación de streaming de clúster de Galera
La característica nueva más importante de esta versión es la replicación de transmisión. Hasta ahora, el proceso de certificación para Galera Cluster funcionó de manera que las transacciones completas debían certificarse una vez completadas.
Este proceso no fue ideal en varios escenarios...
- Puntos de acceso en tablas, filas que se actualizan con mucha frecuencia en varios nodos - Cientos de transacciones rápidas que se ejecutan en múltiples nodos, la modificación del mismo conjunto de filas da como resultado bloqueos frecuentes y reversión de transacciones
- Transacciones de larga duración - si una transacción tarda un tiempo significativo en completarse, esto aumenta seriamente las posibilidades de que alguna otra transacción, mientras tanto, en otro nodo, pueda modificar algunas de las filas que también fueron actualizadas por la transacción larga. Esto resultó en un punto muerto durante la certificación y una de las transacciones tuvo que revertirse.
- Grandes transacciones - si una transacción modifica un número significativo de filas, es probable que otra transacción, al mismo tiempo, en un nodo diferente, modifique una de las filas ya modificadas por la transacción grande. Esto da como resultado un interbloqueo durante la certificación y una de las transacciones debe revertirse. Además de esto, las transacciones grandes requerirán un tiempo adicional para ser procesadas, enviadas a todos los nodos del clúster y certificadas. Esta no es una situación ideal, ya que agrega demoras a las confirmaciones y ralentiza todo el clúster.
Afortunadamente, la replicación de transmisión puede resolver estos problemas. La principal diferencia es que la certificación ocurre en partes donde no hay necesidad de esperar a que se complete toda la transacción. Como resultado, incluso si una transacción es grande o larga, la mayoría (o todas, según la configuración que discutiremos en un momento) de las filas se bloquean en todos los nodos, lo que impide que otras consultas las modifiquen.
Opciones de replicación de secuencias de MySQL Galera Cluster
Hay dos opciones de configuración para la replicación de transmisión:
wsrep_trx_fragment_size
Esto indica qué tan grande debe ser un fragmento (de manera predeterminada, está configurado en 0, lo que significa que la replicación de transmisión está deshabilitada)
wsrep_trx_fragment_unit
Esto dice qué es realmente el fragmento. 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.
Puede configurar Galera 4.0 para certificar cada fila que haya modificado y tomar los bloqueos en todos los nodos mientras lo hace. Esto hace que la replicación de transmisión sea excelente para resolver problemas con interbloqueos frecuentes que, antes de Galera 4.0, solo se podían resolver redirigiendo todas las escrituras a un solo nodo.
Tablas WSREP
Galera 4.0 presenta varias tablas, que ayudarán a monitorear el estado del clúster:
- clúster_wsrep
- wsrep_cluster_members
- wsrep_streaming_log
Todos ellos están ubicados en el esquema 'mysql'. wsrep_cluster proporcionará información sobre el estado del clúster. wsrep_cluster_members le dará información sobre los nodos que forman parte del clúster. wsrep_streaming_log ayuda a rastrear el estado de la replicación de transmisión.
Próximas características del clúster de Galera
Codership, la compañía detrás de Galera, aún no ha terminado. Pudimos obtener una vista previa de la hoja de ruta del CEO, Seppo Jaakola, que se presentó en Percona Live a principios de este año. Aparentemente, vamos a ver características como el soporte de transacciones XA y el cifrado gcache. Esta es una muy buena noticia.
El soporte para transacciones XA será posible gracias a la replicación de transmisión. En resumen, las transacciones XA son las transacciones distribuidas que pueden ejecutarse en múltiples nodos. Utilizan confirmación de dos fases, que requiere adquirir primero todos los bloqueos necesarios para ejecutar la transacción en todos los nodos y luego, una vez que se realiza, confirmar los cambios. En versiones anteriores, Galera no tenía medios para bloquear recursos en nodos remotos, con la replicación de transmisión esto ha cambiado.
Gcache es un archivo que almacena conjuntos de escritura. Su contenido se envía a los nodos de unión que solicitan una transferencia de datos. Si todos los datos se almacenan en el gcache, el ensamblador recibirá solo las transacciones que faltan en el proceso llamado Transferencia de estado incremental (IST). Si gcache no contiene todos los datos requeridos, se requerirá la transferencia de instantáneas de estado (SST) y todo el conjunto de datos deberá transferirse al nodo de unión.
Gcache contiene información sobre cambios recientes, por lo tanto, es genial ver su contenido encriptado para mayor seguridad. Con la introducción de mejores estándares de seguridad a través de más y más regulaciones, es crucial que el software sea mejor para lograr el cumplimiento.
Conclusión
Definitivamente esperamos ver cómo funcionará Galera Cluster 4.0 en bases de datos distintas a MariaDB. Poder implementar MySQL 5.7 u 8.0 con Galera Cluster será realmente genial. Después de todo, Galera es una de las soluciones de replicación síncrona más probadas que hay disponibles en el mercado.
