Esto está relacionado con esta pregunta . Ayuda a obtener un mejor rendimiento para las tablas InnoDB.

Según el manual de MySQL , innodb_flush_log_at_trx_commites una variable dinámica global. Por lo tanto, puedo cambiarlo usando el comando SET GLOBAL y parece estar funcionando.

mysql> SET GLOBAL innodb_flush_log_at_trx_commit=2;
Query OK, 0 rows affected

mysql> SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 2     |
+--------------------------------+-------+
1 row in set

Pero no modificó la configuración real de MySQL. Cuando actualicé my.cnf y reinicié el servidor MySQL, funcionó. Entonces, ¿no puedo cambiar la variable global en tiempo de ejecución?

Prefiero el valor predeterminado innodb_flush_log_at_trx_commit=1, pero necesito cambiarlo a 2 antes de ejecutar un proceso de restauración para que una base de datos grande sea más rápida. Pero cuando finalice el proceso, quiero volver a cambiar el valor a 1. ¿Es posible hacer esto en tiempo de ejecución?

No tengo acceso a my.cnf en mi servidor de alojamiento compartido.

Si bien estoy de acuerdo con la recomendación de Rolando de cambiar innodb_flush_method, no estaba 100% claro a qué se refería con:

no cambió la configuración real de MySQL

Quiero señalar la advertencia de que hacer un cambio en la variable GLOBAL afecta las conexiones nuevas, pero no modifica la sesión actual (el énfasis es mío):

El cambio de variable global no afecta la variable de sesión para ningún cliente que esté conectado actualmente ( ni siquiera el del cliente que emite la instrucción SET GLOBAL ).

Entonces para verificar eso:

mysql> SHOW GLOBAL VARIABLES LIKE 'innodb_flush_log%';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 1     |
+--------------------------------+-------+
1 row in set (0.00 sec)


mysql> SHOW SESSION VARIABLES LIKE 'innodb_flush_log%';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 1     |
+--------------------------------+-------+
1 row in set (0.00 sec)

mysql> SET GLOBAL innodb_flush_log_at_trx_commit=2;
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW GLOBAL VARIABLES LIKE 'innodb_flush_log%';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 2     |
+--------------------------------+-------+
1 row in set (0.00 sec)

mysql> SHOW SESSION VARIABLES LIKE 'innodb_flush_log%';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 1     |
+--------------------------------+-------+
1 row in set (0.00 sec)

mysql> connect;
Connection id:    6
Current database: *** NONE ***

mysql> SHOW SESSION VARIABLES LIKE 'innodb_flush_log%';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 2     |
+--------------------------------+-------+
1 row in set (0.00 sec)

Al configurar innodb_flush_log_at_trx_commit , corre el riesgo de confusión con la interoperabilidad mysqld / OS. Digo esto porque se confía en el sistema operativo para realizar el vaciado.

Tenga en cuenta la precaución de la documentación de MySQL

Muchos sistemas operativos y algunos hardware de disco engañan la operación de vaciado a disco. Pueden decirle a mysqld que el enjuague ha tenido lugar, aunque no lo haya hecho. Entonces, la durabilidad de las transacciones no está garantizada incluso con la configuración 1, y en el peor de los casos, un corte de energía puede incluso dañar la base de datos InnoDB. El uso de una memoria caché de disco con respaldo de batería en el controlador de disco SCSI o en el disco mismo acelera la descarga de archivos y hace que la operación sea más segura. También puede intentar usar el comando hdparm de Unix para deshabilitar el almacenamiento en caché de las escrituras de disco en cachés de hardware, o usar algún otro comando específico para el proveedor de hardware.

Lo que esto dice es lo siguiente: el sistema operativo puede mentir como un marido infiel. El sistema operativo dice que vaciará al disco y simplemente no lo hace. Por lo tanto, incluso si configura innodb_flush_log_at_trx_commit, debe divorciar la descarga del sistema operativo en el disco de la descarga de mysqld en el disco.

Intente establecer innodb_flush_method en O_DIRECT si aún no lo ha hecho. Es posible que vea una diferencia porque el método flush es muy diferente (vea mi aclaraciónMar 04, 2011 posterior a la variable innodb_flush_method de MySQL ).

CONSIDERACIÓN

Como mencionó, no tiene acceso a my.cnf. Póngase en contacto con SysAdmin en su proveedor y cambie innodb_flush_method .

ACTUALIZACIÓN 2012-12-10 12:45 EDT

Actualmente estoy ejecutando MySQL 5.5.12 en mi PC. Cuando me conecto y corro show variables like 'innodb_flush_method';me sale

mysql> show variables like 'innodb_flush_method';
+---------------------+-------+
| Variable_name       | Value |
+---------------------+-------+
| innodb_flush_method |       |
+---------------------+-------+
1 row in set (0.05 sec)

mysql>

Como está en blanco, solo indica que se utiliza la configuración predeterminada. Lea mi publicación del 04 de marzo de 2011 para obtener una aclaración sobre MySQL innodb_flush_method variable