Comment changer en toute sécurité la variable innodb MySQL 'innodb_log_file_size'?

105

Je suis donc relativement novice dans le réglage d'InnoDB. Je change lentement de table (si nécessaire) de MyIsam à InnoDB. J'ai environ 100 Mo dans innodb, alors j'ai augmenté la innodb_buffer_pool_sizevariable à 128 Mo:

mysql> show variables like 'innodb_buffer%';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| innodb_buffer_pool_size | 134217728 |
+-------------------------+-----------+
1 row in set (0.00 sec)

Lorsque je suis allé modifier la innodb_log_file_sizevaleur (par exemple, mon.cnf dans les commentaires de la page de configuration innodb de mysql pour modifier la taille du fichier journal à 25% de la taille de la mémoire tampon. Alors, mon my.cnf ressemble à ceci:

# innodb
innodb_buffer_pool_size = 128M
innodb_log_file_size = 32M

Lorsque je redémarre le serveur, j'obtiens cette erreur:

110216 9:48:41 InnoDB: initialisation du pool de mémoire tampon, taille = 128,0M
110216 9:48:41 InnoDB: initialisation terminée du pool de mémoire tampon
InnoDB: erreur: le fichier journal ./ib_logfile0 est de taille différente 0 5242880 octets
InnoDB: supérieur à celui spécifié le fichier .cnf 0 33554432 octets!
110216 9:48:41 [ERROR] La fonction init du plugin 'InnoDB' a renvoyé une erreur.
110216 9:48:41 [ERREUR] L'enregistrement du plugin 'InnoDB' en tant que MOTEUR DE STOCKAGE a échoué.

Ma question est donc la suivante: est-il prudent de supprimer les anciens fichiers journaux, ou existe-t-il une autre méthode pour modifier la innodb_log_file_sizevariable?

Derek Downey
la source
1
Il suffit de commenter innodb_log_file_size dans my.ini .....
5
hmm, pourquoi voudrais-je le commenter pour utiliser la valeur par défaut lorsque j'essaie de la changer par rapport à la valeur par défaut?
Derek Downey
Oui en commentant la ligne innodb_log_file_size ses travaux .. Merci.
muhammad umar farooq franc
2
@muhammadumarfarooqfrank Bien sûr, cela fonctionne - parce que vous ne modifiez plus la valeur de la variable, rendant ainsi le point entier inutile. J'aimerais qu'il y ait un moyen de réduire les commentaires.
dr01

Réponses:

83

Oui, il est prudent de supprimer le fichier journal une fois que mysqld a été arrêté.

À la lumière de cela, procédez comme suit:

mysql -uroot -p... -e"SET GLOBAL innodb_fast_shutdown = 0"
service mysql stop
mv /var/lib/mysql/ib_logfile[01] /tmp
service mysql start

Démarrez mysqld recréera ib_logfile0etib_logfile1

Essaie !!!

MISE À JOUR 2011-10-20 16:40 EDT

Avant de refaire les fichiers journaux, vous devez définir cette option environ 1 heure avant la fermeture de la page: toutes les données du pool de mémoire tampon InnoDB doivent être définies proprement.

SET GLOBAL innodb_max_dirty_pages_pct = 0;

Par défaut, innodb_max_dirty_pages_pct est égal à 75 (MySQL 5.5+) ou à 90 (antérieur à MySQL 5.5). Si vous définissez cette valeur à zéro, le nombre de pages non conformes est inférieur à 1% du pool de mémoire tampon InnoDB. Effectuer service mysql stopcela fait quand même. En outre, un arrêt finira tous les éléments restants dans le journal de rétablissement. Pour conserver cette option, ajoutez-la simplement à /etc/my.cnf:

[mysqld]
innodb_max_dirty_pages_pct = 0

MISE À JOUR 2013-04-19 16:16 EDT

J'ai mis à jour un peu plus ma réponse avec innodb_fast_shutdown car j'avais l'habitude de redémarrer mysql et d'arrêter mysql pour le faire. Désormais, cette étape est essentielle car chaque transaction non validée peut comporter d’autres éléments mobiles à l’intérieur et à l’extérieur des journaux de transactions InnoDB ( voir Infrastructure InnoDB ).

Veuillez noter que définir innodb_fast_shutdown sur 2 effacerait également les journaux, mais qu'il resterait encore des pièces mobiles et qu'il serait sélectionné lors de la récupération après un crash au démarrage de mysqld. La valeur 0 est la meilleure.

RolandoMySQLDBA
la source
1
Bonne réponse et la mise à jour est excellente aussi. Ma seule suggestion serait de copier les ib_logfiles à un autre endroit au cas où quelque chose se passe mal. Cela vous aidera à avoir une idée sur la façon de dimensionner les fichiers: mysqlperformanceblog.com/2011/07/09/…
Justin Noel
5
Cela a également fonctionné pour moi, MAIS: L’UI de la console linux peut être trompeuse: le démarrage de mysqld prend beaucoup de temps si vous définissez une taille de fichier journal importante (plusieurs centaines de Mo ou plus). L’interface utilisateur de la console vous montre des points, puis indique «échec!», Mais en fait, MySQL est toujours en cours de démarrage. Attendez et continuez à lire le fichier journal (ou surveillez le fichier journal avec "tail -f [fichier-journal]") jusqu'à ce que vous voyiez "mysqld: prêt pour les connexions". et les deux fichiers journaux alloués sur le disque.
f055
2
ATTENTION!! L'étape 3 n'a pas fonctionné pour moi et mon cœur s'est presque arrêté lorsque j'ai vu mysql se charger sans InnoDB. J'ai dû arrêter mysql, les supprimer manuellement et redémarrer MySQL. deux conseils: 1. sauvegardez vos fichiers journaux existants, 2. supprimez les fichiers manuellement
Peeyush Kushwaha
2
Peeyush est correct. Même la documentation de mysql recommande de sauvegarder vos fichiers de log au cas où quelque chose se passe mal
Greg
1
@Greg c'est pourquoi j'utilise SET GLOBAL innodb_fast_shutdown = 0;. Lorsque MySQL s'arrête, toutes les transactions sont effacées de toutes les pièces mobiles, y compris les journaux de restauration (ib_logfile0 et ib_logfile1). On peut les garder. Je n'ai pas encore rencontré de problèmes avec les journaux complètement vidés.
RolandoMySQLDBA
31

Je recommanderais plutôt la méthode officielle , que je reproduis ici pour plus de commodité:

Pour modifier le nombre ou la taille des fichiers journaux InnoDB dans MySQL 5.6.7 ou une version antérieure , utilisez les instructions suivantes. La procédure à utiliser dépend de la valeur de innodb_fast_shutdown, qui détermine si le tablespace système doit être complètement mis à jour avant une opération d'arrêt:

  • Si innodb_fast_shutdown n'est pas défini sur 2: arrêtez le serveur MySQL et assurez-vous qu'il s'éteigne sans erreur, afin de vous assurer qu'il n'y a aucune information sur les transactions en attente dans le journal de restauration. Copiez les anciens fichiers de journalisation dans un endroit sûr, en cas de problème lors de l’arrêt et vous en aurez besoin pour récupérer l’espace de table. Supprimez les anciens fichiers journaux du répertoire des fichiers journaux, éditez my.cnf pour modifier la configuration du fichier journal et redémarrez le serveur MySQL. mysqld constate qu'aucun fichier journal InnoDB n'existe au démarrage et en crée de nouveaux.

  • Si innodb_fast_shutdown est défini sur 2: définissez innodb_fast_shutdown sur 1:

mysql> SET GLOBAL innodb_fast_shutdown = 1;

Suivez ensuite les instructions du point précédent.

Depuis MySQL 5.6.8 , le paramètre innodb_fast_shutdown n’est plus pertinent lors de la modification du nombre ou de la taille des fichiers journaux InnoDB. En outre, vous n'êtes plus obligé de supprimer les anciens fichiers journaux, bien que vous souhaitiez toujours copier les anciens fichiers journaux dans un endroit sûr, en tant que sauvegarde. Pour modifier le nombre ou la taille des fichiers journaux InnoDB, procédez comme suit:

  1. Arrêtez le serveur MySQL et assurez-vous qu'il s'arrête sans erreur.

  2. Modifiez my.cnf pour modifier la configuration du fichier journal. Pour modifier la taille du fichier journal, configurez innodb_log_file_size. Pour augmenter le nombre de fichiers journaux, configurez innodb_log_files_in_group.

  3. Redémarrez le serveur MySQL.

Si InnoDB détecte que innodb_log_file_size diffère de la taille du fichier journal redo, il écrit un point de contrôle du journal, ferme et supprime les anciens fichiers journaux, crée de nouveaux fichiers journaux à la taille requise et ouvre les nouveaux fichiers journaux.

RandomSeed
la source
C'est une bonne réponse pour mettre à jour cette question. +1 !!!
RolandoMySQLDBA
2
Ce n'est pas une "mise à jour". Ces pages de manuel existent depuis longtemps. Je recommande toujours des informations de première main tirées du manuel (l'un des meilleurs manuels sur le marché) plutôt que de réinventer la roue et de dupliquer les informations (ce que les DBA détestent le plus).
RandomSeed
C'est la méthode préférée à partir de MySQL 5.6. Si vous utilisez toujours une version antérieure à la 5.6, cela ne fonctionnera pas.
Derek Downey
20

innodb_buffer_pool_size- changez simplement my.cnf( my.ini) et redémarrez mysqld.

innodb_log_file_sizeest moins critique. Ne le changez pas sauf s'il y a une raison. Roland a fourni les étapes , mais un aspect m'inquiète ... Je ne sais pas si les deux premières étapes sont importantes; il semble qu'ils pourraient être:

  1. set innodb_fast_shutdown = OFF
  2. redémarrer mysql
  3. arrêtez mysql
  4. supprimer les fichiers journaux
  5. démarrer mysql

Les fichiers journaux gardent une trace des travaux non terminés; " innodb_fast_shutdown" dit de traiter avec ce truc après le redémarrage. Donc, supprimer les fichiers peut perdre des informations?

Les nouvelles versions ont amélioré les choses: (plus de discussion dans les commentaires)

  • 5.6 Permet innodb_log_file_size> 4 Go
  • 5.6 innodb_log_file_sizepeut être modifié sans supprimer au préalable iblog *
  • 5.7 permet un redimensionnement dynamique innodb_buffer_pool_size

Devrais-je changer log_file_size?

Utilisez GLOBAL STATUSpour calculer le nombre de minutes avant que le journal se cycle.

Uptime / 60 * innodb_log_file_size / Innodb_os_log_written`

Si la durée est beaucoup inférieure à 60 minutes, il peut être utile d’augmenter log_file_size. Si c'est beaucoup plus, les fichiers journaux gaspillent de l'espace disque. Ce "1 heure" est plutôt arbitraire, donc si vous en êtes proche, ne vous embêtez pas de changer le log_file_size.

Laissez innodb_log_files_in_groupau défaut 2.

Rick James
la source
+1 votre inquiétude semble être soutenue par les docs
Jack Douglas
J'ai jeté un coup d'œil à cette réponse et j'aime bien la première ligne. J'avais l'habitude --skip-networkingde demander à mes clients d'amener mysql par terre avec précaution pour que les changements de dernière minute soient résolus. Votre première ligne (set innodb_fast_shutdown = OFF) l’élimine. +1 !!!
RolandoMySQLDBA
1
Merci pour les votes positifs. Les nouveaux lecteurs peuvent ne pas avoir besoin de cela. Dans 5.6.8 , a innodb_log_file_sizeété amélioré pour permettre de le changer sans supprimer les fichiers iblog.
Rick James
Dis tu veux dire "plus critique", pas "moins critique"?
Igor
@Igor - Non. Si vous avez log_file_size beaucoup trop petit, il y aura des entrées / sorties supplémentaires qui le traverseront. Je vois rarement ça. Si vous l'avez trop volumineux, vous ne faites que gaspiller de l'espace disque. L’objectif est de le parcourir en une heure. Mais 10 minutes contre 10 heures - ni l'une ni l'autre. plus ...
Rick James
1

Lorsque vous vous connectez à mysql, tapez ces commandes:

pager grep seq;
show engine innodb status \G select sleep(60); show engine innodb status \G

Vous aurez deux chiffres. D'abord, vous en obtenez un, puis attendez une minute. Vous en aurez un autre.

Disons que le premier est 3.456.718.123 et le second est 4.098.873.134

Maintenant (4.098.873.134-3.856.718.123) * 60/1024/1024

Le résultat est = 13.856 MB

Vous avez deux fichiers de log. Divisez-le donc par deux et vous obtiendrez un nombre proche de 7.000 MB. Juste pour être sûr, définissez votre taille de fichier journal de 8 Go

Débutant Linux
la source
1
Il n'est pas évident (du moins pour moi) que cela réponde réellement à la question. Cela semble être une suggestion pour une taille alternative pour le fichier journal, et non pour une modification en toute sécurité de la taille du fichier journal.
RDFozz
1
@RDFozz vous avez raison. Cela ne vous indique pas comment modifier la taille du fichier journal. Cette question explique comment déterminer le nombre pour définir innodb_log_file_size. J'ai déjà répondu à une telle question il y a cinq ans (voir le sous-titre Log File Sizede dba.stackexchange.com/questions/23189/… )
RolandoMySQLDBA
Je voulais seulement aider: / Je sais que ce n'est pas la réponse exacte cependant.
Linux débutant
-4

chown mysql: mysql -R / etc / mysql / var / lib / mysql && cd / var / lib / mysql && rm -f ib_logfile * && service mysql restart || service mysql redémarrer

Essayez-le, garanti pour fonctionner [testé sur Debian 6]

Gregory
la source
2
Cela ne garantit pas un arrêt complet. Cela peut fonctionner en moyenne sur un serveur avec une charge faible, mais ceci n'est pas recommandé si vous vous souciez de l'intégrité de votre base de données.
Emil Vikström,