0
217
ViewsEl registro de deshacer de MySQL sigue creciendo
El registro de deshacer de MySQL sigue creciendo a 180G y no hay registros de reversión y simplemente no puedo entender por qué. Hasta donde yo sé, se truncará automáticamente cuando llegue a innodb_max_undo_log_size , que se ha establecido en 1GB . ¿Alguna buena solución para esto? Esta es la consulta:
SELECT Name, ALLOCATED_SIZE/1024/1024/1024 AS SIZE (GB) FROM INFORMATION_SCHEMA.INNODB_TABLESPACES ORDER BY file_size DESC LIMIT 1;
|Name | SIZE (GB) | |innodb_undo_001 | 183.953220367432 | 
¿Qué es lo que debo revisar? ¿Reiniciar el servicio MySQL reducirá el tamaño del registro de deshacer? Por favor ayuda.
1 answers
Answer question0
Compruebe si hay una transacción que se está ejecutando durante mucho tiempo.
mysql> show engine innodb status\GAhora desplácese hasta las últimas entradas de la sección
------------ TRANSACTIONS ------------Allí verá las transacciones de mayor duración. Aquí hay un ejemplo:
---TRANSACTION 184428602997, ACTIVE 236 sec 8057 lock struct(s), heap size 980520, 2000277 row lock(s) MySQL thread id 124353057, OS thread handle 0x7ee6ef041700, query id 6717837828 10.20.30.40 a_mysql_username cleaning upAquí puede ver que la transacción se ejecuta durante 236 segundos. Cuando tu lo hagas
mysql> show processlist;probablemente no lo verás allí dentro al mismo tiempo. En la lista de procesos, la columna de tiempo le brinda los segundos desde el último cambio de estado en la transacción. Cuando la transacción ejecuta una nueva consulta, el temporizador se restablece a 0.
De todos modos, lo que también ve en el ejemplo anterior es la identificación del hilo mysql para esta transacción. Usa esto para matar el hilo.
mysql> kill 124353057;Y su problema debe ser resuelto. Esto llevará bastante tiempo (en realidad, para 180 GB llevará mucho tiempo), ya que la transacción se revierte. Sin embargo, sucedería lo mismo si reiniciara el servidor. No reinicie, su servidor estará inactivo durante bastante tiempo. Acaba con el hilo y espera.