Encontrar y corregir la corrupción del índice InnoDB

Recuerda que en la informática un problema casi siempre tiene diversas resoluciones, no obstante nosotros aquí te enseñamos lo más óptimo y eficiente.

Solución:

Gracias Rolando y Michael por sus respuestas.

Para cerrar el ciclo, aquí está la respuesta que se me ocurrió para mis preguntas originales:

• P: ¿Cómo puedo determinar si otras tablas tienen un índice corrupto similar?

• A: Usar CHECK TABLE. corrí mysqlcheck -c en todas las tablas InnoDB relevantes para averiguar cuáles tenían corrupción de índice

• P: ¿Cuál es la forma más eficaz de corregir los índices dañados?

• A: Usar OPTIMIZE TABLE para reconstruir la tabla InnoDB que tiene índices corruptos. Esto provoca una reconstrucción completa de la tabla que corrige la corrupción.

Es posible que tenga la solución más fácil que existe. Sin embargo, me encantaría aclarar algunas cosas:

Hacer una instantánea con una instancia de MySQL en ejecución podría afectar el único archivo responsable de la manipulación del índice secundario: ibdata1.

El espacio de tablas del sistema ibdata1 es el hogar de 7 clases de información InnoDB

• Páginas de datos (si innodb_file_per_table está deshabilitado)
• Páginas de índice (si innodb_file_per_table está deshabilitado)
• Diccionario de datos (lista incluida de tablas y sus ID de TableSpace)
• Búfer de escritura doble (proporciona información de suma de verificación para evitar la corrupción de datos)
• Insertar búfer (cambios en índices secundarios)
• Rehacer registros
• Deshacer registros
• Representación pictórica

Las clases fundamentales por las que me preocuparía son el búfer de escritura doble y el búfer de inserción. Hacer una instantánea en vivo con cualquiera de estos no escritos correctamente introducirá corrupción de datos.

Haciendo FLUSH TABLES WITH READ LOCK;no detiene las escrituras en ibdata1 como uno pensaría. Escribí sobre este tema antes. Solía ​​pensar que sí, hasta que fue señalado por el miembro de DBA.SE @ShlomiNoach.

Piense en el grupo de búfer de InnoDB. Tendría que eliminar todas las páginas sucias para que todo quede inactivo en el disco. Lo siguiente fuerza la eliminación de todas las páginas sucias por tabla:

• SET GLOBAL innodb_fast_shutdown = 0; seguido por service mysql stop
• SET GLOBAL innodb_max_dirty_pages_pct = 0; y espere hasta que el 1% de Buffer Pool esté sucio
• mysqldump

Además, no olvide que los registros binarios y los registros de retransmisión dependen del sistema operativo para el vaciado.

Una instantánea de EC2 no es compatible con MySQL en estos aspectos, no más de lo que sería una instantánea de LVM. Es por eso que el software de copia de seguridad como R1Soft de CDP tiene un módulo MySQL para tales ocasiones.

Por el contrario, una instancia MYSQL de Amazon RDS es consciente y está diseñada para tales escenarios centrados en InnoDb. Solo si hay tablas MyISAM activas en la instancia de RDS, FLUSH TABLES WITH READ LOCK; ser un mal necesario para realizar manualmente.

Con respecto a su pregunta original, cuando ejecutó ALTER TABLE my_table ENGINE=InnoDB; simplemente reconstruyó las páginas de índice leyendo las páginas de datos de la tabla, muy probablemente sin pasar por el búfer de inserción ibdata1. Esta es la razón por la que funcionó para usted.

Si puedes hacer un mysqldump con --single-transaction --master-data=1 en el Maestro, envíe mysqldump al esclavo y hágalo sin Cargos Financieros, ese sería un método más seguro para configurar el EC2 Esclavo.

Si debe hacer la instantánea, haga esto en el Esclavo:

• Correr SET GLOBAL innodb_fast_shutdown = 0;
• service mysql stop
• Haz tu instantánea
• service mysql start
• Agregue innodb_fast_shutdown a /etc/my.cnf

Información adicional: cuanto más pequeños son ib_logilfe0 e ib_logfile1, más rápido se apaga.

Espero que esto explique muchas cosas.

ACTUALIZACIÓN 2013-01-14 10:36 EDT

Preguntaste recientemente en la sección de comentarios.

¿Cómo puedo saber si una base de datos tiene daños en el índice?

Tenga en cuenta que está utilizando EC2 y no RDS. Con RDS, Amazon es responsable del estado holístico de la máquina virtual y la instancia de MySQL. Con EC2, Amazon es responsable únicamente de la máquina virtual. El estado holístico de la instancia de MySQL ahora depende de usted. Es posible que desee migrar la base de datos a RDS porque viene con funciones adicionales para protegerse contra dicha corrupción.

Sección de Reseñas y Valoraciones

Más adelante puedes encontrar las críticas de otros administradores, tú incluso tienes el poder dejar el tuyo si lo deseas.

---

---

Utiliza Nuestro Buscador