Re: Backups automatiques d'une base de donnée vers un périphérique de stockage
Le 23/03/18 à 20:23, Eric Degenetais <edegenetais@henix.fr> a écrit :
ED> Le 23 mars 2018 21:18, <vandendaelenclement@gmail.com> 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
Reply to: