[Résolu] mysql : restauration ne veut pas marcher

arverne73 · Le 30/04/2019, à 22:36

Bonjour,
Sous Ubuntu 18.04 GNOME (installé à neuf), nous avons mysql installé (installation été 2018) avec plusieurs bases de données.
Une sauvegarde est faite par automysqlbackup dans le dossier utilisateur.
Suite à une erreur de requête, on voulait simplement restaurer une sauvegarde pour revenir à une version antérieure.
Le test est fait sur une base mysql vide créée pour l'occasion.
Or, la commande très classique que l'on trouve partout, soit :

sudo mysql -u nomUtilisateur -p maNouvelleBase < /chemin vers/sauvegarde.sql

ne marche pas ! La machine semble travailler mais la base maNouvelleBase reste vide ! Et aucun message dans le terminal.

Une idée ?
Merci d'avance.

Dernière modification par arverne73 (Le 02/05/2019, à 18:45)

gl38 · Le 01/05/2019, à 13:38

Que donne sans sudo

mysql -u nomUtilisateur -p
show databases;
use maNouvelleBase;
show tables;
quit

Cordialement,
Guy

krodelabestiole · Le 01/05/2019, à 13:48

gl38 a écrit :

Que donne sans sudo

en principe, pour se connecter à mysql depuis bionic c'est simplement

sudo mysql

sans utilisateur et sans mot de passe.
https://doc.ubuntu-fr.org/mysql#authentification

gl38 a écrit :

mysql -u nomUtilisateur -p
show databases;
use maNouvelleBase;
show tables;
quit

ceci dit effectivement, cette méthode devrait permettre de savoir à quel niveau se situe le problème.

arverne73 a écrit :

Or, la commande très classique que l'on trouve partout, soit :
sudo mysql -u nomUtilisateur -p maNouvelleBase < /chemin vers/sauvegarde.sql
ne marche pas !

plutôt que "ça ne marche pas", ce serait bien d'indiquer le message d'erreur exact.

arverne73 · Le 01/05/2019, à 19:39

Je répondrais demain (je suis au boulot). On va essayer ces commandes mysql, en sachant qu'après chaque tentative, on a consulté phpmyadmin qui montrait une base vide.
Et

krodelabestiole a écrit :
plutôt que "ça ne marche pas", ce serait bien d'indiquer le message d'erreur exact.

dans la suite de ma phrase, j'ai bien indiqué "et aucun message dans le terminal", sous entendu, "aucun message d'erreur".
Bonne soirée.

arverne73 · Le 02/05/2019, à 15:21

Bonjour,
Je confirme que l'installation de mysql s'est faite suivant la nouvelle méthode où l'on ne crée plus d'utilisateur root spécifique (auth_socket). Néanmoins, comme on voulait utiliser phpmyadmin, j'ai dû ajouter un utilisateur spécifique à mysql (et je vois que j'ai mis le même login que pour la session Ubuntu mais un mot de passe différent).
La commande tenant compte de ce nouveau type d'accès sous bionic, soit

sudo mysql maNouvelleBase < chemin/vers fichier.sql

ne marche pas (le terminal travaille, ne renvoie aucune erreur mais absence de résultats).

Pour information, j'ai aussi lancé la commande avec l'option -v : de multiples lignes s'affichent dans lesquelles on reconnaît bien des enregistrement du fichier .sql qui est donc bien lu. Ci-dessous les dernières lignes :

rhéophile',NULL,NULL,NULL),(121539,55276,NULL,450,NULL,'Ranunculus','peltatus','écoph.','rhéophile',NULL,NULL,NULL),(121540,75227,NULL,450,NULL,'Lonicera','periclymenum','écoph.','rampant',NULL,NULL,NULL),(121541,65421,NULL,450,NULL,'Sparganium','natans','écoph.','stagnophile',NULL,NULL,NULL),(121542,43859,NULL,450,NULL,'Nasturtium','officinale','écoph.','rhéophile',NULL,NULL,NULL)
--------------

--------------
/*!40000 ALTER TABLE `nouv_espèces` ENABLE KEYS */
--------------

--------------
UNLOCK TABLES
--------------

--------------
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */
--------------

--------------
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */
--------------

--------------
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */
--------------

--------------
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */
--------------

--------------
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */
--------------

--------------
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */
--------------

--------------
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */
--------------

--------------
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */
--------------

Et enfin les autres commandes que vous m'avez demandées avec le résultat montrant bien que la nouvelle base (ici botamyco2) reste vide.

philippe@philippepc:~$ sudo mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 29
Server version: 5.7.26-0ubuntu0.18.04.1 (Ubuntu)

Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| botamyco           |
| botamyco2          |
| micro              |
| mysql              |
| performance_schema |
| phpmyadmin         |
| spip               |
| sys                |
+--------------------+
9 rows in set (0.00 sec)

mysql> use botamyco2
Database changed
mysql> show tables;
Empty set (0.00 sec)

Merci pour votre aide...

bruno · Le 02/05/2019, à 15:36

Bonjour,

Il aurait été plus intéressant de voir les premières lignes que les dernières.
Il faut examiner le contenu de ton fichier .sql. Contient-il les requêtes pour créer les tables et y insérer les données ?

arverne73 · Le 02/05/2019, à 17:07

Je ne sais pas comment voir ces premières lignes dans la mesure où l'option -v crée un nombre invraisemblable de ligne et le plus haut que je remonte dans le terminal, je suis au milieu des données du fichier...
Le fichier .sql est généré automatiquement par automysqlbackup : je suppose qu'il contient tout ce que contient la base: tables, requêtes, formulaires, états

Je me suis aussi forcément servi de cette méthode quand j'ai réinstallé mysql avec bionic, "à neuf" sur la machine. J'ai restauré ces bases forcément à partir des sauvegardes sans grande difficulté à ce moment là.

bruno · Le 02/05/2019, à 17:10

Il ne suffit pas de supposer
Montre-nous les 50 premières lignes de ton fichier .sql

arverne73 · Le 02/05/2019, à 17:28

Je ne savais pas que l'on pouvait ouvrir ce fichier .sql...

Voici le début :

-- MySQL dump 10.13  Distrib 5.7.25, for Linux (x86_64)
--
-- Host: localhost    Database: botamyco
-- ------------------------------------------------------
-- Server version	5.7.25-0ubuntu0.18.04.2

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Current Database: `botamyco`
--

CREATE DATABASE /*!32312 IF NOT EXISTS*/ `botamyco` /*!40100 DEFAULT CHARACTER SET latin1 */;

USE `botamyco`;

--
-- Table structure for table `AjoutFamilles`
--

DROP TABLE IF EXISTS `AjoutFamilles`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `AjoutFamilles` (
  `nom_supra_generique` varchar(16) DEFAULT NULL,
  `num_nom` int(6) DEFAULT NULL,
  `num_nom_retenu` int(6) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `AjoutFamilles`
--

LOCK TABLES `AjoutFamilles` WRITE;
/*!40000 ALTER TABLE `AjoutFamilles` DISABLE KEYS */;
INSERT INTO `AjoutFamilles` VALUES ('Cactaceae',100899,100899),('Onagraceae',100921,100921),('Davallianaceae',100937,100937),('Acoraceae',100949,100949),('Lardizabalaceae',100956,100956),('Alismataceae',100958,100958),('Casuarinaceae',100959,100959),('Alstroemeriaceae',100963,100963),('Lauraceae',100972,100972),('Aponogetonaceae',100973,100973),('Araucariaceae',100975,100975),('Garryaceae',100984,100984),('Azollaceae',100985,100985),('Begoniaceae',100986,100986),('Linderniaceae',100988,100988),('Phyllanthaceae',100990,100990),('Nyctaginaceae',100992,100992),('Basellaceae',100995,100995),('Butomaceae',101001,101001),('Cabombaceae',101003,101003),('Calycanthaceae',101006,101006),('Bignoniaceae',101008,101008),('Cannaceae',101009,101009),('Capparaceae',101011,101011),('Sapindaceae',101012,101012),('Ceratophyllaceae',101021,101021),('Clethraceae',101025,101025),('Commelinaceae',101028,101028),('Coriariaceae',101032,101032),('Culcitaceae',101037,101037),('Cymodoceaceae',101038,101038),('Cynomoriaceae',101039,101039),('Thymelaeaceae',101044,101044),('Davalliaceae',101045,101045),('Hydrangeaceae',101046,101046),('Ebenaceae',101047,101047),('Pontederiaceae',101049,101049),('Elatinaceae',101051,101051),('Escalloniaceae',101055,101055),('Zygophyllaceae',101056,101056),('Bromeliaceae',101057,101057),('Ginkgoaceae',101060,101060),('Proteaceae',101062,101062),('Gunneraceae',101064,101064),('Phrymaceae',101068,101068),('Hymenophyllaceae',101069,101069),('Pedaliaceae',101070,101070),('Paulowniaceae',101076,101076),('Limnanthaceae',101077,101077),('Magnoliaceae',101079,101079),('Meliaceae',101082,101082),('Calceolariaceae',101084,101084),('Myricaceae',101085,101085),('Ruppiaceae',101087,101087),('Nelumbonaceae',101088,101088),('Martyniaceae',101094,101094),('Loasaceae',101097,101097),('Nitrariaceae',101098,101098),('Posidoniaceae',101105,101105),('Psilotaceae',101106,101106),('Pteridaceae',101108,101108),('Gesneriaceae',101109,101109),('Salviniaceae',101111,101111),('Sarraceniaceae',101112,101112),('Saururaceae',101113,101113),('Nartheciaceae',101117,101117),('Staphyleaceae',101118,101118),('Strelitziaceae',101119,101119),('Tofieldiaceae',101120,101120),('Cleomaceae',101122,101122),('Xanthorrhoeaceae',101123,101123),('Tropaeolaceae',101125,101125),('Zosteraceae',101128,101128),('Cycadaceae',101447,101447),('Podocarpaceae',101612,101612),('Sapotaceae',102161,102161),('Altingiaceae',102186,102186),('Cephalotaxaceae',102788,102788),('Lomariopsidaceae',103119,103119),('Zingiberaceae',103128,103128),('Neuradaceae',103305,103305),('Dicksoniaceae',103310,103310),('Myrsinaceae',103311,103311),('Nephrolepidaceae',103514,103514),('Loranthaceae',103515,103515),('Eriocaulaceae',118491,118491),('Musaceae',118595,118595),('Marantaceae',118599,118599),('Annonaceae',120608,120608),('Melastomataceae',120613,120613),('Cystopteridaceae',121571,121571),('Onocleaceae',121588,121588),('Sciadopityaceae',121591,121591),('Calyceraceae',121619,121619);
/*!40000 ALTER TABLE `AjoutFamilles` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `AjoutGenres`
--

DROP TABLE IF EXISTS `AjoutGenres`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `AjoutGenres` (
  `genre` varchar(23) DEFAULT NULL,
  `num_nom` int(6) DEFAULT NULL,
  `num_nom_retenu` int(6) DEFAULT NULL,
  `num_tax_sup` int(6) DEFAULT NULL,
  `auteur` varchar(40) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `AjoutGenres`
--

LOCK TABLES `AjoutGenres` WRITE;
/*!40000 ALTER TABLE `AjoutGenres` DISABLE KEYS */;
INSERT INTO `AjoutGenres` VALUES ('Opuntia',77729,77729,100899,'(L.) Mill.'),('Agapanthus',81989,81989,100931,'L\'Hér.'),('Dahlia',82222,82222,100897,'Cav.'),('Pyracantha',82988,82988,101130,'M.Roem.'),('Ipomoea',83613,83613,100908,'L.'),('Micromeria',84641,84641,100913,'Benth.'),('Acacia',85067,85067,100916,'Mill.'),('Greenovia',85110,85110,100910,'Webb'),

Dernière modification par bruno (Le 02/05/2019, à 18:07)

gl38 · Le 02/05/2019, à 17:42

Je vois

CREATE DATABASE /*!32312 IF NOT EXISTS*/ `botamyco` /*!40100 DEFAULT CHARACTER SET latin1 */;

USE `botamyco`;

Il me semble que la sauvegarde va se mettre dans botamyco et non dans botamyco2.
Cordialement,
Guy

arverne73 · Le 02/05/2019, à 17:53

C'est ce qui vient de me traverser l'esprit ! Bien que dans la commande, on écrive "botamyco2 < sauvegarde.sql", je pense qu'il a restitué direct dans la vraie base comme écrit au sommet du fichier sql.
Quand je vais dans le répertoire /var/lib/mysql, je constate d'ailleurs que tous les fichiers de botamyco sont datés de cette après-midi alors que je n'ai rien saisi dans cette base.
On voulait restituer dans cette base vide "botamyco2" par prudence afin de lire le contenu.
Et il est quand même un peu déroutant de s'apercevoir que cette commande "base < ssuvegarde.sql" que l'on retrouve écrite partout, ne s'exécute par forcément comme il est écrit, notamment si l'on a sauvegardé avec automysqlbackup.

Je vais demander à l'utilisateur de vérifier que les données sont revenues à l'état initial dans la base botamyco... et je mettrais peut être un petit commentaire dans la page automysqlbackup quant à la restauration.
Merci en tout cas.

gl38 · Le 02/05/2019, à 17:56

C'est que mysqldump est peut-être plus sûr : personne ne l'a trafiqué en croyant bien faire !
Cordialement,
Guy

krodelabestiole · Le 02/05/2019, à 18:09

automysqlbackup sert à sauvegarder toutes les bases et à les recréer telles quelles en cas d'accident.

donc aucune maladresse à déplorer à ce niveau.

bruno · Le 02/05/2019, à 18:18

automysqlbackup utilise mysqldump
Par défaut les requêtes CREATE DATABASE … et USE … ne sont pas générées par mysqldump, c'est effectivement une option que automysqlbackup active dans son fichier de configuration :

/etc/default/automysqlbackup a écrit :

# Include CREATE DATABASE in backup?
CREATE_DATABASE=yes

Trois leçons à en tirer :
- toujours vérifier que les options de configuration d'une application correspondent bien à ce que l'on attend ;
- toujours vérifier que le dump que l'on veut restaurer est correct ;
- quand on restaure une base de données : éviter de connecter en root (ou avec un utilisateur qui a tous les droits), plutôt se connecter avec un utilisateur qui a uniquement les droits sur la base que l'on veut restaurer.

arverne73 · Le 02/05/2019, à 18:39

Je confirme en tout cas : les données ont bien été restaurées dans la base originale à partir de laquelle a été faite la sauvegarde.
Automysqlbackup est un outil tout à fait adapté à un utilisateur non professionnel comme moi. Le tout est de connaître les implications, ce que je vais écrire dans la doc.
Merci à tous !

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 30/04/2019, à 22:36

[Résolu] mysql : restauration ne veut pas marcher

#2 Le 01/05/2019, à 13:38

Re : [Résolu] mysql : restauration ne veut pas marcher

#3 Le 01/05/2019, à 13:48

Re : [Résolu] mysql : restauration ne veut pas marcher

#4 Le 01/05/2019, à 19:39

Re : [Résolu] mysql : restauration ne veut pas marcher

#5 Le 02/05/2019, à 15:21

Re : [Résolu] mysql : restauration ne veut pas marcher

#6 Le 02/05/2019, à 15:36

Re : [Résolu] mysql : restauration ne veut pas marcher

#7 Le 02/05/2019, à 17:07

Re : [Résolu] mysql : restauration ne veut pas marcher

#8 Le 02/05/2019, à 17:10

Re : [Résolu] mysql : restauration ne veut pas marcher

#9 Le 02/05/2019, à 17:28

Re : [Résolu] mysql : restauration ne veut pas marcher

#10 Le 02/05/2019, à 17:42

Re : [Résolu] mysql : restauration ne veut pas marcher

#11 Le 02/05/2019, à 17:53

Re : [Résolu] mysql : restauration ne veut pas marcher

#12 Le 02/05/2019, à 17:56

Re : [Résolu] mysql : restauration ne veut pas marcher

#13 Le 02/05/2019, à 18:09

Re : [Résolu] mysql : restauration ne veut pas marcher

#14 Le 02/05/2019, à 18:18

Re : [Résolu] mysql : restauration ne veut pas marcher

#15 Le 02/05/2019, à 18:39

Re : [Résolu] mysql : restauration ne veut pas marcher

Pied de page des forums