Streaming Replication es una nueva función que se introdujo con la versión 4.0 de Galera Cluster. Galera utiliza la replicación sincrónica en todo el clúster, pero antes de esta versión no se admitían conjuntos de escritura de más de 2 GB. Streaming Replication le permite ahora replicar grandes conjuntos de escritura, lo cual es perfecto para inserciones masivas o para cargar datos en su base de datos.
En un blog anterior, escribimos sobre el manejo de grandes transacciones con Streaming Replication y MariaDB 10.4, pero al momento de escribir este blog, Codership aún no había lanzado su versión del nuevo Galera Cluster. Sin embargo, Percona ha lanzado su versión binaria experimental de Percona XtraDB Cluster 8.0 que destaca las siguientes características...
-
Streaming Replication compatible con grandes transacciones
-
Las funciones de sincronización permiten la coordinación de acciones (wsrep_last_seen_gtid, wsrep_last_write_gtid, wsrep_sync_wait_upto_gtid)
-
Registro de errores más granular y mejorado. wsrep_debug ahora es una variable de varios valores para ayudar a controlar el registro, y los mensajes de registro se han mejorado significativamente.
-
Algunos errores de DML y DDL en un nodo de replicación pueden ignorarse o suprimirse. Use la variable wsrep_ignore_apply_errors para configurar.
-
Múltiples tablas del sistema ayudan a obtener más información sobre el estado del clúster.
-
La infraestructura wsrep de Galera 4 es más robusta que la de Galera 3. Presenta una ejecución de código más rápida con mejor manejo de estado, previsibilidad mejorada y manejo de errores.
¿Qué hay de nuevo en Galera Cluster 4.0?
La nueva función de replicación de transmisión
Con Streaming Replication, las transacciones se replican gradualmente en pequeños fragmentos durante el procesamiento de la transacción (es decir, antes de la confirmación real, replicamos una cantidad de fragmentos de tamaño pequeño). Luego, los fragmentos replicados se aplican en subprocesos esclavos, preservando el estado de la transacción en todos los nodos del clúster. Los fragmentos mantienen bloqueos en todos los nodos y no pueden entrar en conflicto más adelante.
Tablas del sistema Galera
Los administradores de la base de datos y los clientes con acceso a la base de datos MySQL pueden leer estas tablas, pero no pueden modificarlas, ya que la base de datos misma hará las modificaciones necesarias. Si su servidor no tiene estas tablas, es posible que su servidor esté usando una versión anterior de Galera Cluster.
#> show tables from mysql like 'wsrep%';
+--------------------------+
| Tables_in_mysql (wsrep%) |
+--------------------------+
| wsrep_cluster |
| wsrep_cluster_members |
| wsrep_streaming_log |
+--------------------------+
3 rows in set (0.12 sec)Nuevas funciones de sincronización
Esta versión presenta una serie de funciones SQL para usar en operaciones de sincronización de wsrep. Puede usarlos para obtener el ID de transacción global que se basa en la última transacción escrita o en la última vista. También puede configurar el nodo para que espere a que se replique y se aplique un GTID específico antes de iniciar la siguiente transacción.
Selección inteligente de donantes
Algunas de las características discretas que han estado presentes desde Galera 3.x incluyen la selección inteligente de donantes y la recuperación de fallas del clúster. Estos se planificaron originalmente para Galera 4, pero llegaron a versiones anteriores en gran parte debido a los requisitos del cliente. Cuando se trata de la selección de nodos donantes en Galera 3, el donante State Snapshot Transfer (SST) se seleccionó al azar. Sin embargo, con Galera 4, obtiene una opción mucho más inteligente cuando se trata de elegir un donante, ya que favorecerá a un donante que pueda proporcionar una Transferencia de estado incremental (IST) o elegirá un donante en el mismo segmento. Como administrador de la base de datos, puede forzar esto configurando wsrep_sst_donor.
¿Por qué usar la replicación de secuencias de MySQL Galera Cluster?
Transacciones de larga duración
Los problemas y las limitaciones de Galera siempre giraban en torno a cómo manejaba las transacciones de ejecución prolongada y, a menudo, causaba que todo el clúster se ralentizara debido a la replicación de grandes conjuntos de escritura. Su control de flujo a menudo aumenta, lo que hace que las escrituras se ralenticen o incluso finalicen el proceso para que el clúster vuelva a su estado normal. Este es un problema bastante común con las versiones anteriores de Galera Cluster.
Codership recomienda utilizar Streaming Replication para sus transacciones de ejecución prolongada para mitigar estas situaciones. Una vez que el nodo replica y certifica un fragmento, ya no es posible que otras transacciones lo anulen.
Grandes Transacciones
Esto es muy útil al cargar datos en su informe o análisis. La creación de inserciones masivas, eliminaciones, actualizaciones o el uso de la declaración LOAD DATA para cargar una gran cantidad de datos puede caer en esta categoría. Aunque depende de cómo administre sus datos para recuperarlos o almacenarlos. Debe tener en cuenta que Streaming Replication tiene sus limitaciones, de modo que las claves de certificación se generan a partir de bloqueos de registros.
Sin Streaming Replication, la actualización de una gran cantidad de registros generaría un conflicto y toda la transacción tendría que revertirse. Los esclavos que también replican grandes transacciones están sujetos al control de flujo cuando alcanza el umbral y comienza a ralentizar todo el clúster para procesar cualquier escritura, ya que tienden a relajarse al recibir transacciones entrantes de la replicación síncrona. Galera relajará la replicación hasta que el conjunto de escritura sea manejable, ya que permite continuar con la replicación nuevamente. Consulte este blog externo de Percona para ayudarlo a comprender más sobre el control de flujo dentro de Galera.
Con Streaming Replication, el nodo comienza a replicar los datos con cada fragmento de transacción, en lugar de esperar la confirmación. Esto significa que no hay forma de que se anulen las transacciones en conflicto que se ejecutan dentro de los otros nodos, ya que esto simplemente afirma que el clúster ha certificado el conjunto de escritura para este fragmento en particular. Es gratis aplicar y confirmar otras transacciones simultáneas sin bloquear y procesar transacciones grandes con un impacto mínimo en el clúster.
Registros calientes/puntos calientes
Registros o filas calientes son aquellas filas en su tabla que se actualizan constantemente. Estos datos pueden ser los más visitados y obtienen mucho tráfico de toda su base de datos (por ejemplo, fuentes de noticias, un contador como el número de visitas o registros). Con Streaming Replication, puede forzar actualizaciones críticas en todo el clúster.
Como señaló el equipo de Galera en Codership
“Ejecutar una transacción de esta manera bloquea efectivamente el registro activo en todos los nodos, evitando que otras transacciones modifiquen la fila. También aumenta las posibilidades de que la transacción se comprometa con éxito y que el cliente, a su vez, reciba el resultado deseado”.
Esto viene con limitaciones, ya que podría no ser persistente y consistente para que tenga confirmaciones exitosas. Sin usar Streaming Replication, terminará con grandes posibilidades o reversiones y eso podría agregar una sobrecarga al usuario final cuando experimente este problema en la perspectiva de la aplicación.
Cosas a tener en cuenta al usar la replicación de transmisión
- Las claves de certificación se generan a partir de bloqueos de registros, por lo tanto, no cubren los bloqueos de intervalos ni los bloqueos de claves siguientes. Si la transacción toma un bloqueo de brecha, es posible que una transacción, que se ejecuta en otro nodo, aplique un conjunto de escritura que encuentre el registro de brecha y anule la transacción de transmisión.
- Al habilitar Streaming Replication, los registros del conjunto de escritura se escriben en la tabla wsrep_streaming_log que se encuentra en la base de datos del sistema mysql para preservar la persistencia en caso de que se produzca un bloqueo, por lo que esta tabla sirve para la recuperación. En caso de registro excesivo y sobrecarga de replicación elevada, la replicación de transmisión provocará una tasa de rendimiento de transacción degradada. Esto podría ser un cuello de botella en el rendimiento cuando se alcanza una carga máxima alta. Como tal, se recomienda que solo habilite Streaming Replication a nivel de sesión y solo para transacciones que no se ejecutarían correctamente sin ella.
- El mejor caso de uso es usar la replicación de transmisión para cortar transacciones grandes
- Establezca el tamaño del fragmento en ~10 000 filas
- Las variables de fragmento son variables de sesión y se pueden configurar dinámicamente
- La aplicación inteligente puede activar/desactivar la replicación de transmisión según sea necesario
Conclusión
Gracias por leer, en la segunda parte discutiremos cómo habilitar la replicación de flujo de clúster de Galera y cómo podrían verse los resultados para su configuración.
