Discussion :

[laguespa]

Bonjour.

Sur une machine sous Debian à laquelle je n'ai pas accès à distance et sur laquelle j'ai une base de 17Mo en localhost je voudrais automatiser la sauvegarde de la base de données mysql périodiquement.
Je le fais régulièrement avec phpmyadmin quand je passe au local de la bibliothèque où se trouve la base et je m'envoie par mail un fichier localhost.sql qui contient la base et ses 231 tables.

En attendant j'essaie en ligne de commande avec mysqldump avant d'automatiser avec cron.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mysqldump -u root -pxxx --opt biblio_prayssas > biblio_prayssas.sql

Mais ça ne me sauvegarde que 145 tables sur 231 et à l'importation sur mon ordi personnel je suis obligé de créer la base biblio_prayssas d'abord pour importer les tables dedans ensuite.

Avez-vous des pistes ? Merci.

[SQLpro]

La sauvegarde de MySQL n'est pas pratiquable à chaud. Cela fait parties des nombreuses anomalies bogues et incohérences qui existe dans cet ersatz de SGBDR !

A lire sur le sujet : http://blog.developpez.com/sqlpro/p9...oudre_aux_yeux

A +

[skuatamad]

SQLPro, pour la version entreprise il y a MySQL Enterprise Backup qui semble proposer une option comme apply-log :

apply-log

Brings the InnoDB tables in the backup up-to-date, including any changes made to the data while the backup was running.

Peut être qu'il est possible depuis peu de faire des backup à chaud avec la version entreprise, en tout cas ça ressemble déjà plus à un backup à chaud.

Sinon mysqldump permet de faire un dump (consistent avec l'option --single-transaction) mais ce n'est pas un outil qui permet une vrai stratégie de sauvegarde à chaud comme pourrait l'entendre un DBA dans le monde des SGBDR commerciaux (et probablement aussi PG ou d'autres).

[laguespa]

J'ai essayé avec l'option --single-transaction mais j'ai toujours 145 tables sauvegardées au lieu de 231. Enfin c'est ce dont je me rends compte à l'importation via phpmyadmin.

Ce qui m'étonne c'est qu'après une sauvegarde

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$ mysqldump -u root -pxxx --opt --host=localhost --log-error=log --verbose ma_base > ma_base.sql

la commande suivante me rend

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ grep "Retrieving table structure for " log | wc -l
231

Donc, en principe 231 tables ont été sauvegardées. Sauf que fichier sql pèse 14,9 Mo au lieu de 17,1 et qu'à l'importation je ne retrouve pas mes 231 tables

Toutes les tables sont de type MyIsam.

J'en discute aussi sur un forum debian et la liste de diffusion du logiciel PMB dont la table est issue. Apparemment mysqldump ne pose de problème à personne d'autre.

[laguespa]

J'ai la réponse.
Il faut réimporter la base en ligne de commande et pas avec phpmyadmin...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mysql -u root -pxxxx ma_base < ma_base.sql

[skuatamad]

Oups, je viens de me rendre compte que je me suis trompé de post, désolé.
--single-transaction c'est pour du Innodb et pas myisam

Apparemment mysqldump ne pose de problème à personne d'autre.

mysqldump est très bien pour réaliser un dump de la base (mais pas pour des sauvegardes à chaud qui était le sujet sur lequel je croyais poster...)

et à l'importation sur mon ordi personnel je suis obligé de créer la base biblio_prayssas d'abord pour importer les tables dedans ensuite.

C'est normal si le dump ne concerne qu'une base :
http://dev.mysql.com/doc/refman/5.1/...-drop-database

--add-drop-database

Add a DROP DATABASE statement before each CREATE DATABASE statement. This option is typically used in conjunction with the --all-databases or --databases option because no CREATE DATABASE statements are written unless one of those options is specified.

Pour le problème du nombre de table, pas d'idée surtout si tu passes par la ligne de commande, désolé.

[edit] ah ben voilà, avec phpmyadmin il peut y avoir ce genre de problème...

[CleeM]

J'en profite pour ajouter une information concernant la restauration de données à l'aide de mysql, en effet un bug existe (cf. http://bugs.mysql.com/bug.php?id=42996).

Si tu essaye de restaurer une base de données supprimée à l'avance (ou n'existant plus), et que ton dump possède la ligne CREATE DATABASE, il arrive des fois où elle ne se créée pas et tu recevra donc un message DATABASE Xx doesn't exist. Il est donc nécessaire de la créer manuellement (ou via un script ou autre) avant de la restaurer.