Moyen optimal pour effectuer des sauvegardes MySQL pour des bases de données assez volumineuses (MyISAM / InnoDB)

8

Actuellement, nous avons une base de données MySQL robuste qui gère quelques sites Web à fort trafic basés sur Django ainsi que certains sites Web de commerce électronique de taille décente. En conséquence, nous avons une quantité considérable de grandes bases de données utilisant à la fois les tables InnoDB et MyISAM.

Malheureusement, nous avons récemment heurté un mur en raison de la quantité de trafic, j'ai donc configuré un autre serveur maître pour aider à alléger les lectures / sauvegardes.

Maintenant, pour le moment, j'utilise simplement mysqldump avec quelques arguments et cela s'est avéré être correct .. jusqu'à maintenant. Évidemment, mysqldump est une méthode rapide et lente, mais je pense que nous avons dépassé son utilisation. J'ai maintenant besoin d'une bonne alternative et j'ai cherché à utiliser l'utilitaire Maatkits mk-parallel-dump ou une solution d'instantané LVM.

Version courte succincte:

J'ai une assez grande base de données MySQL que je dois sauvegarder
La méthode actuelle utilisant mysqldump est inefficace et lente (causant des problèmes)
Examen de quelque chose comme mk-parallel-dump ou des instantanés LVM

Toutes les recommandations ou idées seraient appréciées - puisque je dois refaire la façon dont nous faisons les choses, je préfère que ce soit fait correctement / le plus efficacement :).

mysql backup database-backup

— WinkyWolly
source

5

J'ai eu un bon succès avec la réplication MySQL et les tarballs nocturnes. Pour les bases de données plus petites, la base de données mysql et le schéma, j'utilise une combinaison de scripts conçus pour utiliser mysqlhotcopy et mysqldump.

La sauvegarde à chaud InnoDB est un excellent produit commercial, mais je ne sais pas comment elle gère les tables mixtes dans la même base de données. La recommandation de pQd pour XtraBackup peut être bonne à comparer avec cela.

D'autres aiment les instantanés LVM et je dirais que c'est certainement quelque chose à considérer. En fin de compte, une combinaison de solutions serait probablement la meilleure.

Il est également à noter qu'il s'agit d'un sujet ancien. Entre le livre MySQL High Performance , le manuel MySQL et les questions précédentes de ServerFault, cela a été épuisé de manière générale. Voir:

— Warner
source

+1; avec myisam, vous ne savez jamais si vous avez une sauvegarde logique cohérente [prise par lvm / mysqldump / de lave] ou non. peut-être que si votre application ne change que pendant les heures ouvrables - vous pouvez la vider en toute sécurité la nuit, sinon - vous n'êtes jamais sûr et aucune méthode ne vous aidera.

— pQd

Je pense que vous avez raison de mélanger des solutions. Comme mentionné dans la réponse de pQd, je vais probablement prendre les instantanés LVM et regarder l'utilitaire xtrabackup (il dit qu'il peut gérer des tables mixtes). J'ai examiné la sauvegarde à chaud d'InnoDB mais je suis toujours un pour les projets open source. Merci pour les références, j'ai examiné 2 des mais les réponses sont assez génériques / ne traitent pas les problèmes que j'ai / ils font référence à des bases de données plus "normales" et "banales".

— WinkyWolly

4

xtrabackup - au moins pour innodb.

— pQd
source

Intéressant mais j'aimerais une solution plus gracieuse pour ne pas vous soucier de mon mélange de tables InnoDB / MyISAM.

— WinkyWolly

xtrabackup est livré avec un script qui peut également vous aider à prendre des sauvegardes de myisams, mais consultez mon commentaire dans le post de Warner

— pQd

Merci, on dirait que je pourrais aller dans cette direction et mélanger des instantanés LVM pour faire bonne mesure. Il indique qu'il peut également "gérer" les tables MyISAM via le script "innobackupex". Je suppose que je vais faire un tourbillon et voir exactement ce qui se passe.

— WinkyWolly

3

La façon la plus courante de résoudre ce problème consiste à configurer un autre serveur MySQL, qui peut même se trouver sur la même machine, et à exécuter la réplication maître / esclave. Vous pouvez ensuite effectuer la sauvegarde sur l'esclave, sans impact sur le maître.

— John Gardeniers
source

0

Sur EC2 EBS, j'utilise actuellement xfs_freeze. J'envisage de passer éventuellement à xtrabackup à un moment donné, mais quand je l'ai fait un premier test, c'était très, très gourmand en CPU.

— user5336
source

Malheureusement, je n'utilise XFS que sur des serveurs multimédias pour le moment, ce n'est donc pas une option. Quel genre d'expérience (à part faim de CPU, peut-être plus de détails?) Avez-vous eu avec xtrabackup? Sauvegardiez-vous des tables InnoDB pures ou un mix?

— WinkyWolly

Ma plus grande hésitation était qu'elle mâchait le processeur pendant environ 30 minutes à la fin (sauvegarde d'une base de données d'environ 35 Go de données), ce qui ne rendait le serveur DB que légèrement fonctionnel - certainement pas quelque chose que je pourrais probablement exécuter sur un maître de production . En fait, j'avais déjà converti mes quelques tables MyISAM restantes en InnoDB partiellement à cette fin. Je pense que ce serait probablement OK de fonctionner sur un esclave tant que cela n'entraîne pas un retard substantiel de la réplication.

— user5336

0

Si vous exécutez la réplication d'une base de données partagée entre plusieurs applications, il semble évident que vous pouvez améliorer les performances de nombreuses choses, y compris les sauvegardes, en dédiant les serveurs de base de données aux applications. Partagé est agréable, jusqu'à ce qu'il ne soit pas.

— Justin Alan Ryan
source

0

Si vous conservez vos tables MyISAM uniquement pour des raisons héritées (vous n'avez pas pris la peine de les modifier), voici ce que j'utilise pour corriger facilement cela:

    mysql -u root --password=<password> --database=db_name -B -N -e "SHOW TABLES" | awk '!/not_this_db/ && !/or_this_one/ && /^[a-z]/ {print "ALTER TABLE", $1, "ENGINE=INNODB;"}' | mysql -u root --password=<password> --database=db_name

Vous pouvez exclure et inclure des bases de données avec l'expression rationnelle awk, comme uniquement dbs commençant par une lettre minuscule dans mon exemple ci-dessus. Cela verrouillera bien sûr les tables pendant la modification.

Utilisez ensuite xtrabackup pour copier l'intégralité de la base de données directement sur un autre serveur sans verrouiller aucune table ni utiliser trop d'E / S de disque (après avoir configuré les clés ssh rsa):

innobackupex --throttle=500 --compress --stream=xbstream /doesntneedtoexist | ssh user@otherhost "xbstream -x -C /root/backup/"

et ensuite vous pouvez faire l'étape d'application du journal complètement séparée et économiser de l'espace disque, des E / S et du processeur sur le serveur de production.

HowTo de Percona pour utiliser xtrabackup

— Brad
source