Preguntas de la entrevista de MySQL - registro

Tabla de contenido

1. ¿Cuáles son los registros comunes en MySQL?

2. ¿Para qué sirven los registros de consultas lentas?

3. ¿Qué registra principalmente binlog?

4. ¿Cuántos formatos de entrada tiene mysql binlog? ¿Cual es la diferencia?

5. ¿Cómo garantiza el registro de rehacer la durabilidad de las transacciones?

6. ¿Por qué no simplemente actualizar el disco después de modificar la página?

7. ¿Cuál es la diferencia entre binlog y redolog?

8. ¿Cómo restaurar la base de datos al estado de cualquier segundo dentro de medio mes?

9. ¿Cómo aseguran redo log y binglog la coherencia lógica entre los dos registros?

10. ¿Cómo garantiza el registro de deshacer la atomicidad de las transacciones?

---

1. ¿Cuáles son los registros comunes en MySQL?

1. registro de rehacer: registro de rehacer, utilizado para restaurar datos, para garantizar la integridad de los datos después del tiempo de inactividad anormal de MySQL, solo registre el registro físico (el registro registra la modificación de la página de datos, no la modificación lógica), escritura circular, porque no es necesario devolver Roll, por lo que puede sobrescribir.

2. registro de deshacer: el registro de deshacer, utilizado para revertir transacciones, puede garantizar la atomicidad, la consistencia y el aislamiento de las transacciones. Registre el registro lógico, escriba circularmente y registre el valor antes de la operación de transacción, lo cual es conveniente para revertir la transacción.

3. binlog: registro binario, que registra todas las operaciones que modifican la base de datos, incluidas operaciones como adición, eliminación y modificación, y se utiliza en escenarios como la recuperación y replicación de datos.

4. registro de errores: Registro de errores, que registra errores, advertencias y otra información que ocurre durante la ejecución del motor MySQL, y se utiliza para la resolución de problemas.

5. registro de consultas lentas: registro de consultas lentas, que registra sentencias SQL cuyo tiempo de ejecución supera el umbral, y se utiliza en el ajuste del rendimiento, la optimización de consultas y otros escenarios.

6. registro general: registro general, que registra todas las consultas de los clientes y la información de cambio de estado, incluidas las operaciones de consulta, conexión, desconexión y otras, y generalmente se utiliza para el diagnóstico de problemas y la auditoría de seguridad.

7. Registro de retransmisión: registro de retransmisión, utilizado para la transmisión de datos en la replicación maestro-esclavo de MySQL, copiando datos del nodo maestro de MySQL al nodo esclavo.

2. ¿Para qué sirven los registros de consultas lentas?

El registro de consultas lentas es un registro que se utiliza en MySQL para registrar sentencias SQL cuyo tiempo de ejecución supera el umbral y, por lo general, se utiliza para analizar problemas de rendimiento. Puede registrar cada instrucción SQL cuyo tiempo de ejecución supere el umbral especificado y registrar información como el tiempo de ejecución, las tablas a las que se accede, los índices utilizados y los usuarios que ejecutan SQL, para ayudar a los desarrolladores a encontrar la causa de las consultas lentas y optimizar las soluciones.

Los registros de consultas lentas pueden ayudar a los desarrolladores a identificar qué sentencias SQL tardan más en ejecutarse, de modo que se pueda realizar una optimización dirigida. Los métodos de optimización incluyen, entre otros, optimizar la escritura de declaraciones de consulta, agregar índices, separar tablas grandes, etc. Al analizar los registros de consultas lentas, los desarrolladores pueden obtener una comprensión más profunda de los cuellos de botella del sistema y los problemas de rendimiento, a fin de formular mejores estrategias de optimización.

El registro de consultas lentas se puede activar y desactivar configurando parámetros slow_query_logy long_query_time. Entre ellos, slow_query_logel parámetro se usa para habilitar o deshabilitar la función de registro de consultas lentas, y long_query_timeel parámetro se usa para establecer la instrucción SQL cuyo tiempo de ejecución excede la cantidad de segundos que se registrarán en el registro de consultas lentas.

3. ¿Qué registra principalmente binlog?

binlog (registro binario) es un archivo de registro de MySQL, que registra todas las operaciones de modificación de los datos, incluida la adición, eliminación y modificación de la base de datos. Es una característica importante de MySQL y la base para la replicación, recuperación y seguridad de datos.

Binlog registra principalmente los siguientes tipos de información:

        1. Operaciones de adición, eliminación y modificación de la base de datos

        Binlog registra todas las adiciones, eliminaciones y modificaciones a la base de datos, incluidas las modificaciones a la estructura de la tabla. En cada operación de escritura, MySQL escribirá los datos de la operación en el binlog.

        2. Información de compromiso y reversión de transacciones

        Cuando se confirma una transacción, MySQL escribirá la información de confirmación de la transacción en binlog. Si se revierte una transacción, MySQL también escribirá la información de reversión en el binlog, y la información registrada en el binlog en este momento se puede usar para la recuperación de datos.

        3. Información de estado de la base de datos

El binlog registra la información de estado de MySQL, incluida la versión de MySQL, la ID del servidor y la ID del hilo ejecutado.

Escenarios de uso de binlog:

1. Replicación de datos: la replicación maestro-esclavo de MySQL se implementa a través de binlog. La biblioteca maestra escribe la operación de modificación en el binlog y la biblioteca esclava replica leyendo el archivo binlog de la biblioteca maestra.

2. Recuperación de datos: todas las modificaciones a la base de datos se registran en el binlog, por lo que el binlog se puede utilizar para la recuperación de datos.

3. Copia de seguridad de datos: al hacer una copia de seguridad del archivo binlog, el estado de los datos en un momento determinado se puede restaurar cuando sea necesario.

Cabe señalar que binlog registra la operación de modificación de la sentencia SQL, no la modificación a nivel de fila. Por lo tanto, al restaurar datos, si hay un método de modificación que usa declaraciones que no son SQL, como la modificación directa de archivos, no se puede restaurar a través de binlog.

4. ¿Cuántos formatos de entrada tiene mysql binlog? ¿Cual es la diferencia?

El binlog de MySQL tiene tres formatos: instrucción, fila y mixto.

• formato de sentencia: los registros son sentencias SQL. Las declaraciones de SQL ejecutadas en la biblioteca maestra se registrarán en el registro binario y las declaraciones de SQL se reproducirán en la biblioteca esclava para lograr la replicación maestro-esclavo. Este formato es relativamente simple y es adecuado para escenarios con un volumen de datos pequeño y operaciones de escritura simples.
• Formato de fila: registra los cambios de filas. Cada operación de escritura a nivel de fila realizada en la biblioteca maestra se registrará en el binlog y la fila correspondiente se modificará en la biblioteca esclava para lograr la replicación maestro-esclavo. Este formato es relativamente complejo, pero es adecuado para escenarios con una gran cantidad de datos y operaciones de escritura frecuentes.
• Formato mixto: Los dos formatos de declaración y fila se mezclan. MySQL elegirá qué formato usar de acuerdo con la operación específica. Este formato puede tener en cuenta las ventajas de los dos formatos anteriores, pero es más complicado de implementar.

5. ¿Cómo garantiza el registro de rehacer la durabilidad de las transacciones?

En MySQL, el registro de redo se usa principalmente para asegurar la persistencia de las transacciones, y su implementación es la siguiente:

Cuando se confirma una transacción, el motor InnoDB primero almacenará en caché el registro de rehacer de la transacción en el búfer de registro de redo en la memoria y actualizará la página de datos correspondiente en la memoria al mismo tiempo; luego, en el momento apropiado, el registro de redo en el búfer de registro de rehacer Escriba en el archivo de registro de rehacer en el disco para garantizar que la transacción se pueda recuperar a través del registro de rehacer en situaciones anormales, como bloqueos.

Al escribir en el disco, MySQL escribirá el archivo de registro de rehacer en una cola circular que consta de dos archivos. El tamaño de cada archivo se innodb_log_file_sizecontrola y el valor predeterminado es 48 MB. Al escribir, comenzará a escribir desde el primer archivo en orden hasta que esté lleno, y luego continuará escribiendo en el siguiente archivo.

Debido a que el registro de rehacer se escribe en el disco secuencialmente, puede mejorar la eficiencia de escritura en el disco. Al mismo tiempo, el registro de rehacer adopta un método de cola circular, que puede sobrescribir y ahorrar espacio en disco.

El registro de rehacer de InnoDB tiene un tamaño fijo, por ejemplo, se puede configurar como un conjunto de 4 archivos, cada uno con un tamaño de 1 GB.

La posición de escritura es la posición del registro actual. Se mueve hacia atrás mientras se escribe y vuelve al principio del archivo 0 después de escribir al final del archivo No. 3. El punto de control es la posición actual que se va a borrar, y también se mueve hacia atrás y cíclicamente.Antes de borrar el registro, el registro debe actualizarse en el archivo de datos.

Entre write pos y checkpoint está la parte del "tablero rosa" que aún está vacía, que se puede usar para registrar nuevas operaciones. Si el pos de escritura alcanza el punto de control, significa que el "tablero rosa" está lleno y no se pueden realizar nuevas actualizaciones en este momento. Primero debe detenerse y borrar algunos registros y avanzar el punto de control.

Con el registro de rehacer, InnoDB puede garantizar que incluso si la base de datos se reinicia de forma anormal, los registros enviados anteriormente no se perderán .

6. ¿Por qué no simplemente actualizar el disco después de modificar la página?

En una base de datos, modificar datos se refiere a modificar páginas de datos en la memoria, en lugar de modificar directamente archivos de datos en el disco. La razón principal de esto es mejorar el rendimiento de escritura y garantizar la coherencia de los datos.

Si escribe directamente en el disco cada vez que hay una operación de modificación, afectará seriamente el rendimiento de escritura. Además, las escrituras frecuentes en el disco pueden acortar la vida útil del disco. Además, escribir modificaciones directamente en el disco puede generar inconsistencias en los datos, como en el caso de errores o interrupciones del sistema operativo o del hardware.

Por lo tanto, las bases de datos suelen utilizar una tecnología denominada "Registro de escritura anticipada (WAL)" para registrar las modificaciones de los datos en los archivos de registro. Antes de escribir en el disco, la operación de modificación se registrará en el registro de rehacer para garantizar la persistencia y atomicidad de la transacción. Solo cuando se confirma la transacción, la operación de modificación en el registro de rehacer se sincronizará con el archivo de datos en el disco, de modo que se pueda garantizar la consistencia y durabilidad de los datos.

Cuando el sistema falla o se reinicia, los archivos de datos se pueden recuperar a través de la reproducción del registro de rehacer. Esto se debe a que, en la base de datos, cuando se confirma una transacción, los datos del registro de rehacer se escribirán primero en el archivo de datos del disco y, luego, el identificador de la confirmación de la transacción se escribirá en el registro de redo. Por lo tanto, cuando se inicia la base de datos, solo necesita reproducir las operaciones en el registro de rehacer para restaurar los datos al estado más reciente.

7. ¿Cuál es la diferencia entre binlog y redolog?

1. Redo log (redo log) es un registro implementado por el propio motor de almacenamiento InnoDB para garantizar la durabilidad de las transacciones. Cuando los datos en la tabla InnoDB se modifican durante la ejecución de la transacción, InnoDB primero registrará la operación de modificación en el registro de rehacer y actualizará la página de datos en la memoria. Antes de que se confirme la transacción, InnoDB escribirá el registro de rehacer en el disco para garantizar la persistencia de los datos. El registro de rehacer se escribe en el disco de forma circular y se puede reutilizar. El tamaño del registro de rehacer es fijo y se puede establecer innodb_log_file_sizemediante .

2. Binlog (registro de archivo) es un registro implementado por la capa de servicio de la base de datos MySQL, que registra todas las operaciones de actualización de la base de datos, incluidas las operaciones que se realizan en qué tabla de qué base de datos. Binlog se utiliza en escenarios como la replicación maestro-esclavo y la recuperación de bases de datos. Los registros de registro en binlog se escriben secuencialmente y no se reutilizan. El tamaño de binlog es variable y se puede establecer max_binlog_sizemediante .

Los dos registros difieren en los siguientes tres puntos.

1. El registro de rehacer es específico del motor InnoDB; el binlog lo implementa la capa del servidor MySQL y puede ser utilizado por todos los motores.

2. Redo log es un registro físico, que registra "qué modificación se realizó en una determinada página de datos"; binlog es un registro lógico, que registra la lógica original de esta declaración, como "agregar 1 al campo c de la fila ID= 2" .

3. El registro de rehacer se escribe cíclicamente y el espacio siempre se agotará; se puede agregar el binlog. "Agregar escritura" significa que después de que el archivo binlog se escriba en un tamaño determinado, cambiará al siguiente y no sobrescribirá el registro anterior.

8. ¿Cómo restaurar la base de datos al estado de cualquier segundo dentro de medio mes?

Binlog registrará todas las operaciones lógicas y adopta la forma de "escritura adjunta". Si su DBA promete que se puede restaurar dentro de medio mes, entonces todos los binlogs del último medio mes se guardarán en el sistema de respaldo y el sistema respaldará regularmente toda la base de datos. El "regular" aquí depende de la importancia del sistema, que puede ser una vez al día o una vez a la semana.

Cuando necesita restaurar a un segundo específico, por ejemplo, a las 2 en punto de la tarde un día, descubre que una tabla se eliminó accidentalmente a las 12 en punto del mediodía y necesita recuperar los datos, entonces Puedes hacerlo:

• Primero, busque la última copia de seguridad completa. Si tiene suerte, puede ser una copia de seguridad de anoche y restáurela en la biblioteca temporal desde esta copia de seguridad;
• Luego, comenzando desde el punto de tiempo de la copia de seguridad, extraiga el binlog de la copia de seguridad en secuencia y reprodúzcalo hasta el momento anterior a que la tabla se eliminó accidentalmente al mediodía.

De esta forma, su base de datos temporal es la misma que la base de datos en línea antes de la eliminación accidental, y luego puede sacar los datos de la tabla de la base de datos temporal y restaurarlos en la base de datos en línea según sea necesario.

9. ¿Cómo aseguran redo log y binglog la coherencia lógica entre los dos registros?

La coherencia lógica de redo log y binlog está garantizada por una confirmación en dos fases. Al realizar operaciones de modificación, MySQL primero registrará estas operaciones en el registro de rehacer y luego registrará estas operaciones en el binlog. Debido al diferente orden de registro de redo log y binlog, puede haber incoherencias lógicas entre ellos. Para garantizar la coherencia lógica, MySQL introduce un mecanismo de confirmación de dos fases.

En la confirmación de dos fases, MySQL primero registrará la operación de modificación en la fase de preparación en el registro de rehacer, y la transacción no se confirma en este momento. Luego, MySQL registra estas operaciones en binlog y marca la transacción como estado de preparación. Finalmente, en la fase de confirmación, MySQL cambiará la transacción del estado de preparación al estado de confirmación y enviará las operaciones en el registro de rehacer al disco al mismo tiempo. Esto garantiza la coherencia lógica entre el registro de rehacer y el registro binario.

Cabe señalar que en la confirmación de dos fases, si se produce un error en la fase de preparación, MySQL revertirá la transacción y marcará la operación correspondiente en el binlog como reversión. En este caso, no habrá incoherencia lógica entre redo log y binlog.

La consistencia lógica de redo log y binlog está garantizada por la confirmación en dos fases, que también es la clave para que MySQL realice A (atomicidad) y C (consistencia) en ACID.

10. ¿Cómo garantiza el registro de deshacer la atomicidad de las transacciones?

El registro de deshacer es un mecanismo utilizado por el motor de almacenamiento InnoDB para implementar operaciones de reversión y atomicidad de transacciones. Cuando se modifica una transacción, InnoDB primero escribirá los datos antes de la modificación en el registro de deshacer y luego modificará los datos. Si la transacción se revierte, la información en el registro de deshacer se puede usar para restaurar los datos al estado anterior a la transacción. modificación Para lograr la atomicidad de la transacción.

Específicamente, cuando comienza una transacción, InnoDB abrirá un registro de deshacer para la transacción, y todas las modificaciones de datos realizadas por la transacción se escribirán primero en el registro de deshacer y luego se modificarán los datos. Cuando se confirma una transacción, todas las modificaciones de datos se escribirán en el registro de rehacer al mismo tiempo y, a continuación, el estado de confirmación de la transacción se escribirá en el registro de rehacer, lo que indica que la transacción se ha confirmado correctamente.

Si se produce un error durante la ejecución de la transacción y provoca una reversión, InnoDB utilizará la información en el registro de deshacer para restaurar los datos al estado anterior a la modificación. Cuando se revierte la transacción, InnoDB revertirá la operación de modificación de datos de la transacción, es decir, restaurará los datos modificados a los datos antes de la modificación y luego escribirá estas operaciones en el registro de rehacer, lo que indica que la reversión de la transacción se realizó correctamente.

El registro de deshacer se utiliza principalmente para garantizar la atomicidad y la reversión de las transacciones. Cuando falla la ejecución de la transacción, la información en el registro de deshacer se puede usar para restaurar los datos al estado anterior a la modificación, evitando así daños e inconsistencias en los datos.