SMPFR

Bonjour,

j'ai 3 serveurs mysql en version 3 4 et 5 avec plusieurs bases sur chaque serveur et dans quelques bases des tables ISAM mélangé avec des Innodb et quelques table HEAP aussi. La Volumetrie pour l ensemble des serveurs est d'environ 4.5Go avec en particulier une base qui fait 1.5Go a elle seule.
Mon but sauvegarder tout ce bordel.
Mes contraintes, pas d'arrêt possible des serveurs.
Ma question est comment faire ?
j'ai déja planché sur 2 solutions,
1./ celles qui me semble la plus fiable est InnoDB Hot Backup (Payant) qui permet des sauvegardes a chaud de innodb et isam (par contre je n'ai rien trouvé a propos des tables HEAP, d'ailleurs est il necessaire de les sauvegarder ?)
2./ je me penche aussi sur une mix Mysql Hot Copy (gratuit) et un bete export pour les tables Innodb mais les questions sont un export est il fiable sur les tables Innodb, faut il faire des locks pendant l export ou est auto-géré ? Meme question pour les tables HEAP.

J'aimerais bien avoir plus d'info sur la solution 2, est ce jouable, y a t il des contraintes a mettre ne place ?
Existe il des outils gratuit similaire a InnoDB Hot Backup ?
Merci

Salut

Je m'y connais pas trop là dedans, mais avec rsync ce serait pas possible de faire une sauvegarde?

rsync synchronise des fichiers, pas des base de données tournantes.

par contre, il me semble que mysql_dump permet de prendre un snapshot de la DB (avec les param kivonbien) sans devoir éjecter tout le monde et la mettre en RO...

faut lire la page de man

rsync synchronise des fichiers, pas des base de données tournantes.

par contre, il me semble que mysql_dump permet de prendre un snapshot de la DB (avec les param kivonbien) sans devoir éjecter tout le monde et la mettre en RO...

faut lire la page de man

et la base de données c'est pas des fichiers?

/var/mysql/drupal6/actions.MYD: data
/var/mysql/drupal6/actions.MYI: MySQL MISAM compressed data file Version 1
/var/mysql/drupal6/actions.frm: MySQL table definition file Version 10
/var/mysql/drupal6/actions_aid.MYD: empty
/var/mysql/drupal6/actions_aid.MYI: MySQL MISAM compressed data file Version 1
/var/mysql/drupal6/actions_aid.frm: MySQL table definition file Version 9
/var/mysql/drupal6/authmap.MYD: empty
/var/mysql/drupal6/authmap.MYI: MySQL MISAM compressed data file Version 1
/var/mysql/drupal6/authmap.frm: MySQL table definition file Version 10


si, effectivement.

mais je te déconseille d'essayer de les rsyncer comme ca *pouf*

pis, ce sont des fichiers sous unix. sous windoze, même pas sur que ca ressemble à un fichier avec un type spécifique, je le vois plus genre data moi

ok ok

le backup de fichiers marche, j'ai deja restauré des bases comme ça. bon, a mon avis, c pas du tout secure comme backup.

l'export des tables marche aussi, methode bourrin, les locks sont bien gérés. par contre, c'est tres long et atteins un volume faramineux. (plusieurs fois la taille de la base elle meme)

donc +1 pour mysqldump

les 2 premieres solutions peuvent etre utilisées pour de petites bases a la maison, c'est plus simple

j'ai tout un dossier sur la sauvegarde de mysql si tu veux, ca doit etre un linux magasine de juillet ou aout

edith :

Ca marchera pas de copier simplement les fichiers, je l'ai appris à mes dépends.

Faut faire un mysqldump... c'est le seul moyen de sauvegarder proprement.. et ça permet de changer aussi de version et d'OS..

En dernier recours, lire la doc !

un mysqldump spa bon du tout pour l'intégrité des données

Hein ?

un mysqldump spa bon du tout pour l'intégrité des données

a ma connaissance, c'est la solution la plus efficace.
tu as d'autres infos ? je suis interessé.

Je vois pas bien nom plus ce qu'il y aurais de mieux qu'un mysqldump...

Faut just locker en écriture ta db avant si tu veux être sur de pas foutre le bordel.

Parceque sinon, c'est ce que recommande Mysql lui même.

C'est vrais que c'est gros... c'est pour ça que tu as les pipes et bzip2... pas un vrais souci donc.

Justement, mysqldump est plus sécure que la copie de fichiers simple, puisque certaines transactions sont encore en ram et pas stockées sur le disque dur.

Après ça ne vaut pas une réplication active de la bdd...

le dossier mysql peut m interessé si tu pouvais me le scanner ca serait cool
pour le rsync ou la copie des fichiers a chaud c'est pas bon, les fichiers en cours d 'utilisation ca garantit surtout une base corrompue !

pour le mysqldump je fais des tests, ca sera mieux que rien en attendant une solution plus efficace mais ca me prend pas mal de temps pour une base de 1.5Go gzippé environ 20 minutes et 500Mo a l arrivée

ZEPsikopat à raison , la réplication c'est le top... mais faut avoir deux bécanes qui tournent..

mysqldump.. tu fais ca normalement la nuit. ou une fois par semaine... pas de quoi fouetter un chat.

je l'étudie aussi mais j'ai peur que ce soit lourd a gérer quand la réplication casse, en restant dans l idée de ne jamais éteindre le master

J'avais un peu regardé (après mes déboires de copie de fichiers...) et j'ai vu qu'on pouvais tranférer d'une base à l'autre et d'une machine à l'autre avec de simples commandes SQL.
Ce qui permetais de tout sauvegarder par le réseau assès simplement..

Mais j'avais plus de DB pour tester vu que j'avais tout perdu (ma base de données de plus de 500 livres, avec images et commentaires)

Edit : avec les requetes SQL tu évite seulement le passager par un fichier... c'est tout; et tu peux fe faire par le net.

a ma connaissance, c'est la solution la plus efficace.
tu as d'autres infos ? je suis interessé.

La solution est bonne si tu mets des locks sinon y a problème d'intégrité des données entre les tables vu qu'il peut y avoir des écritures pendant la sauvegardes ta base sauvegardée peut etre incohérente.

Je vois pas bien nom plus ce qu'il y aurais de mieux qu'un mysqldump...

Faut just locker en écriture ta db avant si tu veux être sur de pas foutre le bordel.

Parceque sinon, c'est ce que recommande Mysql lui même.

C'est vrais que c'est gros... c'est pour ça que tu as les pipes et bzip2... pas un vrais souci donc.

Oui voilà je parlais dans le cas du topix ou il veut jamais la couper la base, le dump pt etre incohérent ... Pour l'article je le scan quand j'ai deux min y a tout ce qu'il faut de mémoire

perso j'utilise les solutions gratuites proposées sur le site MySQL ( MySQL Admin & MySQL Query Browser )

aucun pb de restauration SAUF selon l'OS des problemes d'encodage UTF-8 ( en gros après la restauration les caractères accetués sont perdus )

Juste... Windows doit utiliser un autre UTF-8 que l'UTF-8 std...

J'avais pourtant coché UTF-8 pendant l'install. de Mysql sous XP et MysqlODBC (pour l'accès avec Openoffice) aussi, mais rien à faire.

Mais comme mysqldum te donne du texte.. tu peux retester différent encodages en faisant un "sed 's/xx/yy/g' sur une copie de ton fichier"

[HS] j'ai eu bcp de soucis avec la restauration de bdd entre linux et windows avec ces *** caractères
la seule option facile que j'ai trouvé
sortir la bdd en texte puis convertir en utf-8
re-importer après ma bdd
c'est vite très très long dès qu'on a des bdd assez grosses
j'ai converti ~300Mo de bdd comme ca [/HS]

pas mieux

Backuper des bases en rsync sans les arrêter est le meilleur moyen d'avoir des tables corrompues, et ça croît avec la volumétrie...

C'est du vécu

Backuper des bases en rsync sans les arrêter est le meilleur moyen d'avoir des tables corrompues, et ça croît avec la volumétrie...

C'est du vécu

Y aura juste une sauvegarde corrompue ou alors ça corromp aussi la base en utilisation?