Le 23/03/18 à 20:23, Eric Degenetais <[email protected]> a écrit :
ED> Le 23 mars 2018 21:18, <[email protected]> a écrit : ED> ED> > J'ai trouvé encore plus simple ! ED> > Avec la doc envoyé par Timoté Brusson, je suis retombé sur un truc ED> > "pré-fait" est-ce viable ? ( https://doc.ubuntu-fr.org/automysqlbackup ED> > ) Car ça semble de bien fonctionner.. ED> ED> Bonsoir, oui c'est un bon outil, ça s'utilise même sur des ED> environnements de production commerciale. Pour l'usage perso ce script a l'air très bien (pas regardé en détail mais il date de 2011 donc si y'avait un gros pb faut espérer que ça se saurait). Pour un environnement de prod il a quand même un défaut, il lance mysqldump sur la base alors qu'elle est toujours en usage, donc sur des bases utilisées au moment du dump ça pose pb. Soit il lock globalement et le mysql risque fort d'exploser pendant ce temps là (toutes les requêtes en écriture sont en attente, si le dump dure plusieurs minutes ça peut suffire à saturer mysql), soit il dump & lock seulement par table, ce qui peut poser le même pb mais qui peut surtout conduire à des données inconsistantes (une clé externe référencées dans une table mais qui n'existait pas au moment du dump de sa table, fait auparavant). Pour du perso où pas grand monde écrit, surtout à l'heure du backup, et avec de petites bases le risque est faible, mais j'utiliserais pas ça sur ma production ;-) Pour régler le pb du lock je fais du snapshot lvm avec flush & lock juste avant et unlock juste après, ça prend 1~3s et ça passe, puis rsync de /var/lib/mysql (en fait de toute la vm) puis dump tranquillement sur une autre machine plus tard. Sinon y'a aussi la solution master/slave, en utilisant le slave pour le dump (en coupant la réplication avant et en la remettant après), mais ça consomme bcp d'I/O pour rien sur le slave toute la journée. J'ai fait ça un moment mais le disque arrivait à 100% 24/24, car la machine avait plusieurs slave et plusieurs master à suivre, trop cher de prendre une machine ssd par mysql à backuper, avec le snap+rsync un serveur pas cher sans ssd dump tout le monde. -- Daniel Travailler dur n'a jamais tué personne, mais pourquoi prendre le risque ? Edgar Bergen
