Est-il prudent d'utiliser innodb_flush_log_at_trx_commit = 2

J'ai tourné innodb_flush_log_at_trx_commit = 2et obtenir une vitesse d'écriture très rapide. Mais est-il sécuritaire d'être utilisé dans un site Web de production?

Vous pouvez perdre jusqu'à une seconde de transactions. La valeur par défaut est 1, ce qui permet de conserver la conformité InnoDB ACID .

Selon la documentation MySQL sur innodb_flush_log_at_trx_commit

Si la valeur de innodb_flush_log_at_trx_commit est 0, le tampon de journal est écrit dans le fichier journal une fois par seconde et l'opération de vidage sur le disque est effectuée sur le fichier journal, mais rien n'est fait lors d'une validation de transaction. Lorsque la valeur est 1 (valeur par défaut), le tampon de journal est écrit dans le fichier journal à chaque validation de transaction et l'opération de vidage sur disque est effectuée sur le fichier journal. Lorsque la valeur est 2, le tampon de journal est écrit dans le fichier à chaque validation, mais l'opération de vidage sur le disque n'est pas effectuée. Toutefois, le vidage du fichier journal a lieu une fois par seconde lorsque la valeur est égale à 2. Notez que le vidage une fois par seconde n'est pas garanti à 100% toutes les secondes, en raison de problèmes de planification de processus.

La valeur par défaut de 1 est requise pour la conformité ACID complète. Vous pouvez obtenir de meilleures performances en définissant une valeur différente de 1, mais vous pouvez ensuite perdre jusqu'à une seconde de transactions dans un blocage. Avec une valeur de 0, tout crash de processus mysqld peut effacer la dernière seconde des transactions. Avec une valeur de 2, seule une panne du système d'exploitation ou une panne de courant peut effacer la dernière seconde des transactions. La récupération sur incident d’InnoDB fonctionne quelle que soit la valeur.

Pour une durabilité et une cohérence maximales dans une configuration de réplication utilisant InnoDB avec des transactions, utilisez innodb_flush_log_at_trx_commit = 1 et sync_binlog = 1 dans le fichier my.cnf de votre serveur maître.

Mise en garde

De nombreux systèmes d'exploitation et certains matériels sur disque trompent l'opération de vidage sur disque. Ils peuvent dire à mysqld que la couleur a déjà eu lieu, même si ce n’est pas le cas. Alors, la durabilité des transactions n’est pas garantie même avec le réglage 1, et dans le pire des cas, une panne de courant peut même corrompre la base de données InnoDB. L'utilisation d'un cache de disque protégé par batterie dans le contrôleur de disque SCSI ou sur le disque lui-même accélère les vidages de fichiers et rend l'opération plus sûre. Vous pouvez également essayer d'utiliser la commande Unix hdparm pour désactiver la mise en cache des écritures sur disque dans des caches de matériel, ou utiliser une autre commande spécifique au fournisseur de matériel.

Sur cette base, des valeurs autres que 1 exposent InnoDB au risque de perdre une seconde de transactions ou la valeur des données d'une validation de transaction.

La documentation dit également utiliser sync_binlog=1.

Selon la documentation MySQL sur sync_binlog

Une valeur de 1 est le choix le plus sûr, car en cas de blocage, vous perdez au plus une déclaration ou transaction du journal binaire. Cependant, il s’agit également du choix le plus lent (à moins que le disque ne dispose d’un cache sauvegardé par batterie, ce qui rend la synchronisation très rapide).

Votre choix le plus sûr est

[mysqld]
innodb_flush_log_at_trx_commit=1
sync_binlog=1

Si vous ne craignez pas une perte de données possible (d'une valeur pouvant aller jusqu'à 1 seconde), vous pouvez utiliser 0 ou 2 à vos risques et périls si les récompenses (vitesse d'écriture plus rapide) en valent la peine.

Le innodb_flush_log_at_trx_commitest utilisé dans le but que ..

Si la valeur innodb_flush_log_at_trx_commit est 0, le tampon de journal est écrit dans le fichier journal une fois par seconde et l'opération de vidage sur disque est effectuée sur le fichier journal, mais rien n'est fait lors d'une validation de transaction.

Lorsque la valeur est 1 (valeur par défaut), le tampon de journal est écrit dans le fichier journal à chaque validation de transaction et l'opération de vidage sur disque est effectuée sur le fichier journal.

Lorsque la valeur est 2, le tampon de journal est écrit dans le fichier à chaque validation, mais l'opération de vidage sur le disque n'est pas effectuée. Toutefois, le vidage du fichier journal a lieu une fois par seconde lorsque la valeur est égale à 2. Notez que le vidage une fois par seconde n'est pas garanti à 100% toutes les secondes, en raison de problèmes de planification de processus.

La valeur par défaut de 1 est requise pour la conformité ACID complète. Vous pouvez obtenir de meilleures performances en définissant une valeur différente de 1, mais vous pouvez ensuite perdre jusqu'à une seconde de transactions dans un blocage. Avec une valeur de 0, tout crash de processus mysqld peut effacer la dernière seconde des transactions. Avec une valeur de 2, seule une panne du système d'exploitation ou une panne de courant peut effacer la dernière seconde des transactions. La récupération sur incident d’InnoDB fonctionne quelle que soit la valeur.

À mon avis, utiliser innodb_flush_log_at_trx_commit2 ne devrait pas être un problème. Mais utiliser 1 est le plus sûr.

Mon opinion diffère des autres. innodb_flush_log_at_trx_commit = 0 si: il s'agit de mon ordinateur de développement ou de ma mini base de données personnelle où il n'y a pas de données sensibles.

innodb_flush_log_at_trx_commit = 2 si: il s'agit d'un blog / stats / e-commerce (avec ~ 100x shop par jour), etc.

innodb_flush_log_at_trx_commit = 1 si: vous avez beaucoup de clients ou vous devez travailler avec des transactions monétaires telles que des banques. Donc, cette fois, vous devez répartir votre flux de données entre plusieurs serveurs pour plus de rapidité et de sécurité.

Je préfère 2, car sa vitesse d'écriture est environ 75 fois supérieure et il échoue UNIQUEMENT si le matériel tombe en panne.

Quoi qu'il en soit, vous devriez savoir ce dont vous avez besoin davantage de vitesse d'écriture ou d'informations d'une seconde?

J'essaie de répondre, quel est le but de innodb_flush_log_at_trx_commit?

InnoDB effectue la plupart de ses opérations en mémoire ( InnoDB Buffer Pool). Toutes les données modifiées sont écrites InnoDB transaction log filepuis vidées (écrites) dans un stockage durable (disque dur).

Pour la sécurité des données ( Durability from ACID), InnoDB doit stocker les données modifiées de chaque transaction dans un stockage permanent. Dans le même temps, s’engager sur le disque pour chaque transaction est un processus coûteux.

Les E / S de disque sont un processus de blocage et il est très lent, c’est un disque lent, cela réduira en outre le nombre de InnoDB transaction per seconds(Débit de disque).

InnoDB fournit une innodb_flush_log_at_trx_commitvariable permettant de contrôler la fréquence de cette opération de vidage. En fonction de la valeur, le fonctionnement de rinçage InnoDB se comporte différemment.

(Déjà expliqué dans d'autres réponses)

0 - Écriture dans le fichier journal et vidage sur le disque toutes les secondes (les données stockées dans le pool de mémoire tampon ne sont pas écrites dans le fichier journal - pour améliorer les performances). 1 - Flush sur le disque lorsqu'une transaction est validée - par défaut (Pour la sécurité des données - Conformité ACID) 2 - Écriture dans le fichier journal pour chaque transaction et vidage sur le disque toutes les secondes. (Pour gain de performance)

Dépend de l'exigence de l'application ( Performance Vs data safety), vous pouvez définir cette variable. La différence entre 0 et 2 - les deux augmenteront les performances, la valeur 2 stocke les données dans le fichier de transaction et peut être récupérée, en cas de panne ou d'échec, mais pas à 0.

Dans de nombreux cas, le vidage sur disque signifie que les données sont écrites et InnoDB buffer pool (memory) to Operating systems cachenon écrites sur le disque de stockage (stockage permanent). En cas d'échec, dans le pire des cas, vous risquez de perdre des données jusqu'à une seconde.

Le gain de performance dépend de l'environnement et vous pouvez comparer et identifier. Dans un environnement de réplication, pour la sécurité et la cohérence des données, définissez innodb_flush_log_trx_commit = 1et sync_binlog=1.

Si les performances constituent l'objectif principal de l'application, InnoDB fournit une variable permettant de contrôler la fréquence de vidage des journaux - innodb_flush_log_at_timeout- qui vous permet de définir une plage de fréquence de vidage des journaux de 1 to 2700 seconds: par défaut, la valeur est 1.

Sachez que lorsque vous augmentez l'intervalle de vidage jusqu'à N secondes, l'amélioration des performances s'accompagne d'un compromis en matière de sécurité des données pouvant atteindre N secondes. Par exemple, si le rinçage a lieu toutes les 5 secondes, le gain de débit est très élevé, mais en cas de panne de courant ou de panne du système, vous perdrez des données d’une valeur de 5 secondes.

Cet article traite des opérations de vidage et de validation des transactions InnoDB .

Vous pouvez changer après avoir fait le mode 2 sur un disque:

Non modifiable dans certains cas, comme si vous avez une réplication multi az:

Si votre matériel tombe en panne, vous risquez de perdre toutes vos données. J'utilise donc param = 2 sans souci. Quoi qu'il en soit, vous pouvez partager vos données sensibles (ordre, argent virtuel, ...) et régulières (statistiques, panier, ...) entre 2 serveurs de base de données et les conserver rapidement et en toute sécurité. Pour les transactions entre bases de données, vous pouvez utiliser http://dev.mysql.com/doc/refman/5.7/en/xa.html