Réponses:
Si vous souhaitez effectuer correctement les sauvegardes MySQL, sans aucun temps d'arrêt, vous devez répliquer la base de données sur un serveur de rechange. Il n'a pas besoin d'être extrêmement puissant, il suffit de faire face à la charge d'écriture de votre base de données master. Vous ne devez pas utiliser ce serveur en production. Si la réplication ne se poursuit jamais, vous avez besoin d'un serveur plus puissant. Vous pouvez vérifier en comparant le fichier journal et la position de la sortie de
> SHOW MASTER STATUS\G
sur le maître et
> SHOW SLAVE STATUS\G
sur l'esclave. Je pense que MySQL5 montrera le retard SHOW SLAVE STATUS
.
Lorsque vous êtes heureux que votre esclave se maintienne, vous pouvez faire vos sauvegardes en faisant
SLAVE STOP;
sur l'esclavemysqldump --opt
sur le serveur esclave.SLAVE START;
sur l'esclaveSi vous faites cela, vous aurez une sauvegarde cohérente de vos bases de données. Cette méthode empêche différentes bases de données ou pire encore, différentes tables de la même base de données ne sont pas synchronisées et empêche les temps d'arrêt en verrouillant les tables pour les écritures pendant que vous effectuez la sauvegarde.
Un bon avantage de cette configuration est que vous avez une copie de votre base de données que vous pouvez utiliser pour exécuter de longues requêtes coûteuses qui n'affecteront pas votre service en direct.
Quelques conseils aléatoires:
mysqldump --opt
, car c'est généralement le moyen le plus rapide d'importer le SQL résultantJ'utilise un script qui utilise mysqldump
pour extraire les données / schéma dans un fichier pour chaque base de données. Les données sont sauvegardées par la sauvegarde normale de netbackup sur bande. Vous pouvez évidemment ajouter d'autres cloches et sifflets, mais cela fait un vidage de base simpe.
#!/bin/sh
# Find out what databases are in mysql and back them up
# Delete old backups
STARTTIME=` date +%Y%m%d-%H%M `
#BACKUP_DIR="/usr/local/db_backups"
BACKUP_DIR="/var/local/db_backups"
LOGFILE="/var/log/db_backups.log"
USER="root"
PASSWD="<password>"
KEEP="7"
(
echo
echo " ---MySQL backups start ${STARTTIME} ---"
#delete any backup written more than ${KEEP} days ago
echo "Removing files over ${KEEP} days old from ${BACKUP_DIR}:"
/usr/bin/find ${BACKUP_DIR} -mindepth 1 -mtime +${KEEP} -print -delete
echo
echo "Performing today's dumps"
#find each database running in this instance of mysl
for DB in ` echo "show databases;"|mysql -u${USER} -p${PASSWD} mysql |awk " NR>1 {print $1} " `
do
#generate a backup file name based on the data base name
BACKUP_FILE="${BACKUP_DIR}/${DB}-${STARTTIME}.sql"
echo "Processing database ${DB} into file ${BACKUP_FILE}"
# dump the database data/schema into the backup file
mysqldump -u${USER} -p${PASSWD} --add-drop-table ${DB} > ${BACKUP_FILE}
gzip ${BACKUP_FILE}
done
ENDTIME=` date +%Y%m%d-%H%M `
echo
echo " ---MySQL backups complete ${ENDTIME} ---"
echo
) >> ${LOGFILE} 2>&1
Habituellement, les bases de données sont sauvegardées une fois par jour si elles doivent être arrêtées, puis les sauvegardes sont transférées vers une zone de stockage pour consolidation puis elles sont enregistrées sur bande.
Les sauvegardes de base de données sont effectuées avec les outils natifs fournis avec le moteur de base de données la plupart du temps.
Les sauvegardes ne doivent pas être conservées sur les serveurs avec les données en cas de panne matérielle.
Il est assez recommandé d'avoir des répliques à jour de vos serveurs de bases de données lorsque cela est possible, mieux vaut avoir un macanisme de basculement pour les bases de données de production.
Pour les logiciels, vous pouvez par exemple jeter un œil à bacula ou zmanda
Notre configuration standard est un cluster HA avec deux bases de données se répliquant l'une sur l'autre qui est en lecture seule.
Nous effectuons une sauvegarde complète une fois par jour et avons ensuite une politique par client d'éliminer les anciennes sauvegardes, généralement nous gardons 4 dernières sauvegardes quotidiennes (pour survivre le week-end;), 4 derniers dimanches et 4 derniers premiers dimanches dans un mois. Après cela, une ou deux décharges par an vont aux archives pour être conservées pour toujours.
Nous conservons également les journaux de réplication aussi longtemps que nous pouvons nous permettre d’économiser l’espace disque. Ils sont également très utiles comme outil de débogage car ils enregistrent exactement qui a changé quoi et quand.
Théoriquement, tout ce dont vous avez besoin est d'une sauvegarde complète et de tous les journaux de réplication pour pouvoir effectuer une restauration ponctuelle, mais des sauvegardes complètes plus fréquentes accéléreront la restauration.
Une astuce intéressante avec la sauvegarde consiste à utiliser les tables innodb et le paramètre --single-transaction pour le vidage mysql, de cette façon la sauvegarde ne bloquera pas la base de données pendant son exécution.
Le but de la sauvegarde est de pouvoir restaurer.
Je ne recommanderais pas un vidage CSV comme solution de sauvegarde; tout ce qu'il vous donnera, ce sont les données brutes. Il y a beaucoup plus à côté de cela, en particulier avec une base de données. Description des tableaux, vues, proc stockés, vous l'appelez. Si vous ne les avez pas également, vous ne pourrez pas les récupérer avec succès. Il y a aussi l'application et la configuration du SGBDR à considérer. Vous pouvez avoir un grand nombre de correctifs sur lesquels vous devrez également mettre votre environnement de récupération pour le mettre au même niveau. Vous exécutez peut-être une configuration spéciale dictée par les exigences de vos applications. Vous pouvez même avoir un ensemble spécifique de paramètres de système d'exploitation requis pour que votre base de données fonctionne de manière optimale. Tous ces éléments devront également être récupérés, et à moins que vous n'ayez une solution de sauvegarde capable de les faire, cela retarde davantage votre temps de récupération,
Pour les sauvegardes de bases de données (et les sauvegardes en général), je préférerais toujours utiliser un "vrai" logiciel de sauvegarde capable de gérer tout cela.
Plus récemment, j'ai géré des serveurs MySQL dans EC2. Nous avons configuré des instantanés EBS sur une tâche cron de 15 minutes, 3 à 5 instantanés ont été conservés.
Lorsque nous faisions des serveurs MySQL «traditionnels», nous sauvegardions quotidiennement via MySQl-ZRM. Les sauvegardes sont essentiellement des mysqldumps, qui sont envoyés sur bande, SAN, etc., selon les besoins du client.
Les deux méthodes peuvent être effectuées sans arrêter la base de données.
Pour MySQL, j'utilise automysqlbackup ( http://sourceforge.net/projects/automysqlbackup/ ), car mon logiciel de sauvegarde (Backup Exec) ne prend pas en charge les instantanés sur les systèmes Linux.
Cela fonctionne bien, mais je vais surveiller ce fil pour des suggestions :)
Nous effectuons des sauvegardes deux fois par jour et exécutons également des sauvegardes de journal toutes les 10 à 15 minutes.
L'avantage de cette méthode est que vous pouvez restaurer à partir de l'une des sauvegardes deux fois par jour, puis appliquer les fichiers journaux au plus tard au cours des 15 dernières minutes. De cette façon, vous minimisez la quantité de données que vous pouvez perdre.
Cependant, la fréquence à laquelle vous sauvegardez vos données dépend de vous. Combien de données êtes-vous prêt à perdre? Si vous pouvez vous permettre de perdre une journée de données, sauvegardez une fois par jour. Les données ne changent jamais? Ensuite, vous n'avez besoin que d'une copie!