Salut,

Un très bon script Bash qui correspond exactement à ta demande a savoir un dump par base.

http://sourceforge.net/projects/automysqlbackup/

Franck

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°° Franck Leroy Telemaque - SOPHIA ANTIPOLIS °°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

Le 18/07/2013 17:42, Guillaume Dievart a écrit :

Hello,

je te renvoie vers ce premier hangops français qui traite le sujet des backup MySQL => http://www.mysqlplus.fr/2013/06/20/dbhangopsfr-live/

Les dump logique sont bien pour de petites bases, mais lorsque tu veux remonter ta DB ça risque de prendre une plomb !

Aussi si tu souhaites tout de même utiliser mysqldump et que tu as un slave, exécute ton dump depuis ce dernier.

Cordialement, Guillaume Dievart. Le 18/07/2013 17:33, Gaël a écrit :

...

Hello !

J'ai un serveur (toujours le même), sur lequel sont hébergés une trentaine de site. Il y a aussi une vingtaine de bases de données MySQL.

Système sous debian, pas de trucs compliqués, y'a juste apache/php/mysql et des services alacon dont on se fout ici.

Je cherche une solution fonctionnelle et propre tant qu'à faire pour sauvegarder mes bases SQL.

J'ai lu autour de mysql dump, mais si j'ai bien compris, ça ne bloque pas l'accès à la base pendant le dump, donc il peut y avoir des écritures simultanées et ça met le truc en vrille.

M'enfin j'ai pas tout tout compris, donc je vous demande vos avis :)

J'ai 3,3go de db à sauvegarder (enfin, le dossier /var/lib/mysql fait 3,3go), et je voudrais avoir un ficheir sql par DB, et après j'envoie tout ça ailleurs avec rsync.

Merci d'avance !!

Gaël

---

Liste de diffusion du FRsAG http://www.frsag.org/

---

Liste de diffusion du FRsAG http://www.frsag.org/

La méthode décrite par Florent est de loin la plus efficace pour avoir une base cohérente.

J'imagine que cela la cohérence ne peut être véritablement garantie que si les modifications de la base se font via des transactions commitées.

A défaut, le delta de changements non pris en compte est minime avec le backup LVM.

2013/7/18 Florent Rivoire florent@rivoire.fr:

Un principe pour avoir un backup cohérent : => tu mets ton /var/lib/mysql dans un partition qui est un volume LVM

Et ensuite, ton script de backup fait ceci : => tu lock chaque base (FLUSH TABLES WITH READ LOCK de mémoire, cf la doc) => tu prends un snapshot de ton volume LVM => tu unlock les bases (en tout, elles auront été lockées qq secondes maximum) => tu backup le contenu du snapshot LVM => tu supprime le snapshot => et voilà :)

NB: ca fonctionne aussi avec du ZFS au lieu du LVM.

-- Florent

2013/7/18 Gaël gagou9@gmail.com:

...

Hello !

J'ai un serveur (toujours le même), sur lequel sont hébergés une trentaine de site. Il y a aussi une vingtaine de bases de données MySQL.

Système sous debian, pas de trucs compliqués, y'a juste apache/php/mysql et des services alacon dont on se fout ici.

Je cherche une solution fonctionnelle et propre tant qu'à faire pour sauvegarder mes bases SQL.

J'ai lu autour de mysql dump, mais si j'ai bien compris, ça ne bloque pas l'accès à la base pendant le dump, donc il peut y avoir des écritures simultanées et ça met le truc en vrille.

M'enfin j'ai pas tout tout compris, donc je vous demande vos avis :)

J'ai 3,3go de db à sauvegarder (enfin, le dossier /var/lib/mysql fait 3,3go), et je voudrais avoir un ficheir sql par DB, et après j'envoie tout ça ailleurs avec rsync.

Merci d'avance !!

Gaël

---

Liste de diffusion du FRsAG http://www.frsag.org/

---

Liste de diffusion du FRsAG http://www.frsag.org/

On 07/18/2013 05:46 PM, Bégault Luc wrote:

Attention, cette méthode si elle fonctionne avec des tables MyIsam peut poser des problèmes avec InnoDB (http://dev.mysql.com/doc/refman/5.5/en/innodb-backup.html => pour un snapshot fichier, mysql dit que le serveur doit etre arrété).

Si c'est vrai, alors ça veut dire que le serveur n'est pas capable de résister à une coupure de courant, ce qui me semble peu probable (ça briserait d'ailleurs les garanties ACID, plus précisément la garantie de durabilité).

On 18/07/13 17:47, Florent Rivoire wrote:

Un principe pour avoir un backup cohérent : => tu mets ton /var/lib/mysql dans un partition qui est un volume LVM

Et ensuite, ton script de backup fait ceci : => tu lock chaque base (FLUSH TABLES WITH READ LOCK de mémoire, cf la doc) => tu prends un snapshot de ton volume LVM => tu unlock les bases (en tout, elles auront été lockées qq secondes maximum) => tu backup le contenu du snapshot LVM => tu supprime le snapshot => et voilà :)

+1 pour cette méthode, qui permet d'avoir un backup cohérent sans bloquer la base très longtemps. Attention s'il y a beaucoup d'écritures dans les bases, le CoW d'un snapshot plombe pas mal les IO en écriture. Perso, je sync aussi le filesystem avant de snapshoter mais je ne sais pas si c'est mandatory (et je préfère stopper la BdD plutôt que de locker).

Autre solution, qui fonctionne bien avec InnoDB et MyISAM : percona xtrabackup (http://www.percona.com/doc/percona-xtrabackup/2.1/), également capable de réaliser un backup consistant à chaud. C'est une solution intéressante en l'absence de LVM mais qui nécessite MySQL >= 5.1

On 18/07/2013 20:12, Etienne Dechamps wrote:

Techniquement tu n'as pas besoin de locker. Si le moteur de base de données est implémenté correctement (plus précisément s'il utilise fsync() correctement, et pour InnoDB j'imagine que c'est le cas) il est capable de résister sans problème à une coupure de courant. Or, restaurer un snapshot revient exactement au même que rédémarrer la machine après une coupure de courant qui serait intervenue au moment du snapshot.

Justement, tout le problème est là: la restauration impose de passer par un phase de crash recovery. Voir à ce sujet la discussion de ce post: http://www.mysqlperformanceblog.com/2006/08/21/using-lvm-for-mysql-backup-an... c'est pas forcément récent mais assez bien expliqué. Luc.