Modifier le innodb_log_file_size
Si vous avez des tables InnoDB avec un gros load d’écriture (insert, update), il est généralement recommandé d’avoir un innodb_log_file_size assez élevé. En effet, plus la grosseur du log file est élevée, plus le temps de recovery est long dans le cas d’un crash.
InnoDB est un engine capricieux et innodb_log_file_size est l’un de ses caprices. Les logs jouent un rôle très important dans plusieurs concepts d’InnoDB. Il y stock un tas d’information comme le schéma de certains .frm et d’autres metadata. Le problème est qu’on ne peut pas simplement modifier la grosseur du log dans le my.cnf et repartir le serveur. En fait oui, c’est possible et le serveur ne fera pas d’erreur. Mais aucune table InnoDB ne sera utilisable.
Voici comment il faut faire :
• On s’assure que la variable innodb_fast_shutdown ne vaut pas 2.
Si la valeur de innodb_fast_shutdown est 2, il faut la changer pour 1, arrêter le serveur, le repartir, et l’arrêter de nouveau. Ceci permet à InnoDB de fermer correctement.
• On arrête le serveur
• On modifie la configuration
• On renomme le fichier log lui-même
• On repart le serveur
InnoDB est un engine capricieux et innodb_log_file_size est l’un de ses caprices. Les logs jouent un rôle très important dans plusieurs concepts d’InnoDB. Il y stock un tas d’information comme le schéma de certains .frm et d’autres metadata. Le problème est qu’on ne peut pas simplement modifier la grosseur du log dans le my.cnf et repartir le serveur. En fait oui, c’est possible et le serveur ne fera pas d’erreur. Mais aucune table InnoDB ne sera utilisable.
Voici comment il faut faire :
• On s’assure que la variable innodb_fast_shutdown ne vaut pas 2.
Si la valeur de innodb_fast_shutdown est 2, il faut la changer pour 1, arrêter le serveur, le repartir, et l’arrêter de nouveau. Ceci permet à InnoDB de fermer correctement.
• On arrête le serveur
• On modifie la configuration
• On renomme le fichier log lui-même
• On repart le serveur
En renommant le fichier, MySQL va recréer un nouveau log avec la nouvelle grosseur spécifiée dans la configuration au redémarrage. Si tout se déroule bien, on peut supprimer l’ancien log qu’on a renommé.
Par contre, si quelque chose tourne mal, il est possible de remettre l’ancienne valeur de innodb_log_file_size, delete le nouveau log file et remettre l’ancien qui a été renommé.
InnoDB s’attend toujours à avoir un log de la même grosseur. En modifiant l’option, la grosseur spécifiée dans la configuration et la grosseur réelle du fichier ne concordent plus. C’est pour cette raison que nous devons en recréer un tout neuf, avec la bonne grosseur.
Si vous avez oublié de renommer l’ancien log file, MySQL ne vous indiquera pas que c’est le innodb_log_file_size qui est le problème. Vous aurez tout simplement des erreurs lorsque vous tenterez d’accéder ou écrire dans une table InnoDB.
Par contre, si quelque chose tourne mal, il est possible de remettre l’ancienne valeur de innodb_log_file_size, delete le nouveau log file et remettre l’ancien qui a été renommé.
InnoDB s’attend toujours à avoir un log de la même grosseur. En modifiant l’option, la grosseur spécifiée dans la configuration et la grosseur réelle du fichier ne concordent plus. C’est pour cette raison que nous devons en recréer un tout neuf, avec la bonne grosseur.
Si vous avez oublié de renommer l’ancien log file, MySQL ne vous indiquera pas que c’est le innodb_log_file_size qui est le problème. Vous aurez tout simplement des erreurs lorsque vous tenterez d’accéder ou écrire dans une table InnoDB.