J'essaie d'ajouter une ligne à une table InnoDB avec une simple requête:
INSERT INTO Zip_codes (Zip_code, city) VALUES ('90210', 'Beverly Hills');
Mais lorsque je tente cette requête, je reçois le texte suivant:
ERROR 1114 (HY000): The table `Zip_codes` is full
Faire un "SELECT COUNT (*) FROM Zip_codes" me donne 188 959 lignes, ce qui ne semble pas trop, vu que j'ai une autre table avec 810 635 lignes dans cette même base de données.
Je suis assez peu expérimenté avec le moteur InnoDB et n'ai jamais rencontré ce problème avec MyISAM. Quels sont certains des problèmes potentiels ici?
EDIT: Cela ne se produit que lors de l'ajout d'une ligne à la table Zip_codes.
EDIT: Première vérification, si vous n'avez pas manqué d’espace disque, avant de passer à la résolution liée à la configuration.
Vous semblez avoir une taille maximale trop basse pour votre innodb_data_file_path
dans votre my.cnf
, dans cet exemple
innodb_data_file_path = ibdata1:10M:autoextend:max:512M
vous ne pouvez pas héberger plus de 512 Mo de données dans toutes les tables innodb combinées.
Peut-être devriez-vous passer à un schéma innodb-per-table utilisant innodb_file_per_table
.
Une autre raison possible est que la partition est pleine. C'est ce qui m'est arrivé maintenant.
Vous obtiendrez également la même erreur ERREUR 1114 (HY000): la table '# sql-310a_8867d7f' est pleine
si vous essayez d'ajouter un index à une table utilisant le moteur de stockage MEMORY.
Vous devez modifier le plafond défini dans my.cnf pour les tables INNO_DB. Cette limite de mémoire n'est pas définie pour des tables individuelles, elle est définie pour toutes les tables combinées.
Si vous voulez que la mémoire s’étende automatiquement à 512 Mo
innodb_data_file_path = ibdata1:10M:autoextend:max:512M
Si vous ne connaissez pas la limite ou si vous ne souhaitez pas définir de limite, vous pouvez le modifier comme ceci.
innodb_data_file_path = ibdata1:10M:autoextend
Cette erreur apparaît également si la partition sur laquelle réside tmpdir
se remplit (en raison d’une table alter ou autre).
Dans mon cas, c'était parce que la partition hébergeant le fichier ibdata1 était pleine.
Il est possible que vous manquiez d’espace dans la partition où sont stockées les tables mysql (généralement/var/lib/mysql) ou dans celles où les tables temporaires sont stockées (habituellement/tmp).
Vous souhaiterez peut-être: - surveiller votre espace libre lors de la création de l'index. - pointez la variable tmpdir MySQL vers un emplacement différent. Cela nécessite un redémarrage du serveur.
Si vous utilisez NDBCLUSTER comme moteur de stockage, augmentez DataMemory
et IndexMemory
.
J'ai aussi fait face à cette erreur lors de l'importation d'un fichier de base de données SQL de 8 Go. Vérifié mon lecteur d'installation mysql. Il n'y avait plus d'espace libre dans le lecteur. Donc, j'ai eu de la place en supprimant les éléments non désirés et en réexécutant la commande d'importation de ma base de données. Cette fois c'était réussi.
Sauf si vous avez activé l'option innodb_file_per_table
, InnoDB
conserve toutes les données dans un seul fichier, généralement appelé ibdata1
.
Vérifiez la taille de ce fichier et vérifiez que vous avez suffisamment d'espace disque dans le lecteur sur lequel il réside.
nous avions: SQLSTATE [HY000]: Erreur générale: 1114 La table 'catalog_product_index_price_bundle_sel_tmp' est pleine
résolu par:
modifier la configuration de la base de données:
nano /etc/my.cnf
tmp_table_size = 256M max_heap_table_size = 256M
Pour citer les documents MySQL.
Le moteur de stockage InnoDB conserve les tables InnoDB dans un espace de table pouvant être créé à partir de plusieurs fichiers. Cela permet à une table de dépasser la taille maximale d'un fichier individuel. Le tablespace peut inclure des partitions de disque brutes, ce qui permet des tables extrêmement volumineuses. La taille maximale de l'espace table est de 64 To.
Si vous utilisez des tables InnoDB et que vous manquez de place dans l'espace de table InnoDB. Dans ce cas, la solution consiste à étendre l'espace de table InnoDB. Voir Section 13.2.5, «« Ajout, suppression ou redimensionnement de fichiers de données et de fichiers de log InnoDB ».]
Je rencontrais ce problème ... Dans mon cas, je n'avais plus assez de stockage sur mon serveur dédié. Vérifiez que si tout le reste échoue et envisagez d'augmenter l'espace disque ou de supprimer les données ou fichiers indésirables.
UTILISATEURS DOCKER: Cela se produit également lorsque vous avez atteint environ 90% de votre limite de taille d'image Docker (il semble que 10% soit nécessaire pour la mise en cache, par exemple). La formulation est déroutante, car elle signifie simplement la quantité d’espace disque que Docker peut utiliser pour pratiquement tout.
Pour résoudre ce problème, accédez aux paramètres de votre bureau Docker> Disque> déplacez le curseur un peu plus à droite> Appliquer.
Dans mon cas, la mémoire du serveur était saturée, de sorte que la base de données ne pouvait pas écrire les données temporaires. Pour le résoudre, il vous suffit de vous placer sur votre disque.
dans mon cas, c'est simplement parce que le serveur mysql s'exécute avec une application, qui écrit trop de journaux pour que le disque soit plein.
vous pouvez vérifier si le disque dispose de suffisamment d'espace
df -h
si le pourcentage d'utilisation du disque est de 100%, vous pouvez utiliser cette commande pour rechercher le répertoire trop volumineux
du -h -d 1 /
J'ai rencontré le même problème en raison de l'espace disque insuffisant. Et la partition hébergeant le fichier ibdata1, qui est le tablespace système de l'infrastructure InnoDB, était saturée.
Dans mon cas, j'essayais d'exécuter une commande alter table et l'espace disque disponible était inférieur à la taille de la table. Une fois, j'ai augmenté l'espace disque, le problème a disparu.
J'ai résolu ce problème en augmentant la quantité de mémoire disponible pour le vagabond VM où se trouvait la base de données.
Sur CentOS 7, arrêter et démarrer le service MySQL simplement m'a corrigé.
Sudo service mysql stop
Sudo service mysql start