Requisitos de replicación grupal
Los datos deben almacenarse en el motor de almacenamiento de transacciones InnoDB. La transacción se ejecuta de manera optimista y luego se verifica si hay conflictos cuando se confirma. Si hay un conflicto, para mantener la consistencia de todo el grupo, algunas transacciones se revertirán, por lo que se requiere un motor de almacenamiento transaccional. Además, InnoDB también proporciona algunas características adicionales para administrar y manejar mejor los conflictos cuando se opera con la replicación de grupo. El uso de otros motores de almacenamiento (incluidos los motores de almacenamiento temporal de MEMORIA) puede provocar errores de replicación de grupo. Puede evitar el uso de otros motores de almacenamiento configurando la variable de sistema disabled_storage_engines en los miembros del grupo, por ejemplo: disabled_storage_engines = "MyISAM, BLACKHOLE, FEDERATED, ARCHIVE, MEMORY"
Cada tabla replicada por el grupo debe tener una clave principal o una clave única no vacía equivalente. Son necesarios como un identificador único para cada fila de la tabla, lo que permite al sistema determinar qué transacciones tienen conflictos identificando con precisión las filas que han sido modificadas por cada transacción.
El rendimiento de la red afectará al rendimiento del grupo, y la latencia y el ancho de banda de la red afectarán el rendimiento y la estabilidad de la replicación del grupo. Por lo tanto, las instancias del servidor MySQL en la replicación de grupo deben implementarse en un entorno de clúster muy cerca unas de otras, de modo que todos los miembros del grupo siempre mantengan una comunicación bidireccional. Si la instancia del servidor está bloqueada para enviar y recibir mensajes (por ejemplo, restringida por un firewall), el miembro no puede ejecutarse en el grupo y es posible que los miembros del grupo (incluidos los miembros problemáticos) no puedan informar el estado correcto de pertenencia de la instancia del servidor afectada. A partir de MySQL 8.0.14, puede utilizar la infraestructura de red IPv4 o IPv6, o una combinación de las dos, para la comunicación TCP entre servidores de replicación de grupos remotos.
Configure --log-bin [= log_file_name] para activar el registro binario. Esta opción está habilitada de forma predeterminada en MySQL 8. Al igual que otros métodos de replicación de MySQL, la replicación de grupo necesita replicar el contenido del registro binario, por lo que el registro binario debe estar encendido para ejecutarse.
Configure --log-slave-updates para registrar actualizaciones de esclavos. El servidor necesita registrar el registro binario aplicado por la aplicación de replicación. Los servidores del grupo deben registrar todas las transacciones que reciben y aplican del grupo. Esto es necesario porque la recuperación distribuida se basa en los registros binarios de los miembros del grupo. Por lo tanto, es necesario que exista una copia de cada transacción en cada servidor, incluso para las transacciones que no se inician en el servidor mismo. Esta opción está habilitada de forma predeterminada en MySQL 8.
Establezca --binlog-format = row para establecer el registro binario en formato de fila. La replicación de grupo se basa en un formato de replicación basado en filas para propagar los cambios de manera consistente entre los miembros del grupo. Se basa en una infraestructura basada en filas para extraer la información necesaria para detectar conflictos entre transacciones simultáneas ejecutadas por diferentes servidores del grupo.
Establezca --binlog-checksum = NONE para desactivar la verificación del registro binario. Debido a la limitación de diseño de las sumas de verificación de eventos de replicación, la replicación de grupo no puede usarlas y debe deshabilitarse.
Establezca --gtid-mode = ON para activar el identificador de transacción global. La replicación de grupo usa el identificador de transacción global para rastrear con precisión las transacciones que se han comprometido en cada instancia del servidor, de modo que pueda inferir qué transacciones del servidor pueden entrar en conflicto con transacciones que se han comprometido en otro lugar.
Establezca --master-info-repository = TABLE y --relay-log-info-repository = TABLE para almacenar el repositorio de información replicado en la tabla. Las aplicaciones de replicación necesitan escribir información de la base de datos maestra y transmitir metadatos de registro en las tablas del sistema mysql.slave_master_info y mysql.slave_relay_log_info. Esto garantiza que el complemento de replicación de grupo tenga una replicabilidad y una gestión de transacciones coherentes de los metadatos de replicación. A partir de MySQL 8.0.2, estas opciones están predeterminadas en TABLE, y a partir de MySQL 8.0.3, no se recomienda la configuración FILE.
Establezca --transaction-write-set-extract = XXHASH64, de modo que el servidor también recopile conjuntos de escritura cuando registre líneas de datos en el registro binario. El conjunto de escritura se basa en la clave principal de cada fila para identificar de forma única la fila modificada y se utiliza para detectar conflictos de transacciones. Esta opción está habilitada de forma predeterminada en MySQL 8.
Se recomienda establecer slave_parallel_workers en un valor mayor que cero para habilitar aplicaciones de replicación de múltiples subprocesos en los miembros del grupo. Se pueden especificar hasta 1024 subprocesos de aplicaciones de replicación paralela. Establezca slave_preserve_commit_order = 1 para asegurarse de que la confirmación final de la transacción paralela esté en el mismo orden que la transacción original. Esto es necesario para la replicación del grupo. Se basa en que todos los miembros del grupo reciban y apliquen transacciones confirmadas en el mismo orden para garantizar la coherencia de los datos en las transacciones paralelas. . slave_preserved_commit_order = 1 requiere la configuración de slave_parallel_type = LOGICAL_CLOCK, que especifica la estrategia utilizada para determinar qué transacciones se pueden ejecutar en paralelo en la biblioteca esclava. La configuración de slave_parallel_workers = 0 desactiva la replicación paralela y proporciona un único hilo de aplicación para la biblioteca esclava en lugar del hilo coordinador. Con esta configuración, las opciones slave_parallel_type y slave_preserve_commit_order no son válidas y se ignoran.
Límite de copia de grupo
El proceso de certificación no considera bloqueos de brechas. A menos que la aplicación se base en la semántica REPEATABLE READ, MySQL recomienda usar el nivel de aislamiento READ COMMITTED con replicación de grupo. InnoDB no usa bloqueos de brecha en READ COMMITTED. Unifica la detección de conflictos locales en InnoDB con la detección de conflictos distribuida realizada por replicación de grupos.化.
El proceso de autenticación no considera bloqueos de tabla (LOCK TABLES y UNLOCK TABLES) o bloqueos con nombre (GET_LOCK)
La replicación no admite el nivel de aislamiento SERIALIZABLE. Establecer el nivel de aislamiento de la transacción en SERIALIZABLE hará que el grupo se niegue a confirmar la transacción.
Cuando se utiliza el modo de múltiples primarios, las declaraciones de definición de datos (DDL) y las declaraciones de manipulación de datos (DML) concurrentes para el mismo objeto pero ejecutadas en diferentes servidores no son compatibles.
El modo de múltiples primarios no admite tablas con dependencias de clave externa de varios niveles, especialmente tablas con restricciones de clave externa CASCADING definidas. MySQL recomienda configurar group_replication_enforce_update_everywhere_checks = ON en la replicación de grupo en modo primario múltiple para evitar conflictos no detectados.
Cuando la replicación de grupo se ejecuta en modo de múltiples primarios, la instrucción SELECT .. FOR UPDATE puede causar un interbloqueo.
Los filtros de replicación global no se pueden usar en instancias de servidor MySQL configuradas para replicación de grupo.
Si una sola transacción es demasiado grande para replicar mensajes entre miembros del grupo a través de la red en 5 segundos, se puede sospechar que el miembro ha fallado y ser eliminado del grupo. Debido a problemas de asignación de memoria, las transacciones grandes también pueden ralentizar el sistema. Para evitar estos problemas, utilice las siguientes medidas de mitigación:
Intente limitar el tamaño de la transacción tanto como sea posible. Por ejemplo, divida el archivo utilizado con LOAD DATA en trozos más pequeños.
Utilice la variable de sistema group_replication_transaction_size_limit para especificar el tamaño máximo de transacción que recibe el grupo. Las transacciones que superen este tamaño se revertirán y no se enviarán al grupo. En MySQL 8.0, el valor predeterminado de esta variable del sistema es 150.000.000 bytes (aproximadamente 143 MB).
A partir de MySQL 8.0.13, la variable de sistema group_replication_member_expel_timeout se puede utilizar para permitir más tiempo antes de que se elimine el miembro que se sospecha que ha fallado. Puede extenderse hasta una hora después del período de detección inicial de 5 segundos.
A partir de MySQL 8.0.16, los mensajes grandes se segmentan automáticamente, lo que significa que los mensajes grandes no activarán el período de detección de 5 segundos que despierta sospechas, a menos que haya otros problemas de red en este momento. Para que el grupo de replicación use la segmentación, todos los miembros del grupo deben estar en MySQL 8.0.16 o superior, y la versión del protocolo de comunicación de replicación de grupo que usa el grupo debe permitir la segmentación. Si la versión de MySQL no admite la segmentación de mensajes, puede utilizar la variable del sistema group_replication_communication_max_message_size para ajustar el tamaño máximo del mensaje. El valor predeterminado es 10485760 bytes (10 MB), o puede desactivar la segmentación especificando un valor cero.