Première fois que je voyais cette erreur... Sans avoir touché à la configuration ou à quoi que ce soit sur le serveur de mon client, cette erreur 1033 est arrivée soudainement, sans qu'on sache vraiment pourquoi.

Après avoir testé différentes façon de la régler sans succès, et même m'être fait une frayeur en pensant que j'avais corrompu toutes les bases de données du serveur, j'ai enfin fini par trouver une solution fonctionnelle.

L'explication de cette erreur est la suivante : la base de données qui a été montée pour notre projet tourne avec InnoDB. Et de par le fait qu'InnoDB est un moteur de "multi-versionning", il fonctionne non seulement avec les fichiers "frm" de la base de données, mais également avec plusieurs fichiers de type ib_logfile et ibdata.

Avant d'avoir résolu le problème, j'avais 3 fichiers :

• ibdata1
• ib_logfile0
• ib_logfile1

Le fichier ibdata1 contient les différentes versions de données de la base de données, il est donc indispensable au bon fonctionnement du système.

Ces fichiers ont une taille qui est définie à l'avance par MySQL. Les fichiers de log faisaient 5Mo et le fichier ibdata 18Mo. Et c'est là que le problème survenait... Au départ, ces fichiers sont construit avec leur taille finale, leur contenu étant simplement des 0. Mais une fois que ces fichiers sont remplis de données, si la taille des données arrive à hauteur de la taille du fichier, alors MySQL ne peut plus y insérer de nouvelles entrées et désactive le support InnoDB. C'est pour cette raison que l'erreur 1033 survient tout d'un coup sans crier gare.

Bref. La difficulté se situait dans la manière de faire pour pouvoir augmenter la taille de ces fichiers. Le fichier ibdata étant indispensable au système, si on le supprime, alors la ou les bases de données qui y puisent des données ne seront plus fonctionnelles. Le problème étant qu'avec cette erreur, il est impossible de faire un dump sur les bases de données, donc aucune sauvegarde à disposition... Les fichiers de log standard sont d'une grande utilité pour essayer de comprendre ou se situe le problème :

Oct 21 08:00:07 srv mysqld[9654]:
InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 1048576 bytes!
...
...
Oct 21 08:25:23 srv mysqld[14022]:
InnoDB: Error: data file ./ibdata1 is of a different size
InnoDB: 1152 pages (rounded down to MB)
InnoDB: than specified in the .cnf file 32768 pages!
InnoDB: Could not open or create data files.
InnoDB: If you tried to add new data files, and it failed here,
InnoDB: you should now edit innodb_data_file_path in my.cnf back
InnoDB: to what it was, and remove the new ibdata files InnoDB created
InnoDB: in this failed attempt. InnoDB only wrote those files full of
InnoDB: zeros, but did not yet use them in any way. But be careful: do not
InnoDB: remove old data files which contain your precious data!

Tout d'abord, il est nécessaire de fermer MySQL :

srv:# cd /etc/init.d
srv:/etc/init.d# ./mysql stop

Puis ensuite, il faut éditer le fichier my.cnf (dans mon cas situé dans /etc/mysql/) pour y rajouter la ligne suivante dans la section [mysqld] :

innodb_data_file_path=ibdata1:18M;ibdata2:100M:autoextend

Comme on peut le voir, je spécifie que le fichier ibdata1 doit faire 18Mo (sa taille actuelle... Il faut qu'il garde sa taille actuelle sinon MySQL ne le reconnaitra plus en tant que fichier de données) et je rajoute un second fichier ibdata2 qui doit faire 100Mo avec une possibilité d'auto-extension. Dès que sa taille va dépasser les 100Mo, il s'incrémentera par pas de 8Mo à chaque fois que ça sera nécessaire.

Enfin, il faut supprimer les fichiers ib_logfile0 et ib_logfile1 pour que MySQL les reconstruisent correctement avec une nouvelle taille.

La dernière opération est de relancer MySQL :

srv:# cd /etc/init.d
srv:/etc/init.d# ./mysql start

Une fois que MySQL redémarre, il va recréer les différents fichiers tout en gardant le fichier ibdata1 tel qu'il est, afin de ne pas corrompre les données.

Oct 21 08:45:25 srv mysqld[21548]:
081021 8:45:25 InnoDB: Data file ./ibdata2 did not exist: new to be created
081021 8:45:25 InnoDB: Setting file ./ibdata2 size to 100 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Progress in MB: 100
081021 8:45:31 InnoDB: Log file ./ib_logfile0 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile0 size to 1 MB
InnoDB: Database physically writes the file full: wait...
081021 8:45:32 InnoDB: Log file ./ib_logfile1 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile1 size to 1 MB
InnoDB: Database physically writes the file full: wait...
081021 8:45:32 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
081021 8:45:33 InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 63329292.
InnoDB: Doing recovery: scanned up to log sequence number 0 63329292
InnoDB: Last MySQL binlog file position 0 3567, file name /var/log/mysql/mysql-bin.000266
081021 8:45:33 InnoDB: Started; log sequence number 0 63329292
081021 8:45:33 [Note] /usr/sbin/mysqld: ready for connections.

ATTENTION !!!!!!
Avant d'effectuer une quelconque opération, je ne saurais que trop vous mettre en garde de tenter une sauvegarde de vos données, soit via mysqldump pour créer des scripts sql, soit de faire des copies des répertoires de vos bases de données, et également des copies des fichiers ib_logfile0, ib_logfile1 et ibdata1 au cas où la manipulation ne fonctionnerai pas du premier coup.

Sources :
ERROR 1033 (HY000) on InnoDB configuration error
MySQL: ibdata files do not shrink on database deletion [innodb]
MySQL : 13.2.7. Adding and Removing InnoDB Data and Log Files