Il y aura toujours un compromis entre la résilience et la performance.
Avec MySQL sur ext4, les barrières = 1 par défaut provoquent en effet un ralentissement, cependant la première action ne doit pas être de désactiver la journalisation ou d'activer data = writeback.
Premièrement, si la résilience est d'une grande importance, un RAID soutenu par batterie en vaut certainement la peine.
Les options de montage que j'ai choisies, en particulier sur un RAID sans batterie, sont:
/dev/mapper/vg-mysql--data /var/lib/mysql/data ext4 defaults,noatime,nodiratime,barrier=1,data=ordered 0 0
Ceci n'utilise pas intentionnellement data = writeback parce que je ne veux pas risquer une corruption du système de fichiers entraînant "d'anciennes données à apparaître dans les fichiers après un crash et une récupération du journal" (citation de man mount).
La configuration idéale dans my.cnf pour une résilience complète autour des paramètres liés aux E / S est:
[mysqld]
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
J'ai opté pour la séquence de compromis suivante pour augmenter les performances:
sync_binlog = 0: c'est la première config MySQL que je change loin de la pleine résilience. La raison en est qu'il donne une amélioration significative des performances, en particulier là où binlog_format=row(malheureusement requis pour Jira). J'utilise suffisamment de répliques MySQL dans le cluster que si le binlog venait à être corrompu par un scénario de perte de puissance, je ferais une copie binaire d'une autre réplique.innodb_flush_log_at_trx_commit = 2: Bien qu'une valeur de 1 soit requise pour une conformité ACID complète, avec une valeur de 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 sur le le 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. " (citation de la documentation MySQL)- Mettez à jour les options de montage à utiliser
data=writeback. Notez que s'il s'agit de votre système de fichiers racine, vous devrez également passer une option de ligne de commande du noyau. J'ai mis en place quelques étapes à ce sujet à coderwall .
- Testez différentes valeurs de
innodb_flush_method. Il est démontré qu'O_DIRECT améliore les performances dans certaines charges de travail, mais cela ne va pas de soi que cela fonctionnera dans votre environnement.
- Mise à niveau vers les disques SSD, dans ce cas , vous aurez également besoin d'augmenter
innodb_io_capacity, et les paramètres syntoniser tels que innodb_adaptive_flushing, innodb_read_io_threads, innodb_write_io_threads, innodb_purge_threadset d' autres paramètres possibles.