J'ai deux VPS en cours d'exécution en ce moment. Un, que j'appellerai "l'ancien" serveur, fonctionne sur Debian 7 et donne cette sortie pour mysql --version
:
mysql Ver 14.14 Distrib 5.5.44, for debian-linux-gnu (x86_64) using readline 6.2
L'autre, que j'appellerai le "nouveau" serveur, fonctionne sur une toute nouvelle installation de Debian 8 , et donne cette sortie:
mysql Ver 15.1 Distrib 10.0.20-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
J'essaie de déplacer mes bases de données et tables de l'ancien serveur vers le nouveau serveur. J'ai pensé que je pouvais le faire en copiant simplement le répertoire /var/lib/mysql/
De l'ancien serveur et en écrasant le même répertoire sur le nouveau serveur. Cependant, après avoir fait cela, je reçois maintenant cette erreur dans phpMyAdmin sur le nouveau serveur lorsque je clique sur l'une des tables ou des bases de données:
#1932 - Table 'phpmyadmin.pma__tracking' doesn't exist in engine
Cependant, je peux clairement voir qu'il existe:
Y a-t-il une solution à cela? Je ne sais pas ce que j'ai fait de mal. Merci!
J'ai résolu le problème en suivant cette réponse: https://stackoverflow.com/a/11506495/2364405
Sauf avec ces changements:
create_tables.sql
, mais j'ai trouvé create_tables.sql.gz
au lieu. J'ai utilisé WinSCP et téléchargé ce fichier, puis je l'ai importé dans phpMyAdmin (cela prend en charge les étapes 6 et 7).pma__bookmark
par exemple), donc je ne les ai pas modifiés en un seul trait de soulignement.D'une certaine manière, cela m'a permis d'utiliser à nouveau phpMyAdmin sans erreur. :)
Vous pouvez copier des fichiers d'un serveur à l'autre pour déplacer votre base de données. Pour ce faire, vous devez vous assurer que les deux instances de votre base de données sont arrêtées. Je recommande également d'utiliser rsync pour copier vos fichiers de base de données. En plus de vous assurer que les deux serveurs de bases de données sont arrêtés avant de déplacer les fichiers, vous devrez probablement changer la propriété de vos fichiers. Sudo chown --recursive mysql:mysql /var/lib/mysql
avant de démarrer votre nouvelle instance.
Il existe d'autres options pour déplacer votre base de données. Si votre base de données n'est pas terriblement grande, mysqldump est probablement le plus simple. J'ai joint la documentation pour mysqldump ci-dessous telle que fournie par MariaDB, car vous utilisez MariaDB.
https://mariadb.com/kb/en/mariadb/mysqldump/
Une autre option à considérer, un peu plus complexe mais un peu plus flexible pour la taille, serait le xtrabackup de Percona .
https://www.percona.com/software/mysql-database/percona-xtrabackup
Si vous déplacez simplement votre base de données d'un dossier vers un autre dossier, mais que vos tables InnoDB ne fonctionnent plus, car elles ne peuvent pas être trouvées et le message d'erreur "La table n'existe pas dans le moteur" s'affiche, alors ces paires de SQL les déclarations peuvent être aussi rapides qu'utiles:
ALTER TABLE __yourtable_name__ DISCARD TABLESPACE ;
ALTER TABLE __yourtable_name__ IMPORT TABLESPACE ;
En pratique, le .IDB
le fichier est détaché de .FRM
fichier puis lié à nouveau, de sorte que le contenu de la table devienne lisible.
Cela a fonctionné dans mon cas. J'espère que le vôtre aussi.
J'obtenais cette même erreur après avoir déplacé une sauvegarde mysqldump vers une nouvelle machine, et après avoir fait quelques mises à jour sur la base de données, j'ai supprimé un index unique qui avait une clé pour une contrainte étrangère.
J'ai réalisé que c'était une erreur de clé étrangère en utilisant: afficher le statut innodb du moteur.
------------------------
LATEST FOREIGN KEY ERROR
------------------------
2019-07-23 10:43:05 0x7f68a4255700 Error in foreign key constraint of table lhprovedorinfo/NOTAFISCAL:
there is no index in the table which would contain
the columns as the first columns, or the data types in the
table do not match the ones in the referenced table
or one of the ON ... SET NULL columns is declared NOT NULL. Constraint:
Après cela, j'ai désactivé les vérifications de clé étrangère avec: set FOREIGN_KEY_CHECKS = 0; Ensuite, a supprimé la clé étrangère et l'a recréée, afin de créer mysql les index nécessaires. Et ma table est revenue à la vie.
J'espère que cela aide quelqu'un.