Est-il prudent d'utiliser innodb_flush_log_at_trx_commit = 2

55

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?

Bruce Dou
la source

Réponses:

57

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.

RolandoMySQLDBA
la source
3
Rolando: +1 pour les dernières lignes sync_binlog = 1 ...
Abdul Manaf
@AbdulManaf, optez toujours pour l'intégrité des données plutôt que la vitesse. Si vous voulez sacrifier la vitesse pour l’intégrité des données, vous perdrez beaucoup plus de temps à traiter les problèmes de données.
Pacerier
1
@RolandoMySQLDBA, Par "perdre une seconde de transaction", voulez-vous dire qu'un succès commit peut en réalité être perdu?
Pacerier
1
Pacerier, oui. Les données ne sont garanties d'être écrites sur le disque qu'après leur "vidage sur le disque". Jusque-là, il se peut que ce ne soit que dans la mémoire RAM
Emil Vikström
2
@RolandoMySQLDBA vous êtes l'homme, sérieusement. Si vous faites autre chose que des concerts de consultation mysql à temps plein, vous devriez peut-être changer de carrière.
jeudi
25

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.

Abdul Manaf
la source
3
Je viens de remarquer que vous avez répondu seulement 18 secondes après moi avec essentiellement la même réponse. +1 !!!
RolandoMySQLDBA le
24

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?

Sertekmedia
la source
1
+1 pour75x faster write speed and it fails ONLY if hardware fails.
Naman Gala
3
75 fois plus vite? Citation requise.
Pacerier
5
Mon propre point de repère: 5000 UPDATEavec innodb_flush_log_at_trx_commit = 1: 179 secondes. Avec innodb_flush_log_at_trx_commit = 2: 1,12secondes. C'est une vitesse d'écriture 160x plus rapide dans mon cas.
Kevin
Bonne réponse. Une chose à laquelle vous devez penser est que si votre machine se bloque après une transaction réussie, il est probable que la transaction n’ait pas été écrite sur le disque avec innodb_flush_log_at_trx_commit = 2, et pourtant la réussite a été indiquée à votre application (c’est-à-dire que mysqld parvient à envoyer un paquet réseau indiquant la transaction terminée. pour le pilote dans votre application), cette chance est très très faible
Vladislav Vaintroub 17/02/2017
pouvez-vous améliorer votre réponse en précisant ce que la crash
doc
2

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:

peut changer après avoir fait le mode 2 sur les aws

prévisualisations

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

FYI non modifiable dans certains cas

rathishDBA
la source
1

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

Karolis Mačiulskis
la source
"Perdez toutes vos données" ou voulez-vous dire les transactions qui ont été interrogées au cours des dernières secondes?
NiCk Newman
1
Une défaillance matérielle peut entraîner la perte de tout un disque dur, d'où la perte de toutes vos données. Donc , sauf si vous avez une configuration de réplication de vos données est à la merci de la fréquence que vous faites des sauvegardes de toute façon, de sorte que le point de cette réponse a été fait est qu'une seconde ou deux de données perdues est rien à craindre en comparaison
thomasrutter