Discussion :

[deew599]

Bonjour a vous,

voila mon soucis..

J'ai un mysql 5.1 sur un windows serveur 2008 , je fais des DUMP tout les soirs à 00h00.
Durant ce dump, mysql doit sans doute lock les tables, mais le soucis c'est que les processus httpd (apache) s'accumule sur mon serveur Apache et dans certain cas le serveur plante.

voila j'aurai aimer savoir comment vous faisiez pour vos DUMP (ma base fait plusieur GIGA, les dumps dure plus de 10 min)

toute solution est la bienvenu .

Merci d'avance

[SQLpro]

MySQL n'est pas en mesure à ce jour de permettre une sauvegarde cohérente à chaud sans verrouiller les tables. Si votre site fonctionne 24h/24 et avec un fort volume et trafic, orientez vous vers PostGreSQL ou mieux, Oracle, SQL Server....

A +

[deew599]

merci de votre reponse.

mais je pense que je vais m'orienter vers un second serveur en slave pour faire mes DUMP et ne pas le faire sur le serv de prod.

par contre pour info j'ai vu que si je passais mes table en engine INNODB , seul la ligne lu serai lock et non la table entière comme en MyIsam dans mon cas (je ne peux pas changer car je dois garder mes index fullText).

pour le moment une migration vers un autre system est assez dur a envisager pour moi (manque de temps et de compétence)

[kedare]

Essais de passer a InnoDB et d'utiliser un système de recherche externe style Sphinx ( http://www.sphinxsearch.com/ )

PostGreSQL ou mieux, Oracle, SQL Server....

Troll ?

[SQLpro]

par contre pour info j'ai vu que si je passais mes table en engine INNODB , seul la ligne lu serai lock et non la table entière comme en MyIsam dans mon cas (je ne peux pas changer car je dois garder mes index fullText).

Ce sera pire, car votre sauvegarde risque d'être incohérente. Du genre sauvegarde de la table client, puis insertion client et facture, puis sauvegarde table facture. Au restore, il y aura une facture sans client !
MySQL n'est pas en mesure à ce jour de permettre une sauvegarde cohérente à chaud sans verrouiller les tables, quelque soit le moteur de stockage choisit !
C'est une anomalie gravissime bien connue et non résolue à ce jour car cela impose de nombreux changements technique remettant en cause les principes même de fonctionnement de MySQL !

A +

[peufeu]

Lire ici :

http://www.innodb.com/doc/hot_backup/manual.html

Bref. Si tu utilises MyISAM, il faut que tu te poses une question : si tes données sont suffisamment importantes pour justifier une sauvegarde, pourquoi les stocker dans un type de table qui n'offre aucune garantie d'intégrité ? Pas de contraintes, pas de FK, aucune garantie en cas de crash, et d'ailleurs, si il y a un crash, il est fort probable que tu perdras des bouts de table, ou alors ta table est corrompue et nécessite un REPAIR (ce qui peut prendre des plombes), ou alors tes index sont corrompus et tes requêtes renvoient des résultats faux, etc. Et comme il y a eu un crash...

Donc première chose : MyISAM ne doit être utilisé que pour du read-only, du cache, des tables temporaires, etc, bref des choses pour lesquelles MyISAM va bien parce que c'est un format compact

Donc, toute donnée importante doit être en InnoDB, avec contraintes, etc.

Ah, oui, le FULLTEXT.

J'avais fait des benchmarks assez poussés il y a environ 2 ans et les résultats furent que :

- Le FULLTEXT de MySQL est vraiment misérable
- Postgres est 10-100x plus rapide,
- Xapian est 10-100x plus rapide que Postgres

quand ça commence à dépasser un peu la RAM, le fulltext de MYSQL s'effondre, celui de Postgres fatigue, celui de Xapian ne remarque rien, il continue à tourner à une vitesse hallucinante.

Il paraît que Sphinx est au même niveau que Xapian.

Donc tu vois le FULLTEXT est un faux argument, la solution est de virer le fulltext mysql et de prendre un vrai moteur. En plus Sphinx/Xapian sont beaucoup plus puissants, et franchement, les INSERT/UPDATE sur les index FULLTEXT de MySQL, je les ai assez vus.

Si tu veux éviter que 1000 process apache crash ton serveur, utilise lighttpd qui gère parfaitement bien ce genre de cas, ou alors un squid ou apache-proxy devant un apache avec au max 10-20 process.

Perso, je mettrais Postgres, ou SQL Server si tu es marié à Windows.

[kedare]

Pourtant logiquement si on fait le backup depuis une transaction, c'est sensé être cohérent, non ?

[peufeu]

Pourtant logiquement si on fait le backup depuis une transaction, c'est sensé être cohérent, non ?

Certes, mais là il est sous MyISAM

[deew599]

Encore merci pour vos reponses

En fait j'utilise déjà lucene couplé de solr pour mes recherches, trés efficace soit dit en passant, j'avais tester sphinx qui gère très bien aussi mais est moins pratique sur l'indexation a la volé.

sinon cette table que je sauvegarde est utilisé quasi qu'en lecture et est mis a jour grâce a des cron tous les jours, mais j'ai encore besoin de mes fulltext pour certaine recherche et mysql suffit pour celle ci, pour les autre j'ai lucéne ;p.

par contre mettre un serveur en slave pour mes sauvegardes personne n'en a parlé , ce n'est pas une bonne idee?

edit:je n'ai pas de données vraiment critique, le site peu s'apparenter a un "forum" amélioré

[omiossec]

L'utilisation d'une réplication master/slave peut être une partie de la réponse à votre problème (le site lag lors du backup).
Cependant il y aura toujours un problème votre base qui fait plusieurs GIGA.
MySqlDUMP n'est pas un outil de sauvegarde, mais un outil permettant de faire des export au format texte de vos données.
Il est généralement utilisé avec les options par défaut (en mode SQL) et sur les bases de plusieurs Go c'est l'horreur garantie si vous voulez faire une restauration (une lenteur enorme même avec --extended-insert et il n'est pas dit que vous irez jusqu'au bout ...). L'utilisation de --tab est à préférer.

Il faut bien se rappeler que le but d'une sauvegarde et de pouvoir restaurer des données cohérente rapidement sans (trop de) perte de données.

Avez vous envisager les sauvegarde à froid sur un SLAVE ?

[deew599]

Avez vous envisager les sauvegarde à froid sur un SLAVE ?

le slave aurai cette utilité en fait (pas encore installé)