|
|
|
Publicité ' | |||||||||||||||||||||||
30/10/2006, 15h38
|
#1 |
|
Membre confirmé
 
 Inscription : janvier 2005 Messages : 232  |
sauvegarde à chaud MySQL
Hello,
Après avoir parcouru un max d'informations sur le sujet, il me manque encore quelques précisions. Ce que j'ai lu : Les scripts mysqldump et mysqlhotcopy permettent une sauvegarde à chaud grâce à un lock tables et flush tables. Ce que je considère comme sauvegarde à chaud : La sauvegarde s'effectue alors que l'application tourne et que les données sont modifiées Ce que je me pose comme questions : - MySQL verrouille toutes les tables ou les une à la suite ? - Si MySQL verrouille toutes les tables du début à la fin de la sauvegarde, comme peut réagir une application qui tente un accès en modification sur une table lockée ? - Si MySQL verrouille les tables une par une, comment peut il assurer la cohérences entre les tables sauvegardés au début et celles sauvegardées à la fin ? Merci d'avance :-) |
|
00
|
|
30/10/2006, 15h56
|
#2 |
|
Membre confirmé
Inscription : juin 2002 Messages : 240 |
Le verrouillage de l'ensemble des tables est une options de mysqldump.
Le problème, c'est que sur une grosse base, ce verrou maintenu sur l'ensemble de la base gèle les autres processus (qui attendent la libération du verrou). Pas de pb si la base fait une petite dizaine de Mo (gèle de quelques secondes). Inutilisable sur une base de plusieurs Go. Une sauvegarde cohérente d'un grosse base avec des table myIsam est donc quasi impossible (à chaud, j'entend). Le seul moyen réellement efficace (et là cela fonctionne très bien) et d'utiliser des tables InnoDB. Là on dispose du transactionnel. Il suffit alors d'utiliser l'option --single-transaction, avec mySqlDump. On dispose alors d'un dump cohérent (intant T du début de sauvegarde) sans pour autant bloquer les autres process (innoDB étant multi-générationnel, les autres process peuvent aussi bien lire qu'écrire sans être bloqué et sans interférer avec la sauvegarde en cours). A voir également, directement sur le site Innodb.com, l'outil payant "ibbackup". Il permet de faire une copie transactionnelle, en mode binaire. En gros le résultat correspond à un clone quasi-exploitable de la base de données. La remise en service n'est guère plus longue que la copie du fichier lui même. Comparé au remontage d'un dump SQL de plusieurs centaines de Mo (qui peut prendre plusieurs dizaines de minutes, voir plusiuers heures) c'est un vrai bonheur. Ne pas hésiter en environement pro. Cordialement Gabriel |
|
|
00
|
|
30/10/2006, 16h25
|
#3 |
|
Membre confirmé
Inscription : janvier 2005 Messages : 232 |
Il s'agira en effet de tables de l'ordre du Giga octet. Actuellement cette appli peut tourner avec ORACLE ou MsSQL Server. Innodb s'impose...
Très intéressant, merci 
|
|
|
00
|
|
30/10/2006, 18h58
|
#4 | |
|
Membre Expert
 
Inscription : mai 2002 Messages : 1 022 |
Citation:
__________________
Alexandre T. PHP5/MySQL5 Codes prêts à l'emploi 30 projets avec codes sources complets pour créer diaporamas photos, chat, arbre généalogique, statistiques de visites, création de graphiques, moteur de recherche, Sudoku etc... Mes articles |
|
|
|
00
|
|
25/08/2010, 16h24
|
#5 |
|
Membre du Club
 Inscription : septembre 2007 Messages : 118 |
Désolé de repartir de ce post plutôt ancien mais je me posais une question sur le mysqlhotcopy
Est-ce que cette commande ne marche que base par base (en l'identifiant dans la ligne de commande d'exécution), ou peut-on la faire pour toutes les bases d'un coup (avec une option qui ressemblerait à all databases pour mysqldump) ? Sachant que le mysqlhotcopy créée un rép. avec toutes les tables à chaque fois, j'ai un doute sur la faisabilité de ma question |
|
|
00
|
Copyright © 2000-2012 - www.developpez.com