nous essayons d'améliorer l'efficacité de notre serveur de base de données.
L'une des recommandations de MySQLTunner est d'augmenter la taille de innodb_log_file_size à 12 Go. Comme nous le voyons, ce changement pourrait améliorer considérablement la vitesse et les performances de nos requêtes. Le problème est survenu lorsque nous augmentons ce paramètre de plus de 1 Go, le service ne démarre pas, nous supprimons les journaux, l'arrêtons proprement et ne pouvons toujours pas démarrer avec ce paramètre au-dessus de 1 Go.
Quelques informations: p >
mysql Ver 14.14 Distrib 5.5.62, for debian-linux-gnu innodb_buffer_pool_size = 100G innodb_file_per_table = ON innodb_buffer_pool_instances = 64 innodb_stats_on_metadata = OFF innodb_log_file_size = 1G innodb_log_buffer_size = 8M
Il y a suffisamment d'espace dans les partitions pour conserver cette taille de journal
Merci!
3 Réponses :
Si vous modifiez le paramètre innodb_log_file_size , vous devez supprimer les anciens fichiers journaux. Sinon, Innodb ne démarrera pas correctement si les fichiers existants ne correspondent pas à la taille spécifiée dans le fichier de configuration.
D'un autre côté, innodb_buffer_pool_size doit être réglé à environ 70% de la RAM disponible si vous utilisez InnoDB uniquement.
Nous supprimons déjà le ib_logfile *, y en a-t-il un autre que nous devons supprimer? La RAM totale est d'environ 128 Go.
Ouais, voici le jornal après avoir essayé de démarrer et d'échouer. pastebin.com/J4ZDsEnr
pouvez-vous essayer d'exécuter mysqld avec l'option --verbose?
C'est fou. Donc, si j'exécute MySQL sur un serveur de production et qu'au fil des ans, les besoins en mémoire ont augmenté, je ne peux pas modifier ce paramètre sans supprimer à nouveau quels fichiers ????. Et les gens qui travaillent sur MySQL se disent intelligents ???? Je ne peux pas croire ça
MySql est toujours surprenant je suppose :)
Il est difficile de changer le log_file_size dans cette ancienne version. Pour les étapes, voir https://dba.stackexchange.com/questions/1261/how-to-safely-change-mysql-innodb-variable-innodb-log-file-size/4103#4103
Cependant, je prédis que changer le log_file_size n'aidera pas beaucoup. «Performance» implique généralement quelques requêtes lentes. Le slowlog est-il activé? avec une valeur faible de long_query_time ? Trouvez les quelques pires requêtes; nous pouvons probablement améliorer les performances en les abordant. Étapes à suivre: http://mysql.rjweb.org/doc.php/mysql_analysis
Dans MySQL 5.5, vous ne pouvez pas augmenter la taille du fichier journal innodb au-delà de 4 Go au total. innodb_log_file_size ne peut être que de 4 Go / innodb_log_files_in_group (qui vaut 2 par défaut, et il n'y a aucun avantage à changer cela). Vous pouvez donc définir le fichier journal sur un maximum de 2 Go.
La taille combinée maximale des fichiers journaux est passée à 512 Go dans la version 5.6.3. Encore une fois, innodb_log_file_size doit avoir la taille d'un un fichier journal, donc si vous utilisez plusieurs fichiers journaux, le total ne peut pas dépasser 512 Go.
Je suis d'accord avec la réponse de Rick James selon laquelle l'augmentation de la taille du fichier journal n'est pas une solution magique pour accélérer l'exécution des requêtes. Ça ne fera pas ça.
Il est parfois utile d'augmenter la taille du fichier journal innodb, si le goulot d'étranglement est que vous manquez d'espace journal plus rapidement que les pages sales peuvent être vidées vers le tablespace, car vous avez un trafic d'écriture très élevé. Cela dépend du taux d'écritures, pas de la vitesse des écritures individuelles.
Pour la plupart des applications, deux fichiers journaux de 2 Go suffisent largement. Si ce n'est pas le cas, il est probablement temps d'exécuter plusieurs instances MySQL et de répartir votre trafic d'écriture sur elles aussi régulièrement que possible.
Combien de RAM avez-vous?
Dup de dba.stackexchange.com/questions/1261/...