Respuestas:
Si desea realizar copias de seguridad de MySQL correctamente, sin ningún tiempo de inactividad, debe replicar la base de datos en un servidor de reserva. No necesita ser muy poderoso, solo necesita hacer frente a la carga de escritura de su base de datos maestra. No debe usar este servidor en producción. Si la replicación nunca continúa, necesita un servidor más potente. Puede verificar comparando el archivo de registro y la posición de la salida de
> SHOW MASTER STATUS\G
en el maestro y
> SHOW SLAVE STATUS\G
en el esclavo Creo que MySQL5 mostrará el retraso de SHOW SLAVE STATUS
.
Cuando estés contento de que tu esclavo esté al día, puedes hacer copias de seguridad haciendo
SLAVE STOP;
el esclavomysqldump --opt
en el servidor esclavo.SLAVE START;
el esclavoSi hace esto, tendrá una copia de seguridad consistente de sus bases de datos. Este método evita que diferentes bases de datos o, peor aún, que diferentes tablas de la misma base de datos no estén sincronizadas y evita el tiempo de inactividad al bloquear las tablas para las escrituras mientras realiza la copia de seguridad.
Un buen beneficio de esta configuración es que tiene una copia de su base de datos que puede usar para ejecutar consultas largas y costosas que no afectarán su servicio en vivo.
Par de consejos al azar:
mysqldump --opt
, ya que suele ser la forma más rápida de importar el SQL resultanteYo uso un script que usa mysqldump
para extraer los datos / esquema a un archivo para cada base de datos. Los datos están respaldados por la copia de seguridad de copia de seguridad normal en cinta. Obviamente, puede agregar más campanas y silbatos, pero esto hace un volcado básico simple.
#!/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
Por lo general, las bases de datos se respaldan una vez al día si tienen que detenerse, y luego las copias de seguridad se transfieren a un área de almacenamiento para su consolidación y luego van a cinta.
Las copias de seguridad de la base de datos se realizan con las herramientas nativas proporcionadas con el motor de la base de datos la mayor parte del tiempo.
Las copias de seguridad no se guardarán en los servidores con los datos en caso de falla del hardware.
Es bastante recomendable tener réplicas actualizadas de sus servidores de bases de datos cuando sea posible, mejor tener un macanismo de conmutación por error para las bases de datos de producción.
Para el software puede, por ejemplo, echar un vistazo a Bacula o Zmanda
Nuestra configuración estándar es un clúster HA con dos bases de datos, una replicando a la otra, que es de solo lectura.
Hacemos una copia de seguridad completa una vez al día y luego tenemos una política por cliente de eliminar las copias de seguridad antiguas, generalmente guardamos 4 últimas copias de seguridad diarias (para sobrevivir al fin de semana;), 4 últimos domingos y 4 últimos primeros domingos en un mes. Después de eso, uno o dos basureros al año irán al archivo para mantenerse para siempre.
También conservamos los registros de replicación por el tiempo que podamos ahorrar espacio en el disco. También son bastante útiles como herramienta de depuración, ya que registran exactamente quién cambió qué y cuándo.
Teóricamente, todo lo que necesita es una copia de seguridad completa y todos los registros de replicación para poder restaurar un punto en el tiempo, pero las copias de seguridad completas más frecuentes acelerarán la restauración.
Un buen truco con la copia de seguridad es usar tablas innodb y - parámetro de transacción única para el volcado de mysql, de esa manera la copia de seguridad no bloqueará la base de datos mientras se ejecuta.
Estoy usando el Xtrabackup de Percona . Es una solución de respaldo no bloqueable para InnoDB / XtraDB
Todo el propósito de la copia de seguridad es poder restaurar.
No recomendaría un volcado CSV como una solución de respaldo; todo lo que le dará son los datos en bruto. Además de eso, hay mucho más, particularmente con una base de datos. Descripciones de tablas, vistas, procesos almacenados, lo que sea. Si no los tiene también, no podrá recuperarlos con éxito. También hay que considerar la aplicación RDBMS y la configuración. Es posible que tenga una gran cantidad de parches, que también necesitará poner en su entorno de recuperación para llevarlo al mismo nivel. Es posible que esté ejecutando alguna configuración especial dictada por los requisitos de sus aplicaciones. Incluso puede tener un conjunto específico de configuraciones del sistema operativo necesarias para que su base de datos se ejecute de manera óptima. También será necesario recuperar todo esto y, a menos que tenga una solución de respaldo que sea capaz de hacerlos, habrá más demoras en su tiempo de recuperación,
Para las copias de seguridad de bases de datos (y las copias de seguridad en general) siempre preferiría usar un software de copia de seguridad "real" que pueda manejar todo esto.
Más recientemente, he administrado servidores MySQL en EC2. Configuramos instantáneas de EBS en un trabajo cron de 15 minutos, se guardaron 3-5 instantáneas.
Cuando hicimos servidores MySQL 'tradicionales', realizamos copias de seguridad diariamente a través de MySQl-ZRM. Las copias de seguridad son esencialmente mysqldumps, que se envían a cinta, SAN, etc., según las necesidades del cliente.
Ambos métodos se pueden hacer sin detener la base de datos.
Para MySQL utilizo automysqlbackup ( http://sourceforge.net/projects/automysqlbackup/ ), ya que mi software de respaldo (Backup Exec) no admite instantáneas en sistemas Linux.
Funciona bien, pero voy a monitorear este hilo para sugerencias :)
Hacemos copias de seguridad dos veces al día y también ejecutamos copias de seguridad de registros cada 10-15 minutos.
La ventaja de este método es que puede restaurar desde una de las copias de seguridad dos veces al día y luego aplicar los archivos de registro hasta los últimos 15 minutos como máximo. De esta forma, minimiza la cantidad de datos que puede perder.
Sin embargo, la frecuencia con la que realice una copia de seguridad de sus datos depende de usted. ¿Cuántos datos te sientes cómodo con perder? Si puede permitirse perder un día de datos, haga una copia de seguridad una vez al día. Los datos nunca cambian? ¡Entonces solo necesitas una copia!