Est-il sûr d'utiliser innodb_flush_log_at_trx_commit = 2
J'ai tourné innodb_flush_log_at_trx_commit = 2 et obtenez une vitesse d'écriture très rapide. Mais est-il sûr d'être utilisé dans le site Web de production?
Vous pouvez perdre jusqu'à une seconde de transactions. La valeur par défaut est 1, ce qui aide à maintenir InnoDB ACID conforme .
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 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 disque n'y est pas effectuée. Cependant, le vidage du fichier journal a lieu une fois par seconde également lorsque la valeur est 2. Notez que le vidage une fois par seconde n'est pas garanti à 100% à chaque seconde, en raison de problèmes de planification du processus.
La valeur par défaut de 1 est requise pour une conformité ACID complète. Vous pouvez obtenir de meilleures performances en définissant une valeur différente de 1, mais vous pouvez alors perdre jusqu'à une seconde de transactions dans un crash. Avec une valeur de 0, tout plantage du processus mysqld peut effacer la dernière seconde des transactions. Avec une valeur de 2, seul un plantage du système d'exploitation ou une panne de courant peut effacer la dernière seconde des transactions. La récupération après incident d'InnoDB fonctionne quelle que soit la valeur.
Pour une durabilité et une cohérence optimales dans une configuration de réplication utilisant InnoDB avec des transactions, utilisez innodb_flush_log_at_trx_commit = 1 et sync_binlog = 1 dans votre fichier my.cnf de votre serveur maître.
Mise en garde
De nombreux systèmes d'exploitation et certains matériels de disque trompent l'opération de vidage sur disque. Ils peuvent dire à mysqld que la vidange a eu lieu, même si ce n'est pas le cas. Ensuite, la durabilité des transactions n'est pas garantie même avec le paramètre 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 disque sauvegardé par batterie dans le contrôleur de disque SCSI ou dans 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 les caches matériels, 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 l'équivalent d'une seconde de transactions ou la valeur des données d'un engagement de transaction.
La documentation indique é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 plantage, vous perdez au plus une instruction ou une transaction du journal binaire. Cependant, c'est aussi le choix le plus lent (sauf si le disque a 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 cela ne vous dérange pas une perte de données possible (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_commit est utilisé dans le but de ..
Si la valeur de innodb_flush_log_at_trx_commit est égal à 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 disque n'y est pas effectuée. Cependant, le vidage du fichier journal a lieu une fois par seconde également lorsque la valeur est 2. Notez que le vidage une fois par seconde n'est pas garanti à 100% à chaque seconde, en raison de problèmes de planification du processus.
La valeur par défaut de 1 est requise pour une conformité ACID complète. Vous pouvez obtenir de meilleures performances en définissant une valeur différente de 1, mais vous pouvez alors perdre jusqu'à une seconde de transactions dans un crash. Avec une valeur de 0, tout plantage du processus mysqld peut effacer la dernière seconde des transactions. Avec une valeur de 2, seul un plantage du système d'exploitation ou une panne de courant peut effacer la dernière seconde des transactions. La récupération après incident d'InnoDB fonctionne quelle que soit la valeur.
À mon avis, en utilisant innodb_flush_log_at_trx_commit à 2 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: c'est mon ordinateur de développement ou ma mini base de données domestique où il n'y a pas de données sensibles.
innodb_flush_log_at_trx_commit = 2 si: c'est blog/stats/e-commerce (avec ~ 100x boutique en jour), etc.
innodb_flush_log_at_trx_commit = 1 si: vous avez beaucoup de clients ou vous devez travailler avec une transaction monétaire comme une banque. cette fois, vous devez répartir votre flux de données entre plusieurs serveurs pour bénéficier de la vitesse et de la sécurité.
Je préfère 2, car il a une vitesse d'écriture 75 fois plus rapide et il échoue UNIQUEMENT si le matériel tombe en panne.
Quoi qu'il en soit, vous devriez savoir ce dont vous avez besoin de beaucoup plus de vitesse d'écriture ou jusqu'à 1 seconde d'informations?
J'essaie de répondre à quoi sert innodb_flush_log_at_trx_commit?
InnoDB effectue la plupart de ses opérations dans la mémoire (InnoDB Buffer Pool). Toutes les données modifiées sont écrites dans InnoDB transaction log file Puis vidées (écrites) sur 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, la validation sur disque pour chaque transaction est un processus coûteux.
Les E/S disque sont un processus de blocage et elles sont très lentes, il s'agit d'un disque lent, cela réduira encore le nombre de InnoDB transaction per seconds (Débit du disque).
InnoDB fournit une variable innodb_flush_log_at_trx_commit Pour contrôler la fréquence de cette opération de vidage. En fonction de la valeur, l'opération de rinçage InnoDB se comporte différemment.
(Déjà expliqué dans d'autres réponses)
0 - Écrire dans le fichier journal et vider le disque à chaque seconde (les données sont dans le pool de tampons non écrites dans le fichier journal - pour un gain de performances). 1 - Vider le disque lorsqu'une transaction est validée - par défaut (pour la sécurité des données - Conformité ACID) 2 - écrire dans le fichier journal pour chaque transaction et vider le disque à chaque seconde. (Pour un gain de performance)
En fonction des exigences 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érable, en cas de plantage ou d'échec, mais pas en 0.
Dans de nombreux cas, le vidage sur disque est un moyen, les données sont écrites à partir de InnoDB buffer pool (memory) to Operating systems cache pas réellement écrites sur le disque de stockage (stockage permanent). En cas d'échec, au pire des cas, vous risquez de perdre des données jusqu'à une seconde)
Le gain de performances 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 = 1 Et sync_binlog=1.
Si les performances sont l'objectif principal de l'application, InnoDB fournit une variable pour contrôler la fréquence de vidage des journaux - innodb_flush_log_at_timeout - qui vous permet de définir la plage de fréquences de vidage des journaux à partir de 1 to 2700 seconds, Par défaut, il s'agit de 1.
Sachez que lorsque vous augmentez l'intervalle de rinçage jusqu'à N secondes, le gain de performances s'accompagne d'un compromis sur la sécurité des données jusqu'à N secondes. Par exemple - si vous définissez le rinçage 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 vidage InnoDB et validation de transaction .
Vous pouvez changer après avoir fait le mode 2 sur aws rds:
Non modifiable dans certains cas comme si vous avez la réplication multi a-z:
Si votre matériel tombe en panne, vous pouvez perdre toutes vos données, donc j'utilise param = 2 sans aucun souci. Quoi qu'il en soit, vous pouvez répartir vos données sensibles (commande, argent virtuel, ...) et régulières (statistiques, panier, ...) entre 2 serveurs db et les garder en sécurité et rapidement. Pour les transactions entre bases de données, vous pouvez utiliser http://dev.mysql.com/doc/refman/5.7/en/xa.html