web-dev-qa-db-fra.com

Corruption de la base de données avec MariaDB: la table n'existe pas dans le moteur

Je suis dans une configuration d’environnement, tournant sous OSX avec MariaDB 10.0.12-MariaDB Homebrew

J'ai foiré l'installation, j'ai donc complètement supprimé MySQL et MariaDB de ma configuration et je l'ai redémarré.

Après avoir terminé d’installer MariaDB, j’ai réimporté mes bases de données (innoDB) via un fichier DB Dump à partir du serveur de production. Cela a bien fonctionné . Après un redémarrage, le lendemain, je ne peux plus accéder aux bases de données: 

Table 'my.table' doesn't exist in engine

Quelle en est la cause et quelle est la solution? Je vois la structure de ma base de données, mais lorsque j'essaie d'y accéder, le message d'erreur s'affiche.

J'ai essayé mysql-upgrade --force et en supprimant rm ib_logfile1 ib_logfile0

La perte de données n’est pas un problème ici, le problème est que je ne peux pas passer 30 minutes à réinstaller chaque base de données à chaque redémarrage.

Voici quelques journaux:

140730  9:24:13 [Note] Server socket created on IP: '127.0.0.1'.
140730  9:24:14 [Note] Event Scheduler: Loaded 0 events
140730  9:24:14 [Warning] InnoDB: Cannot open table mysql/gtid_slave_pos from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.
140730  9:24:14 [Warning] Failed to load slave replication state from table mysql.gtid_slave_pos: 1932: Table 'mysql.gtid_slave_pos' doesn't exist in engine
140730  9:24:14 [Note] /usr/local/Cellar/mariadb/10.0.12/bin/mysqld: ready for connections.
Version: '10.0.12-MariaDB'  socket: '/tmp/mysql.sock'  port: 3306  Homebrew
140730 16:26:28 [Warning] InnoDB: Cannot open table db/site from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.
mysqlinnodbmariadb
7
sf_tristanb

Quelque chose a supprimé votre fichier ibdata1 où InnoDB conserve le dictionnaire. Ce n'est certainement pas MySQL qui le fait.

9
akuzminsky

Ok les gars, j’ai rencontré ce problème ce week-end lorsque mon environnement OpenStack est tombé en panne. Un autre article sur ce sujet à venir sur la façon de récupérer. 

J'ai trouvé une solution qui fonctionnait pour moi avec une instance SQL Server exécutée sous Ver 15.1 Distrib 10.1.21-MariaDB avec Fedora 25 Server en tant qu'hôte. N'écoutez pas tous les autres messages disant que votre base de données est corrompue si vous avez complètement copié le répertoire/var/lib/mysql de votre ancien mariadb-server et que la base de données que vous copiez n'est pas déjà corrompue. Ce processus est basé sur un système où le système d'exploitation a été corrompu mais où ses fichiers étaient toujours accessibles . 

Voici les étapes que j'ai suivies.

  1. Assurez-vous que vous avez complètement désinstallé les versions actuelles de SQL uniquement sur le nouveau serveur. Assurez-vous également que TOUS les processus mysql-server ou mariadb-server sur les serveurs NEW AND OLD ont été arrêtés en exécutant:

    service mysqld stop ou service mariadb stop.

  2. Sur le NOUVEAU serveur SQL, allez dans le répertoire/var/lib/mysql et assurez-vous qu’il n’ya aucun fichier dans ce répertoire. S'il y a des fichiers dans ce répertoire, votre processus de suppression du serveur de base de données de la nouvelle machine n'a pas fonctionné et est peut-être corrompu. Assurez-vous qu'il est complètement désinstallé de la nouvelle machine. 

  3. Sur le vieux serveur SQL:

    mkdir/OLDMYSQL-DIR cd /OLDMYSQL-DIR tar cvf mysql-olddirectory.tar /var/lib/mysql gzip mysql-olddirectory.tar

  4. Assurez-vous que sshd s'exécute sur les serveurs OLD et NEW. Assurez-vous qu'il existe une connectivité réseau entre les deux serveurs. 

  5. Sur le NOUVEAU serveur SQL:

    mkdir/NEWMYSQL-DIR

  6. Sur le vieux serveur SQL:

    cd /OLDMYSQL-DIR scp mysql-olddirectory.tar.gz @:/NEWMYSQL-DIR

  7. Sur le NOUVEAU serveur SQL:

    cd /NEWMYSQL-DIR gunzip mysql-olddirectory.tar.gz OR tar zxvf mysql-olddirectory.tar.gz (si tar zxvf ne fonctionne pas) tar xvf mysql-olddirectory.tar.gz

  8. Vous devriez maintenant avoir un fichier de répertoire "mysql" dans le dossier NEWMYSQL-DIR. Résistez à l'envie d'exécuter une commande "cp" seule sans aucun commutateur. Ça ne marchera pas. Exécutez la commande "cp" suivante et assurez-vous d’utiliser les mêmes commutateurs que ceux que j’ai utilisés. 

    cd mysql / cp -rfp */var/lib/mysql /

  9. Vous devriez maintenant avoir une copie de tous vos anciens fichiers de serveur SQL sur le nouveau serveur avec les autorisations nécessaires. Sur le NOUVEAU serveur SQL:

    cd/var/lib/mysql /

ÉTAPE TRÈS IMPORTANTE. NE PASSE PAS

> rm -rfp ib_logfile*
  1. Maintenant, installez mariadb-server ou mysql-server sur le NOUVEAU serveur SQL. Si vous l'avez déjà installé et/ou en cours d'exécution, vous n'avez pas suivi les instructions et ces étapes échoueront. 

POUR MARIADB-SERVER et DNF:

> dnf install mariadb-server
> service mariadb restart

POUR MYSQL-SERVER et YUM:

> yum install mysql-server
> service mysqld restart
2
lvto2000

Vous pouvez essayer de: 

  • sauvegardez votre dossier de base de données à partir de C:\xampp\mysql\data (fichiers .frm et .ibd uniquement correspondant aux noms de vos tables)
  • réinstaller xampp et recopier le dossier DB à C:\xampp\mysql\data

  • modifier my.ini add 

    [mysqld]
innodb_file_per_table = on

  • puis ouvrez phpmyadmin (ou tout autre visualiseur de base de données tel que Navicat ou MYSQL Workbench) et exécutez

    ALTER TABLE tbl_name IMPORT TABLESPACE

    pour chaque table

  • Une fois que vous pouvez ouvrir vos tables, créez un vidage mysql complet

  • tout effacer et faire une installation propre

Je sais, beaucoup de travail pour faire que vous n'en avez pas besoin.

0
Adrian P.