web-dev-qa-db-fra.com

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

Je suis donc assez nouveau pour régler InnoDB. Je change lentement les tables (si nécessaire) de MyIsam à InnoDB. J'ai environ 100 Mo en innodb, j'ai donc augmenté le innodb_buffer_pool_size variable à 128 Mo:

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

Quand je suis allé changer le innodb_log_file_size valeur (exemple my.cnf sur page de configuration innodb de mysql commentaires pour changer la taille du fichier journal à 25% de la taille du tampon. Alors maintenant 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 tampons, taille = 128,0 M
110216 9:48:41 InnoDB: initialisation terminée du pool de tampons
InnoDB: Erreur: le fichier journal ./ib_logfile0 est de taille différente 0 5242880 octets
InnoDB: que spécifié dans le fichier .cnf 0 33554432 octets!
110216 9:48:41 [ERREUR] La fonction d'initialisation 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é.

Donc, ma question: est-il sûr de supprimer les anciens fichiers log_files, ou existe-t-il une autre méthode pour modifier le innodb_log_file_size variable?

mysqlinnodbmyisamlogs
108
Derek Downey

Oui, il est sûr de supprimer le fichier journal une fois mysqld arrêté

À la lumière de cela, effectuez simplement les étapes suivantes:

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

Le démarrage de mysqld recréera ib_logfile0 et ib_logfile1

Essaie !!!

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

Il page proprement toutes les données dans le pool de tampons InnoDB avant de refaire les fichiers journaux, vous devez définir cette option environ 1 heure avant l'arrêt:

SET GLOBAL innodb_max_dirty_pages_pct = 0;

Par défaut, innodb_max_dirty_pages_pct est 75 (MySQL 5.5+) ou 90 (avant MySQL 5.5). La définition de ce paramètre à zéro maintient le nombre de pages sales sous 1% du pool de tampons InnoDB. Exécution service mysql stop le fait quand même. De plus, un arrêt terminera 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 ma réponse un peu plus avec innodb_fast_shutdown parce que j'avais l'habitude de redémarrer mysql et d'arrêter mysql pour ce faire. Maintenant, cette étape est vitale car chaque transaction non validée peut avoir d'autres pièces mobiles à l'intérieur et à l'extérieur des journaux de transactions InnoDB ( Voir Infrastructure InnoDB ).

Veuillez noter que le réglage innodb_fast_shutdown à 2 permettrait également de nettoyer les journaux mais plus de pièces mobiles existent encore et sont récupérées sur Crash Récupération lors du démarrage de mysqld. Le réglage de 0 est le meilleur.

86
RolandoMySQLDBA

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 version antérieure , utilisez les instructions suivantes. La procédure à utiliser dépend de la valeur de innodb_fast_shutdown, qui détermine s'il faut mettre à jour ou non l'espace disque logique système 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'arrête sans erreur, pour vous assurer qu'il n'y a pas d'informations sur les transactions en attente dans le journal de rétablissement. Copiez les anciens fichiers journaux de rétablissement dans un endroit sûr, au cas où quelque chose se serait mal passé lors de l'arrêt et que vous en auriez besoin pour récupérer l'espace disque logique. Supprimez les anciens fichiers journaux du répertoire des fichiers journaux, modifiez my.cnf pour modifier la configuration du fichier journal et redémarrez le serveur MySQL. mysqld voit 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 de l'élément 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 la taille innodb_log_file_size diffère de la taille du fichier de journalisation, il écrit un point de contrôle de journal, ferme et supprime les anciens fichiers journaux, crée de nouveaux fichiers journaux à la taille demandée et ouvre les nouveaux fichiers journaux.

31
RandomSeed

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

innodb_log_file_size est moins critique. Ne le changez que s'il y a une raison. Roland à condition 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 affaires non terminées; " innodb_fast_shutdown "dit de faire face à ce genre de choses après redémarrage. La suppression des fichiers peut donc 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_size peut être modifié sans supprimer d'abord iblog *
  • 5.7 permet de redimensionner dynamiquement innodb_buffer_pool_size

Dois-je changer log_file_size?

Utilisation GLOBAL STATUS pour calculer le nombre de minutes avant les cycles de journalisation.

Uptime / 60 * innodb_log_file_size / Innodb_os_log_written`

Si elle est beaucoup moins supérieure à 60 (minutes), cela peut aider à augmenter log_file_size. Si c'est beaucoup plus, les fichiers journaux gaspillent de l'espace disque. Cette "1 heure" est plutôt arbitraire, donc si vous en êtes proche, ne vous embêtez pas à changer la taille de log_file_size.

Partir innodb_log_files_in_group par défaut 2.

22
Rick James

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 obtiendrez deux numéros. D'abord, vous en obtenez un, puis attendez une minute. Vous en obtiendrez 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 de = 13,856 Mo

Vous disposez de deux fichiers journaux. Alors divisez-le par deux et vous obtiendrez un nombre proche de 7 000 Mo. Juste pour être sûr, définissez la taille de votre fichier journal 8 Go

2
Linux Newbie