¿Cómo cambiar de forma segura la variable innodb de MySQL 'innodb_log_file_size'?

105

Así que soy bastante nuevo en el ajuste de InnoDB. Estoy cambiando lentamente las tablas (cuando sea necesario) de MyIsam a InnoDB. Tengo aproximadamente 100 MB en innodb, así que aumenté la innodb_buffer_pool_sizevariable a 128 MB:

mysql> show variables like 'innodb_buffer%';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| innodb_buffer_pool_size | 134217728 |
+-------------------------+-----------+
1 row in set (0.00 sec)

Cuando fui a cambiar el innodb_log_file_sizevalor (ejemplo my.cnf en los comentarios de la página de configuración innodb de mysql para cambiar el tamaño del archivo de registro al 25% del tamaño del búfer. Entonces mi my.cnf se ve así:

# innodb
innodb_buffer_pool_size = 128M
innodb_log_file_size = 32M

Cuando reinicio el servidor, aparece este error:

110216 9:48:41 InnoDB: Inicializando agrupación de almacenamiento intermedio, tamaño = 128.0M
110216 9:48:41 InnoDB: Inicialización completada de agrupación de almacenamiento intermedio
InnoDB: Error: el archivo de registro ./ib_logfile0 es de diferente tamaño 0 5242880 bytes
InnoDB: que el especificado en el archivo .cnf 0 33554432 bytes!
110216 9:48:41 [ERROR] La función de inicio del complemento 'InnoDB' devolvió el error.
110216 9:48:41 [ERROR] El registro del complemento 'InnoDB' como MOTOR DE ALMACENAMIENTO falló.

Entonces mi pregunta: ¿es seguro eliminar los archivos de registro antiguos o hay otro método para cambiar la innodb_log_file_sizevariable?

Derek Downey
fuente
1
Simplemente comente el innodb_log_file_size en my.ini .....
55
hmm, ¿por qué querría comentarlo para usar el valor predeterminado cuando intento cambiarlo del valor predeterminado?
Derek Downey
Sí, al comentar la línea innodb_log_file_size funciona ... Gracias.
muhammad umar farooq franco
2
@muhammadumarfarooqfrank Por supuesto que funciona, porque ya no está cambiando el valor de la variable, por lo tanto, hace que todo el punto sea discutible. Desearía que hubiera una manera de rechazar los comentarios.
dr01

Respuestas:

83

Sí, es seguro eliminar el archivo de registro una vez que mysqld ha sido apagado

En vista de esto, solo realice los siguientes pasos:

mysql -uroot -p... -e"SET GLOBAL innodb_fast_shutdown = 0"
service mysql stop
mv /var/lib/mysql/ib_logfile[01] /tmp
service mysql start

Al iniciar mysqld se recreará ib_logfile0yib_logfile1

Darle una oportunidad !!!

ACTUALIZACIÓN 2011-10-20 16:40 EDT

Pagina limpiamente todos los datos en el InnoDB Buffer Pool antes de rehacer los archivos de registro, debe configurar esta opción aproximadamente 1 hora antes del apagado:

SET GLOBAL innodb_max_dirty_pages_pct = 0;

Por defecto, innodb_max_dirty_pages_pct es 75 (MySQL 5.5+) o 90 (antes de MySQL 5.5). Establecer esto a cero mantiene el número de páginas sucias por debajo del 1% del InnoDB Buffer Pool. Realizarlo service mysql stophace esto de todos modos. Además, un apagado terminará los elementos restantes en el registro de rehacer. Para mantener esta opción, simplemente agréguela a /etc/my.cnf:

[mysqld]
innodb_max_dirty_pages_pct = 0

ACTUALIZACIÓN 2013-04-19 16:16 EDT

Actualicé mi respuesta un poco más con innodb_fast_shutdown porque solía reiniciar mysql y detener mysql para hacer esto. Ahora, este paso es vital porque cada transacción no comprometida puede tener otras partes móviles dentro y fuera de los InnoDB Transaction Logs ( Ver Infraestructura InnoDB ).

Tenga en cuenta que establecer innodb_fast_shutdown en 2 también eliminaría los registros, pero aún existen más partes móviles y se selecciona en Crash Recovery durante el inicio de mysqld. La configuración de 0 es la mejor.

RolandoMySQLDBA
fuente
1
Buena respuesta y la actualización también es genial. Mi única sugerencia sería COPIAR los ib_logfiles a otra ubicación en caso de que algo salga mal. Esto le ayudará a tener una idea de cómo dimensionar los archivos: mysqlperformanceblog.com/2011/07/09/…
Justin Noel
55
También funcionó para mí, PERO: la interfaz de usuario de la consola de Linux puede ser engañosa: el inicio de mysqld toma mucho tiempo si configura un tamaño de archivo de registro grande (varios cientos de MB o más). La interfaz de usuario de la consola muestra puntos y luego muestra "¡falló!", Pero de hecho MySQL todavía se está iniciando. Espere y siga leyendo el archivo de registro (o monitoree el archivo de registro con "tail -f [log-file]") hasta que vea "mysqld: listo para las conexiones". y ambos archivos de registro asignados en el disco.
f055
2
¡¡ADVERTENCIA!! el paso 3 no funcionó para mí y mi corazón casi se detuvo cuando vi que mysql se estaba cargando sin InnoDB, tuve que detener mysql y eliminarlos manualmente e iniciar MySQL nuevamente. dos consejos: 1. haga una copia de seguridad de sus archivos de registro ya existentes, 2. elimine los archivos manualmente
Peeyush Kushwaha
2
Peeyush es correcto. Incluso la documentación de mysql recomienda hacer una copia de seguridad de sus archivos de registro en caso de que algo salga mal
Greg
1
@ Greg, es por eso que uso SET GLOBAL innodb_fast_shutdown = 0;. Cuando MySQL se cierra, todo lo transaccional se elimina de todas las partes móviles, incluidos los registros de rehacer (ib_logfile0 e ib_logfile1). Uno puede quedarse con ellos. Todavía tengo que encontrar problemas con los registros completamente enjuagados.
RolandoMySQLDBA
31

En cambio, recomendaría el método oficial , que reproduzco aquí por conveniencia:

Para cambiar el número o el tamaño de los archivos de registro de InnoDB en MySQL 5.6.7 o anterior , use las siguientes instrucciones. El procedimiento a utilizar depende del valor de innodb_fast_shutdown, que determina si se debe actualizar o no el espacio de tabla del sistema antes de una operación de apagado:

  • Si innodb_fast_shutdown no está configurado en 2: Detenga el servidor MySQL y asegúrese de que se apaga sin errores, para asegurarse de que no haya información para transacciones pendientes en el registro de rehacer. Copie los archivos de registro de rehacer antiguos en un lugar seguro, en caso de que algo saliera mal durante el apagado y los necesite para recuperar el espacio de tabla. Elimine los archivos de registro antiguos del directorio de archivos de registro, edite my.cnf para cambiar la configuración del archivo de registro e inicie nuevamente el servidor MySQL. mysqld ve que no existen archivos de registro de InnoDB al inicio y crea nuevos.

  • Si innodb_fast_shutdown está establecido en 2: establezca innodb_fast_shutdown en 1:

mysql> SET GLOBAL innodb_fast_shutdown = 1;

Luego siga las instrucciones del artículo anterior.

A partir de MySQL 5.6.8 , la configuración innodb_fast_shutdown ya no es relevante al cambiar el número o el tamaño de los archivos de registro de InnoDB. Además, ya no es necesario eliminar los archivos de registro antiguos, aunque es posible que aún desee copiar los archivos de registro antiguos en un lugar seguro, como copia de seguridad. Para cambiar el número o el tamaño de los archivos de registro de InnoDB, realice los siguientes pasos:

  1. Detenga el servidor MySQL y asegúrese de que se apaga sin errores.

  2. Edite my.cnf para cambiar la configuración del archivo de registro. Para cambiar el tamaño del archivo de registro, configure innodb_log_file_size. Para aumentar la cantidad de archivos de registro, configure innodb_log_files_in_group.

  3. Inicie el servidor MySQL nuevamente.

Si InnoDB detecta que innodb_log_file_size difiere del tamaño del archivo de rehacer registro, escribirá un punto de control de registro, cerrará y eliminará los archivos de registro antiguos, creará nuevos archivos de registro en el tamaño solicitado y abrirá los nuevos archivos de registro.

Semilla aleatoria
fuente
Esta es una buena respuesta como una actualización de esta pregunta. +1 !!!
RolandoMySQLDBA
2
Esta no es una "actualización". Estas páginas del manual han existido por mucho tiempo. Siempre recomiendo información de primera mano del manual (uno de los mejores manuales que existen) en lugar de reinventar la rueda y duplicar información (que es algo que los DBA más odiamos).
RandomSeed
Este es el método preferido a partir de MySQL 5.6. Si todavía se está ejecutando en una versión anterior a 5.6, esto no funcionará.
Derek Downey
20

innodb_buffer_pool_size- simplemente cambie my.cnf( my.ini) y reinicie mysqld.

innodb_log_file_sizeEs menos crítico. No lo cambie a menos que haya una razón para hacerlo. Roland proporcionó los pasos , pero un aspecto me preocupa ... No sé si los dos primeros pasos son importantes; parece que podrían ser:

  1. set innodb_fast_shutdown = OFF
  2. reiniciar mysql
  3. deja de mysql
  4. eliminar los archivos de registro
  5. iniciar mysql

Los archivos de registro realizan un seguimiento de los asuntos pendientes; " innodb_fast_shutdown" dice que debe lidiar con esas cosas después de reiniciar. Entonces, ¿eliminar los archivos puede perder información?

Las nuevas versiones han mejorado las cosas: (más discusión en Comentarios)

  • 5.6 Permite innodb_log_file_size> 4GB
  • 5.6 innodb_log_file_sizese puede cambiar sin quitar primero iblog *
  • 5.7 permite cambiar el tamaño dinámicamente innodb_buffer_pool_size

¿Debo cambiar log_file_size?

Se usa GLOBAL STATUSpara calcular la cantidad de minutos antes de los ciclos de registro.

Uptime / 60 * innodb_log_file_size / Innodb_os_log_written`

Si es mucho menos de 60 (minutos), entonces podría ayudar a aumentar log_file_size. Si es mucho más, entonces los archivos de registro están desperdiciando espacio en disco. Esa "1 hora" es bastante arbitraria, por lo que si está cerca de ella, no se moleste en cambiar el log_file_size.

Dejar innodb_log_files_in_groupen el valor predeterminado de 2.

Rick James
fuente
+1 su preocupación parece estar respaldada por los documentos
Jack Douglas
Eché un vistazo a esta respuesta y me gusta la primera línea. Por lo general, los clientes bajaban y subían mysql --skip-networkingcomo medida de precaución para eliminar esos cambios de última hora. Su primera línea (set innodb_fast_shutdown = OFF) elimina eso. +1 !!!
RolandoMySQLDBA
1
Gracias por los votos a favor. Los nuevos lectores pueden no necesitar esto. En 5.6.8 , innodb_log_file_sizese mejoró para permitir cambiarlo sin eliminar los archivos iblog.
Rick James
¿Te refieres a "más crítico", no "menos crítico"?
Igor
@Igor - No. Si tiene log_file_size demasiado pequeño, habrá un extra de E / S a través de él. Raramente veo eso. Si lo tiene demasiado grande, solo está desperdiciando espacio en disco. El objetivo al configurarlo es recorrerlo en una hora. Pero 10 minutos versus 10 horas, tampoco importa mucho. más ...
Rick James
1

Cuando inicie sesión en mysql, escriba esos comandos:

pager grep seq;
show engine innodb status \G select sleep(60); show engine innodb status \G

Obtendrás dos números. Primero obtienes uno y luego espera un minuto. Obtendrás otro.

Digamos que el primero es 3.456.718.123 y el segundo es 4.098.873.134

Ahora (4.098.873.134-3.856.718.123) * 60/1024/1024

El resultado es = 13.856 MB

Tienes dos archivos de registro. Divídalo por dos y obtendrá un número cercano a los 7,000 MB. Solo para estar seguro, configure el tamaño del archivo de registro de 8 GB

Novato Linux
fuente
1
No es obvio (al menos para mí) que esto realmente responda la pregunta. Esto parece ser una sugerencia de un tamaño alternativo para el archivo de registro, no cómo cambiar de forma segura el tamaño del archivo de registro.
RDFozz
1
@RDFozz tienes razón. Esto no responde cómo cambiar el tamaño del archivo de registro. Esta pregunta responde cómo averiguar el número para establecer innodb_log_file_size. Ya respondí esa pregunta hace cinco años (consulte el subtítulo Log File Sizeen dba.stackexchange.com/questions/23189/… )
RolandoMySQLDBA
Solo quería ayudar: / Sin embargo, sé que no es la respuesta exacta.
Novato de Linux el
-4

chown mysql: mysql -R / etc / mysql / var / lib / mysql && cd / var / lib / mysql && rm -f ib_logfile * && service mysql restart || servicio mysql reiniciar

Pruébelo, garantizado para funcionar [probado en Debian 6]

Gregory
fuente
2
Esto no garantiza un apagado limpio. Puede funcionar en el caso promedio en un servidor con solo una carga ligera, pero no se recomienda si le importa la integridad de su base de datos.
Emil Vikström