Preguntas y respuestas sobre el seminario web «Las 3 características principales de MySQL»

En primer lugar, quiero agradecer a todos los que asistieron a mi seminario web el 19 de diciembre de 2019 «Las 3 características principales de MySQL». El registro y las diapositivas están disponibles en la página del seminario web.

Aquí hay respuestas a las preguntas de los participantes que no pude proporcionar durante el seminario web.

P: ¿Cuándo entran en juego los registros de cancelación y rehacer? ¿Puede explicar las operaciones básicas de estos registros?

A: Estos dos son estructuras completamente diferentes.

Deshacer registros

Pertenece a una única transacción activa. Contiene información sobre cómo deshacer el último cambio en el índice agrupado, realizado por esta transacción.

Vamos a mostrarte cómo funcionan con un ejemplo.

Considere esta tabla:

Ahora abra una transacción y busque la fila de esta tabla:

En otra sesión, abrimos una nueva transacción y cambiamos la cola donde
f1=‘dentro’ a
f1=‘bar’:

Usamos el nivel de aislamiento de transacción predeterminado
REPETIBLELEER. Por tanto, la primera transacción debe recibir los mismos resultados que había visto antes del cambio y cara:

La transacción recupera los datos de los registros de deshacer porque la tabla ya se actualizó
COMPROMISO.

Los registros de deshacer se almacenan de forma predeterminada en el espacio de tabla compartido de InnoDB, pero se pueden colocar en espacios de tabla separados para una mejor gestión del espacio. Esta es la opción recomendada.

Puede encontrar más información sobre la eliminación de registros en el Manual de referencia del usuario.

En registro de rehacer

El registro de rehacer es una estructura de datos basada en disco que se utiliza durante la recuperación de fallas para corregir los datos escritos por transacciones incompletas.

fuente: 15.6.5 Registro de rehacer

Durante el funcionamiento normal, InnoDB nunca lo lee. Solo si el servidor MySQL no está firmado correctamente, InnoDB usa los registros en el registro de rehacer para corregir los datos.

¿Por qué es necesario Redo Log?

InnoDB mira los datos de los archivos en u índice de clúster. La estructura interna del índice agrupado es B-Tree. Este almacenamiento permite un acceso de lectura rápido, pero es lento para escribir porque aún necesita reequilibrar el árbol. Además, incluso si solo han cambiado los datos no indexados, llevará algún tiempo encontrar la página correcta en el disco donde se debe colocar la actualización.

Entonces, InnoDB observa inicialmente el cambio en la memoria. grupo de almacenamiento intermedio. Esto le permite devolver el éxito a la aplicación más rápido. Luego, en segundo plano, InnoDB vacía los datos del grupo de búfer al disco. Por lo tanto, en algún momento, los datos recién comprometidos podrían estar simplemente en la memoria. Sin embargo, en caso de falla, los datos en la memoria se perderán.

Por lo tanto, al mismo tiempo, también se escribe una solicitud de cambio codificada en el registro de rehacer. Tal escritura es secuencial y no hay necesidad de perder tiempo buscando la posición correcta. Entonces, esta operación es mucho más rápida que actualizar el archivo de la tabla. Sin embargo, está a salvo de fallas porque los datos ahora existen en la memoria (conjunto de datos activo) y en el disco (un registro en el registro de rehacer).

El tamaño del registro de rehacer está limitado por dos opciones:

  1. innodb_log_file_size
    1. Tamaño de archivo de registro individual
  2. innodb_log_files_in_group
    1. Número de archivos de registro

El tamaño total del registro de rehacer se puede calcular a partir de la fórmula:

¿Qué sucede si se alcanza el tamaño completo del Redo Log?

Cada registro en el registro de rehacer tiene su propio número: LSN. Normalmente, InnoDB elimina constantemente los cambios en los archivos de la tabla y vuelve a escribir los registros que esos LSN ya se lavaron de forma circular.

Sin embargo, si el tamaño combinado del registro de rehacer es demasiado pequeño para la cantidad de escrituras que recibe InnoDB a corto plazo, es posible que el registro de rehacer esté lleno antes de que InnoDB escriba los datos en los archivos de tabla. En este caso, InnoDB detiene toda actividad de escritura y ejecuta el llamado flujo agresivo. Puede leer más sobre la transmisión en el Manual de referencia del usuario.

Por lo tanto, es esencial establecer el tamaño del registro de rehacer lo suficientemente grande para que InnoDB pueda continuar con la escritura de la aplicación. Aprenda a calcular el tamaño correcto del archivo de registro de InnoDB.

P: En los casos en que InnoDB falla (larga espera hasta que se enciende el semáforo), ¿cuáles son las razones del bloqueo?

A: InnoDB utiliza semáforos para proteger y estructuras internas para uso simultáneo. Normalmente, estos semáforos se mantienen solo durante un breve período de tiempo. Entonces, si el semáforo esperó más de 600 segundos, InnoDB decidió que algo había ido terriblemente mal y colapsó el servidor. En este caso, debe hacer lo que sugiere el mensaje de error: informar un error a https://bugs.mysql.com y/o https://jira.percona.com.

Sin embargo, a veces el semáforo espera cuando finaliza la ansiada operación. Por ejemplo,
ANÁLISIS MESA en una mesa muy grande. En este caso, el servidor puede fallar sin un motivo válido. Hemos visto casos en los que incluso una aplicación de diagnóstico ha causado tal falla. se informó a PS-6113 y corregido en Percona Server para MySQL. Sin embargo, esta limitación existe en el servidor MySQL ascendente de las versiones 5.7.28 y 8.0.18.

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario