Xtrabackup: ¿Cómo garantizar la coherencia sin realizar una copia de seguridad de binlog?

Conocimiento: la confirmación de dos fases dentro de MySQL está diseñada para resolver el problema de coherencia del binlog y el registro de rehacer (durante la recuperación de fallos, si se descubre que el registro de rehacer de una transacción ha completado la fase de preparación, pero aún no ha completado la confirmación , luego verificará si la transacción existe en el binlog, si existe, se confirmará (si existe, se confirmará; de lo contrario, se revertirá)

Como todos sabemos, Xtrabackup realizará operaciones similares a la recuperación tras restaurar la copia de seguridad. Vuelva a colocar el contenido del registro en los datos y confirme/revierta la transacción), entonces, ¿por qué Xtrabackup no necesita hacer una copia de seguridad del archivo binlog? p> Después de pensarlo durante mucho tiempo, parece que no puedo explicarlo en una oración, así que intentaré responderlo

Fase de bloqueo global de la copia de seguridad:

.

Hay dos cosas principales que se deben garantizar aquí:

Primero, FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS es para evitar que innodb_flush_log_at_trx_commit no sea igual a 1. y los registros de rehacer no se vacían en el disco. se utiliza para obtener los bits de binlog.

La clave es que xtrabackup solo necesita garantizar la "consistencia de los datos y los bits de binlog", no la "consistencia" de los datos y los bits de binlog. El proceso de recuperación de fallas debe garantizar la "consistencia de datos y binlog", porque después de una falla, no puede haber una situación en la que la transacción se rehaga y confirme sin registrarse en el binlog. Esto causará la pérdida de datos en el repositorio. ¿Se debe considerar para la copia de seguridad?

De hecho, estos dos puntos son los mismos, es decir, garantizar que "los bits de datos y binlog sean consistentes" durante la copia de seguridad

<. p> En primer lugar, debemos saber que durante el proceso de envío de dos fases de la transacción, las tres colas de descarga, sincronización y confirmación tienen bloqueos exclusivos, y el envío de una transacción grande puede tardar unos segundos. por lo tanto, la ejecución de FTWRL está bloqueada en este momento. El bloqueo global solo se puede obtener después de que se complete el envío. Una vez obtenido el bloqueo global, la ejecución del envío se bloqueará:

Esto está garantizado. xtrabackup puede guardar datos en el mismo lugar que el binlog.

Esto garantizará que solo haya dos tipos de transacciones en el registro de rehacer respaldado por xtrabackup: transacciones que han completado su confirmación y transacciones que aún no han comenzado. para confirmar (aquellas que aún no se han confirmado). Las transacciones pueden ser vaciadas por subprocesos en segundo plano) y ninguna transacción estará en estado listo. Una cosa más: la generación de GTID y la escritura de caché binlog se realizan en la fase de vaciado de binlog. compromiso de dos fases. Combinado, esto significa que el estado de show master después de FTWRL obtendrá la posición de binlog, que solo se puede obtener completando la transacción confirmada, por lo que esto garantiza que la posición de binlog sea consistente con el binlog.

Por lo tanto, durante la recuperación de xtrabackup, no es necesario procesar las transacciones en el estado listo, ni es necesario verificar que las transacciones estén en el binlog.

Por lo tanto, el proceso de recuperación de xtrabackup no necesita procesar transacciones en estado listo, ni necesita verificar que la transacción esté en el binlog.