La guía o código que hallarás en este post es la resolución más eficiente y efectiva que hallamos a tus dudas o problema.
Solución:
Puede perder hasta un segundo de transacciones. El valor predeterminado es 1, lo que ayuda a mantener InnoDB Cumple con ÁCIDO.
Según la documentación de MySQL sobre innodb_flush_log_at_trx_commit
Si el valor de innodb_flush_log_at_trx_commit es 0, el búfer de registro se escribe en el archivo de registro una vez por segundo y la operación de descarga en disco se realiza en el archivo de registro, pero no se hace nada en la confirmación de una transacción. Cuando el valor es 1 (el valor predeterminado), el búfer de registro se escribe en el archivo de registro en cada confirmación de transacción y la operación de descarga en disco se realiza en el archivo de registro. Cuando el valor es 2, el búfer de registro se escribe en el archivo en cada confirmación, pero no se realiza la operación de descarga en disco. Sin embargo, el vaciado en el archivo de registro se realiza una vez por segundo también cuando el valor es 2. Tenga en cuenta que no se garantiza al 100% que el vaciado una vez por segundo ocurra cada segundo, debido a problemas de programación del proceso.
Se requiere el valor predeterminado de 1 para el cumplimiento completo de ACID. Puede lograr un mejor rendimiento configurando un valor diferente de 1, pero luego puede perder hasta un segundo de transacciones en un bloqueo. Con un valor de 0, cualquier caída del proceso mysqld puede borrar el último segundo de las transacciones. Con un valor de 2, solo un bloqueo del sistema operativo o un corte de energía pueden borrar el último segundo de las transacciones. La recuperación de fallas de InnoDB funciona independientemente del valor.
Para obtener la mayor durabilidad y consistencia posibles en una configuración de replicación usando InnoDB con transacciones, use innodb_flush_log_at_trx_commit=1 y sync_binlog=1 en el archivo my.cnf de su servidor maestro.
Precaución
Muchos sistemas operativos y algún hardware de disco engañan a la operación de vaciado en disco. Es posible que le digan a mysqld que se ha realizado el lavado, aunque no sea así. 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 caché de disco respaldada por batería en el controlador de disco SCSI o en el propio disco acelera el vaciado de archivos y hace que la operación sea más segura. También puede intentar usar el comando de Unix hdparm para deshabilitar el almacenamiento en caché de escrituras en disco en cachés de hardware, o usar algún otro comando específico del proveedor de hardware.
En base a esto, los valores distintos de 1 ponen a InnoDB en riesgo de perder el valor de las transacciones de 1 segundo, o el valor de los datos de una confirmación de transacción.
La documentación también dice uso sync_binlog=1.
Según la documentación de MySQL sobre sincronización_binlog
Un valor de 1 es la opción más segura porque, en caso de bloqueo, perderá como máximo una declaración o transacción del registro binario. Sin embargo, también es la opción más lenta (a menos que el disco tenga una memoria caché respaldada por batería, lo que hace que la sincronización sea muy rápida).
Su elección más segura es
[mysqld]
innodb_flush_log_at_trx_commit=1
sync_binlog=1
Si no le importa la posible pérdida de datos (hasta 1 segundo), puede usar 0 o 2 bajo su propio riesgo si las recompensas (velocidad de escritura más rápida) valen la pena.
Mi opinión difiere de la otra respuesta.
yo suelo innodb_flush_log_at_trx_commit = 0 solo en mi computadora de desarrollo o mini base de datos doméstica donde no hay datos confidenciales.
yo suelo innodb_flush_log_at_trx_commit = 2 si se trata de una base de datos de blog/estadísticas/comercio electrónico (con ~100x compras en el día), etc.
yo suelo innodb_flush_log_at_trx_commit = 1 si tiene muchos clientes o necesita trabajar con transacciones de dinero como un banco. Entonces, esta vez debe dividir su flujo de datos entre varios servidores para tener velocidad y la seguridad.
Prefiero 2, porque tiene una velocidad de escritura mucho más rápida y falla SÓLO si falla el hardware.
Solo puede decidir si necesita escrituras rápidas o consistencia, integridad y durabilidad de datos garantizadas.
los innodb_flush_log_at_trx_commit se utiliza con el propósito de ..
Si el valor de innodb_flush_log_at_trx_commit es 0, el búfer de registro se escribe en el archivo de registro una vez por segundo y la operación de descarga en disco se realiza en el archivo de registro, pero no se hace nada en la confirmación de una transacción.
Cuando el valor es 1 (el valor predeterminado), el búfer de registro se escribe en el archivo de registro en cada confirmación de transacción y la operación de descarga en disco se realiza en el archivo de registro.
Cuando el valor es 2, el búfer de registro se escribe en el archivo en cada confirmación, pero no se realiza la operación de descarga en disco. Sin embargo, el vaciado en el archivo de registro se realiza una vez por segundo también cuando el valor es 2. Tenga en cuenta que no se garantiza al 100% que el vaciado una vez por segundo ocurra cada segundo, debido a problemas de programación del proceso.
Se requiere el valor predeterminado de 1 para el cumplimiento completo de ACID. Puede lograr un mejor rendimiento configurando un valor diferente de 1, pero luego puede perder hasta un segundo de transacciones en un bloqueo. Con un valor de 0, cualquier caída del proceso mysqld puede borrar el último segundo de las transacciones. Con un valor de 2, solo un bloqueo del sistema operativo o un corte de energía pueden borrar el último segundo de las transacciones. La recuperación de fallas de InnoDB funciona independientemente del valor.
En mi opinión usando innodb_flush_log_at_trx_commit a 2 no debería ser un problema. Pero usar 1 es lo más seguro.