Giltonic

dimanche 3 juin 2007

Mysql Cookbook

Conseils :
Faire des sauvegardes avec la date dans le fichier/repertoire
Faire 2 Types de sauvegardes : génération de fichier sql et repertoire entier.
Pour la variable %date% attention tous les machines n'ont pas la meme config il faut adapter le script ci dessous- créer un batch et excecuter le batch par la commande AT

set adate=%date:~6,4%%date:~3,2%%date:~0,2%
cd c:\sav
mkdir %adate%
C:\mysql\bin\mysqldump --user=root --opt prodia_sas --tab=C:\sav\%adate%\
C:\mysql\bin\mysqldump --user=root --opt prodia_sas > C:\sav\prodia_%adate%.sql


Remarques
Il semblerait que l'option --opt : lock les tables, les indexes etc... L'option --tab fait une copie du repertoire avec des formats spéciaux. j'ai pas encore compris comment remonter les données en cas de pb mais tout le monde à l'air de préférer cette méthode. L'option ">" .sql reste, elle, ma préférée. La base doit être démarrer pour réaliser une sauvegarde
Réparation de la base Mysql
Sachez que Mysql se félicite d'avoir un taux de réussite de 99% sans remonter de sauvegarde.

  1. Lire les docs !
  2. Regarder le type d'erreur dans l'observateur d'evenement/Application ce qui ne va pas.
  3. Faire une recherche sur le net

liens :

  1. http://dev.mysql.com/doc/refman/5.0/fr/myisam-table-problems.html
  2. http://dev.mysql.com/doc/refman/5.0/fr/repair-table.html

Problèmes déjà rencontrés sur Mysql

Chez Prodia le 28/02/2007 (tel le 01/03/2007 au matin)

Type Mysql 4.0.26

Quelques minutes avant la sauvegarde (mysqldump) du 28/02/2007, l'observateur d'évenement signale un problàme sur Mysql

Can't find file: 'consommation.MYI' (errno: 2)

Dans ce cas il faut se connecter à la base et reparer la table comme ceci.

En ligne de commande c'est beaucoup mieux que par MyCC ou autre

D:\>cd mysql\bin
D:\mysql\bin> mysql --user=root
mysql> use prodia_sas;
Database changed
mysql> REPAIR TABLE consommation;
+-------------------------+--------+----------+------------------------------------------------+
Table Op Msg_type Msg_text
+-------------------------+--------+----------+------------------------------------------------+
prodia_sas.consommation repair error Can't find file: 'consommation.MYI' (errno: 2)
+-------------------------+--------+----------+------------------------------------------------+
1 row in set (0.00 sec)
mysql>REPAIR TABLE consommation USE_FRM;
+-------------------------+--------+----------+----------------------------------------+
Table Op Msg_type Msg_text
+-------------------------+--------+----------+----------------------------------------+
prodia_sas.consommation repair warning Number of rows changed from 0 to 24681
prodia_sas.consommation repair status OK
+-------------------------+--------+----------+----------------------------------------+
2 rows in set (0.34 sec)
mysql>exit;

Autres Info sur ce problème : L'origine du problème est encore à déterminer, mais il faut savoir que la première erreur se situe entre le moment ou la sauvegarde XCS (Oracle) a été effectée et le lancement du dump de la base Mysql. Je pense a un lockage de l'application de Production (Créer par moi) du au fait que la connexion à Oracle s'est terminée brusquement. Une grande partie du problème chez Prodia, c'est que mon application tourne 24/24 365j/an. Je préconise un arret de l'application de Production pendant les sauvegardes, Mais je ne sais pas encore comment réaliser ce miracle : cela ne sera pas facile car tout l'atelier laisse en général les écrans ouverts. Le seul moyen serait de récuperer le N° d'Erreur Oracle et de killer l'application à ce moment là.

Libellés : , , ,

0 commentaires:

Enregistrer un commentaire

Abonnement Publier les commentaires [Atom]



<< Accueil