myisamchk : mySQL doit-il etre arreté ?

16 réponses

Auteur	Message
krucial \| Administrateur Inscrit le : 09/03/2005	# Le 29/03/2007 à 11:45 Yop Petite question : pour faire un myisamchk, il faut que mysql soit coupé ? Actuellement, je coupe mysql, mais je me demande si c'est vraiment obligé. Qqu sait ? JC - Mes sites \| Affiliation devis travaux \| Cotes voitures anciennes
Rano \| Jean Modérateur Inscrit le : 13/04/2005	# Le 29/03/2007 à 11:48 You must ensure that no other program is using the tables while you are running myisamchk. The most effective means of doing so is to shut down the MySQL server while running myisamchk, or to lock all tables that myisamchk is being used on. Chambres d'hote tavel Séjours en provence Forum mariage
SquawK \| Blabla Modérateur Inscrit le : 09/05/2005	# Le 29/03/2007 à 11:48 Je dirais que c'est obligé si tu veux pas avoir de problèmes. Comparatif pc portable
krucial \| Jean Christophe Administrateur Inscrit le : 09/03/2005	# Le 29/03/2007 à 12:18 Vous le faites souvent vous ? JC - Mes sites \| Affiliation devis travaux \| Cotes voitures anciennes
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 29/03/2007 à 17:14 Debian lance un controle en lecture seule à chaque démarrage de MySQL (en parallèle). C'est à mon avis largement suffisant... les tables n'étant pas sensées se corrompre. Ca n'arrive normalement qu'en cas de coupure électrique daevel : infogérance et conseil \|\| moi
Rano \| Jean Modérateur Inscrit le : 13/04/2005	# Le 29/03/2007 à 17:21 Je le fais toutes les nuits aussi, avec --sort-index. Il me semblait que ça permettait de reconstruire les index et "enseigner" à mysql la meilleure façon de les utiliser. Rebooter mysql sur debian, est suffisant ? (Enfin, arret puis démarrage dans le but de faire un backup entre les deux) Chambres d'hote tavel Séjours en provence Forum mariage
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 29/03/2007 à 17:25 Je fais mes backups à chaud, via un mysqldump. C'est un peu plus long, mais permet de sauvegarder à distance sans réelle coupure. Et l'export est "utilisable" (un simple fichier .sql, découpable, et rechargeable sur une autre version sans problème de compatibilité, etc). MySQL n'est jamais rebooté, sauf mise à jour de sécurité. Pour le "sort index", il me semblait qu'un "optimize table" suffisait. Je vérifierai. daevel : infogérance et conseil \|\| moi
Rano \| Jean Modérateur Inscrit le : 13/04/2005	# Le 29/03/2007 à 17:44 en backup à chaud j'utilise mysqlhotcopy dans certains cas, c super rapide Chambres d'hote tavel Séjours en provence Forum mariage
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 29/03/2007 à 17:51 mouais, ça verrouille les tables, copie les fichiers, et déverrouille. C'est pratique car rapide, mais ça ne marche qu'en local, et qu'avec les tables myisam. Je ne suis vraiment pas fan. daevel : infogérance et conseil \|\| moi
kigenaou \| Paul Membre Inscrit le : 09/05/2005	# Le 29/03/2007 à 19:09 Bool a dit : Je fais mes backups à chaud, via un mysqldump. C'est un peu plus long, mais permet de sauvegarder à distance sans réelle coupure. Et l'export est "utilisable" (un simple fichier .sql, découpable, et rechargeable sur une autre version sans problème de compatibilité, etc). Petit bemol a ce sujet dont j'ai fait les frais recement ... Penser à bien verifier que les fichiers SQL sont utilisables dans l'etat ... pour ma part il manquait l'option de quotes de noms de tables ... certains noms etant des mots reserves, j'ai galeré comme un c..
Rano \| Jean Modérateur Inscrit le : 13/04/2005	# Le 29/03/2007 à 20:32 oui, ca marche juste avec les myisam c'est vrai, par contre le fait que ce soit en local, je trouve pas ca génant. Quand ma machine de backup veut faire une sauvegarde, j'ai un : ssh truc@pouet.com "/root/script_mysqlhotcopy.sh" avec script_mysqlhotcopy.sh qui fait un backup local très rapidement, qui ne bloque donc pas mysql longtemps (après voilà, c'est pas forcément les mêmes problématiques ) et ensuite un sync pour récupérer ca sur le serveur de backup. Chaque truc a son avantage et inconvénient, mais comme j'ai découvert mysqlhotcopy y a pas longtemps, je voulais partager Chambres d'hote tavel Séjours en provence Forum mariage
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 04/08/2008 à 21:24 Gros déterrage La taille des bases de données ne cessant pas d'augmenter j'ai du faire une croix sur mon backup à coup de mysqldump . Bloquer MySQL en lecture même pendant deux minutes, pour certains sites ce n'est pas vraiment envisageable en particulier si on doit faire un backup en pleine journée. Mais mysqlhotcopy par contre n'est pas utilisable pour toutes les tables... Je me suis donc tourné vers mylvmbackup qui repose sur le système de snapshot de LVM. Bon du coup il faut un partitionnement LVM, et ça prend toutes les bases de données d'un coup... Mais en contrepartie on peut sauvegarder des dizaines de Go de données avec un pauvre verrou d'1 seconde ; c'est franchement sympa. J'avais vu ça sur MySQLPerformanceBlog (y a le lien dans le dossier MySQL de WMC) donc j'ai tenté. Je suis d'ailleurs passé à LVM pour l'occasion, et je trouve ça également très pratique. (Message édité le 04-08-2008 à 21h29 par Bool) daevel : infogérance et conseil \|\| moi
flush \| Jean-Philippe Modérateur Inscrit le : 09/05/2005	# Le 04/08/2008 à 22:34 Pour le mysqldump, nous on a carrément mis un serveur en réplication, et on fait notre dump sur le SLAVE. Aucune coupure de cette manière ^^ MySQL conseille de faire un OPTIMIZE TABLE de chaque grosse table tous les jours, et toutes les petites une fois par mois. @+ Jean-Philippe
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 04/08/2008 à 23:08 Je ne suis pas vraiment fan de la réplication en fait, je n'ai pas beaucoup testé mais j'ai lu pas mal de problèmes. Sinon c'est effectivement une excellente solution : le verrou imposé par le dump a certainement moins d'impact sur le serveur de réplication. PS : quant au "optimize table", c'est effectivement très important. J'ai tendance à le faire toutes les nuits sur toutes les tables (la taille des bases que j'administre le permet encore en tous cas). daevel : infogérance et conseil \|\| moi
flush \| Jean-Philippe Modérateur Inscrit le : 09/05/2005	# Le 04/08/2008 à 23:29 Chez nous la réplication est en place depuis avril, et franchement ça marche super bien. Et il nous sert pour les lectures et calcul de stats un peu plus lourd, c'est vraiment très pratique. Le master a déjà planté plusieurs fois, il reboot et jamais aucune perte ou décalage sur le SLAVE ! @+ Jean-Philippe
SquawK \| Blabla Modérateur Inscrit le : 09/05/2005	# Le 04/08/2008 à 23:38 MySQL conseille de faire un OPTIMIZE TABLE de chaque grosse table tous les jours, et toutes les petites une fois par mois. 500 Mo c'est gros ou petit ? Comparatif pc portable
flush \| Jean-Philippe Modérateur Inscrit le : 09/05/2005	# Le 04/08/2008 à 23:42 500 mo pour une table, ça commence à être gros pour moi oui. Après faut voir le nombre d'enregistrements ... @+ Jean-Philippe

Auteur

Message

krucial |
Administrateur

Inscrit le : 09/03/2005

# Le 29/03/2007 à 11:45

Yop

Petite question : pour faire un myisamchk, il faut que mysql soit coupé ? Actuellement, je coupe mysql, mais je me demande si c'est vraiment obligé. Qqu sait ?

JC - Mes sites | Affiliation devis travaux | Cotes voitures anciennes

Rano | Jean
Modérateur

Inscrit le : 13/04/2005

# Le 29/03/2007 à 11:48

You must ensure that no other program is using the tables while you are running myisamchk. The most effective means of doing so is to shut down the MySQL server while running myisamchk, or to lock all tables that myisamchk is being used on.

Chambres d'hote tavel
Séjours en provence
Forum mariage

SquawK | Blabla
Modérateur

Inscrit le : 09/05/2005

# Le 29/03/2007 à 11:48

Je dirais que c'est obligé si tu veux pas avoir de problèmes.

Comparatif pc portable

krucial | Jean Christophe
Administrateur

Inscrit le : 09/03/2005

# Le 29/03/2007 à 12:18

Vous le faites souvent vous ?

JC - Mes sites | Affiliation devis travaux | Cotes voitures anciennes

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 29/03/2007 à 17:14

Debian lance un controle en lecture seule à chaque démarrage de MySQL (en parallèle). C'est à mon avis largement suffisant... les tables n'étant pas sensées se corrompre.

Ca n'arrive normalement qu'en cas de coupure électrique

daevel : infogérance et conseil || moi

Rano | Jean
Modérateur

Inscrit le : 13/04/2005

# Le 29/03/2007 à 17:21

Je le fais toutes les nuits aussi, avec --sort-index. Il me semblait que ça permettait de reconstruire les index et "enseigner" à mysql la meilleure façon de les utiliser.
Rebooter mysql sur debian, est suffisant ? (Enfin, arret puis démarrage dans le but de faire un backup entre les deux)

Chambres d'hote tavel
Séjours en provence
Forum mariage

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 29/03/2007 à 17:25

Je fais mes backups à chaud, via un mysqldump. C'est un peu plus long, mais permet de sauvegarder à distance sans réelle coupure.
Et l'export est "utilisable" (un simple fichier .sql, découpable, et rechargeable sur une autre version sans problème de compatibilité, etc).

MySQL n'est jamais rebooté, sauf mise à jour de sécurité.

Pour le "sort index", il me semblait qu'un "optimize table" suffisait. Je vérifierai.

daevel : infogérance et conseil || moi

Rano | Jean
Modérateur

Inscrit le : 13/04/2005

# Le 29/03/2007 à 17:44

en backup à chaud j'utilise mysqlhotcopy dans certains cas, c super rapide

Chambres d'hote tavel
Séjours en provence
Forum mariage

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 29/03/2007 à 17:51

mouais, ça verrouille les tables, copie les fichiers, et déverrouille.

C'est pratique car rapide, mais ça ne marche qu'en local, et qu'avec les tables myisam. Je ne suis vraiment pas fan.

daevel : infogérance et conseil || moi

kigenaou | Paul
Membre

Inscrit le : 09/05/2005

# Le 29/03/2007 à 19:09

Bool a dit :
Je fais mes backups à chaud, via un mysqldump. C'est un peu plus long, mais permet de sauvegarder à distance sans réelle coupure.
Et l'export est "utilisable" (un simple fichier .sql, découpable, et rechargeable sur une autre version sans problème de compatibilité, etc).

Petit bemol a ce sujet dont j'ai fait les frais recement ...

Penser à bien verifier que les fichiers SQL sont utilisables dans l'etat ... pour ma part il manquait l'option de quotes de noms de tables ... certains noms etant des mots reserves, j'ai galeré comme un c..

Rano | Jean
Modérateur

Inscrit le : 13/04/2005

# Le 29/03/2007 à 20:32

oui, ca marche juste avec les myisam c'est vrai, par contre le fait que ce soit en local, je trouve pas ca génant. Quand ma machine de backup veut faire une sauvegarde, j'ai un :

ssh truc@pouet.com "/root/script_mysqlhotcopy.sh"

avec script_mysqlhotcopy.sh qui fait un backup local très rapidement, qui ne bloque donc pas mysql longtemps (après voilà, c'est pas forcément les mêmes problématiques ) et ensuite un sync pour récupérer ca sur le serveur de backup.

Chaque truc a son avantage et inconvénient, mais comme j'ai découvert mysqlhotcopy y a pas longtemps, je voulais partager

Chambres d'hote tavel
Séjours en provence
Forum mariage

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 04/08/2008 à 21:24

Gros déterrage

La taille des bases de données ne cessant pas d'augmenter j'ai du faire une croix sur mon backup à coup de mysqldump . Bloquer MySQL en lecture même pendant deux minutes, pour certains sites ce n'est pas vraiment envisageable en particulier si on doit faire un backup en pleine journée.
Mais mysqlhotcopy par contre n'est pas utilisable pour toutes les tables...

Je me suis donc tourné vers mylvmbackup qui repose sur le système de snapshot de LVM. Bon du coup il faut un partitionnement LVM, et ça prend toutes les bases de données d'un coup... Mais en contrepartie on peut sauvegarder des dizaines de Go de données avec un pauvre verrou d'1 seconde ; c'est franchement sympa.

J'avais vu ça sur MySQLPerformanceBlog (y a le lien dans le dossier MySQL de WMC) donc j'ai tenté. Je suis d'ailleurs passé à LVM pour l'occasion, et je trouve ça également très pratique.

(Message édité le 04-08-2008 à 21h29 par Bool)

daevel : infogérance et conseil || moi

flush | Jean-Philippe
Modérateur

Inscrit le : 09/05/2005

# Le 04/08/2008 à 22:34

Pour le mysqldump, nous on a carrément mis un serveur en réplication, et on fait notre dump sur le SLAVE.

Aucune coupure de cette manière ^^

MySQL conseille de faire un OPTIMIZE TABLE de chaque grosse table tous les jours, et toutes les petites une fois par mois.

@+ Jean-Philippe

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 04/08/2008 à 23:08

Je ne suis pas vraiment fan de la réplication en fait, je n'ai pas beaucoup testé mais j'ai lu pas mal de problèmes.
Sinon c'est effectivement une excellente solution : le verrou imposé par le dump a certainement moins d'impact sur le serveur de réplication.

PS : quant au "optimize table", c'est effectivement très important.
J'ai tendance à le faire toutes les nuits sur toutes les tables (la taille des bases que j'administre le permet encore en tous cas).

daevel : infogérance et conseil || moi

flush | Jean-Philippe
Modérateur

Inscrit le : 09/05/2005

# Le 04/08/2008 à 23:29

Chez nous la réplication est en place depuis avril, et franchement ça marche super bien. Et il nous sert pour les lectures et calcul de stats un peu plus lourd, c'est vraiment très pratique.

Le master a déjà planté plusieurs fois, il reboot et jamais aucune perte ou décalage sur le SLAVE !

@+ Jean-Philippe

SquawK | Blabla
Modérateur

Inscrit le : 09/05/2005

# Le 04/08/2008 à 23:38

MySQL conseille de faire un OPTIMIZE TABLE de chaque grosse table tous les jours, et toutes les petites une fois par mois.

500 Mo c'est gros ou petit ?

Comparatif pc portable

flush | Jean-Philippe
Modérateur

Inscrit le : 09/05/2005

# Le 04/08/2008 à 23:42

500 mo pour une table, ça commence à être gros pour moi oui. Après faut voir le nombre d'enregistrements ...

@+ Jean-Philippe

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.