Pregunta

Así que soy bastante nuevo en Tuning Innodb. Estoy cambiando lentamente las tablas (donde sea necesario) de Myisam a Innodb. Tengo alrededor de 100 MB en innodb, así que aumenté el innodb_buffer_pool_size variable a 128MB:

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_size valor (ejemplo my.cnf on Página de configuración innoDB de MySQL Comentarios para cambiar el tamaño del archivo de registro al 25% del tamaño del búfer. Así que ahora mi my.cnf se ve así:

# innodb
innodb_buffer_pool_size = 128M
innodb_log_file_size = 32M

Cuando reinicio el servidor, recibo este error:

110216 9:48:41 InnoDB: Inicialización del grupo de búfer, tamaño = 128.0m
110216 9:48:41 InnoDB: Inicialización completa del grupo de amortiguadores
Innodb: error: 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] complemento 'innodb' La función init devolvió el error.
110216 9:48:41 [Error] Plugin 'innodb' El registro como un motor de almacenamiento falló.

Entonces mi pregunta: ¿es seguro eliminar los viejos log_files, o hay otro método para cambiar el innodb_log_file_size ¿variable?

¿Fue útil?

Solución

Sí, es seguro eliminar el archivo de registro una vez que MySQLD ha sido cerrado

A la luz de esto, simplemente 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

Iniciar MySQLD recreará ib_logfile0 y ib_logfile1

Darle una oportunidad !!!

Actualización 2011-10-20 16:40 EDT

Paga limpiamente todos los datos en el grupo de búfer innoDB 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 IS 75 (MySQL 5.5+) o 90 (antes de MySQL 5.5). Establecer esto en cero mantiene el número de páginas sucias por debajo del 1% de la piscina de amortiguación innodb. Ejecutando service mysql stop Hace esto de todos modos. Además, un cierre finalizará los elementos restantes en el registro de rehacer. Para mantener esta opción, simplemente agréguelo 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 a MySQL para hacer esto. Ahora, este solo paso es vital porque cada transacción no comprometida puede tener otras partes móviles dentro y fuera de los registros de transacciones innoDB (Ver Innodb Infraestructura).

Tenga en cuenta que la configuración innodb_fast_shutdown hasta 2 limpiaría los registros también, pero aún existen más piezas móviles y se recogen en la recuperación de choques durante el inicio de MySQLD. La configuración de 0 es la mejor.

Otros consejos

En su lugar, recomendaría el método oficial, que reproduco aquí por conveniencia:

Para cambiar el número o el tamaño de los archivos de registro innoDB en Mysql 5.6.7 o anterior, use las siguientes instrucciones. El procedimiento a usar depende del valor de innodb_fast_shutdown, que determina si el espacio de tabla del sistema está completamente actualizado antes de una operación de cierre:

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

  • Si innodb_fast_shutdown se establece en 2: establecer innodb_fast_shutdown en 1:

mysql> SET GLOBAL innodb_fast_shutdown = 1;

Luego siga las instrucciones en el elemento 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 innodb. Además, ya no se requiere eliminar archivos de registro antiguos, aunque aún es posible que desee copiar los archivos de registro antiguos en un lugar seguro, como una copia de seguridad. Para cambiar el número o tamaño de los archivos de registro innodb, realice los siguientes pasos:

  1. Detenga el servidor MySQL y asegúrese de que se apague 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 el número de archivos de registro, configure innodb_log_files_in_group.

  3. Inicie el servidor MySQL nuevamente.

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

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

innodb_log_file_size es menos crítico. No lo cambies a menos que haya una razón para. 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. Detener mysql
  4. Eliminar los archivos de registro
  5. Comienza mysql

Los archivos de registro realizan un seguimiento de los negocios pendientes; "innodb_fast_shutdown"dice lidiar con esas cosas después reinicio. 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_size se puede cambiar sin eliminar primero iBlog*
  • 5.7 permite cambiar el tamaño dinámico innodb_buffer_pool_size

¿Debo cambiar log_file_size?

Usar GLOBAL STATUS para calcular el número de minutos antes de que los registros sean ciclos.

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, los archivos de registro están desperdiciando el espacio en el disco. Esa "1 hora" es bastante arbitraria, por lo que si está cerca de él, no se moleste en cambiar el Log_File_Size.

Abandonar innodb_log_files_in_group al valor predeterminado de 2.

Cuando inicia sesión en MySQL, escriba esos comandos:

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

Obtendrá 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

Tiene dos archivos de registro. Así que divídalo por dos y obtendrá un número cerca de 7.000 MB. Solo para estar seguro, configure el tamaño de su archivo de registro 8GB

Chown mysql: mysql -r/etc/mysql/var/lib/mysql && cd/var/lib/mysql && rm -f ib_logfile* && service mysql reiniciar || Servicio de reinicio MySQL

Pruébelo, garantizado para trabajar [probado en Debian 6

Licenciado bajo: CC-BY-SA con atribución
No afiliado a dba.stackexchange
scroll top