Copia de seguridad diaria de una base de datos MySQL de 22 GB

Ahora mismo puedo hacer la copia de seguridad usando mysqldump. Pero tengo que eliminar el servidor web Y me toma alrededor de 5 minutos hacer la copia de seguridad. Si no elimino el servidor web, me lleva una eternidad y nunca termina + el sitio web se vuelve inaccesible durante la copia de seguridad.

¿Existe una forma más rápida / mejor de hacer una copia de seguridad de mis 22 GB y mi creciente base de datos?

Todas las tablas son MyISAM.

Sí.

Configurar la replicación en una segunda máquina. Cuando necesite hacer una copia de seguridad, puede bloquear la máquina secundaria, realizar mysqlhotcopy o mysqldump y luego desbloquearla. Se pondrá al día con tu maestro, y nunca tendrás que desconectarlo.

Incluso podría hacer esto en la misma máquina, si no le importa duplicar la E / S de escritura, pero idealmente debería hacer una copia de seguridad en tiempo real en un segundo servidor físico, y tomar sus copias de seguridad de instantáneas con la frecuencia que necesite sin molestar a su servidor de producción.

También es teóricamente posible restaurar una base de datos utilizando un estado conocido y binlogs. Nunca lo he hecho, así que por favor investigue primero, pero podría hacer una copia de seguridad de un estado conocido de su base de datos, luego simplemente haga una copia de seguridad de todos los nuevos binlogs y reprodúzcalos si alguna vez necesita restaurar. Dado que los binlogs se escriben linealmente, la sincronización de nuevos binlogs a una computadora remota sería muy rápida.

Editar: de hecho, parece que el uso de binlogs para la copia de seguridad está documentado.

Esta pregunta está altamente relacionada

Disculpe por suponer que el sistema operativo es Linux. Si no está utilizando LVM, debería estarlo. Si es así, aquí hay una manera muy simple de hacer copias de seguridad a través de una instantánea.

# Define these vars to meet your needs. These meet mine.
lvol="/dev/VolGroup03/lvol0"
snap_name="nightly_snapshot"
snap_vol="$(dirname $lvol)/$snap_name"
snap_path="/mnt/$snap_name"
snap_size="10g" # Not the size of your data, anticipated data changes during the backup
backup_path="/backups/$snap_name"

/usr/bin/time -f 'Databases were locked for %E' -- \
mysql <<- MYSQL
# based on http://pointyhair.com/tiki-view_blog_post.php?blogId=1&postId=5
FLUSH TABLES WITH READ LOCK;
\! lvcreate --size $snap_size --snapshot --name $snap_name $lvol
UNLOCK TABLES;
MYSQL
mount $snap_vol $snap_path
rsync -av --delete $snap_path/mysql $backup_path/
umount $snap_path
lvremove -f $snap_vol

Esto le permitirá realizar copias de seguridad nocturnas sin tener que agregar un servidor esclavo. Estoy muy a favor de tener un servidor esclavo para alta disponibilidad, pero no quiero que pienses que estás atascado hasta que puedas crear ese esclavo.

LAVAR TABLAS CON READ LOCK no es algo que desee hacer de forma regular (o incluso semi-regular) en un sistema de producción. Debería ser un último recurso solamente.

Configure al menos dos esclavos de replicación (esto requerirá TABLAS DE DESCARGA CON BLOQUEO DE LECTURA, por supuesto). Una vez que están configurados, puede quitar una copia de seguridad de uno mientras el otro permanece sincronizado como maestro de reserva.

Además, si uno de tus esclavos falla, puedes usar una instantánea de eso para reconstruir un segundo (o tercer) esclavo. Si todos tus esclavos fallan, volverás a ENJUAGAR TABLAS CON LECTURA BLOQUEADA.

Recuerde tener siempre un proceso que verifique regularmente que los datos estén sincronizados: use algo como mk-table-checksum para hacer esto (esto no es trivial para configurar, consulte la documentación de Maatkit para más detalles).

Como 22 GB es relativamente pequeño, no tendrá problemas para hacerlo. Hacerlo con una base de datos grande podría ser más problemático.

La solución aquí es doble, como se describió anteriormente:

1. Configure la replicación de su servidor en un esclavo que puede desconectar. La mejor manera de hacerlo es volcar la base de datos utilizando mysqldump y el parámetro --master-data.
2. Configurar copias de seguridad nocturnas en el esclavo. Puede usar mysqldump con --master-data --flush-logs y --single-transacción flags, o puede detener el servidor mysql, copiar los archivos de datos en el disco y reiniciarlo (la replicación comenzará donde se quedó).
3. Ejecute un script en el esclavo cada (por ejemplo, 5, 10, 20 minutos) para verificar y asegurarse de que mysql todavía se esté replicando. Escribí un simple script de Python para hacerlo, que puedes usar.

Tenga en cuenta que si está usando InnoDB para sus tablas, puede usar el indicador --single-transacción para evitar tener que bloquear cualquier tabla y aún así obtener un volcado constante de la base de datos, incluso en el maestro, y así hacer sus copias de seguridad sin derribando el servidor. La solución anterior, sin embargo, es mejor.

Además, si está utilizando LVM en Linux, puede tomar una instantánea LVM de la partición y luego hacer una copia de seguridad. Las instantáneas de LVM son atómicas, por lo que si hace 'tablas al ras con bloqueo de lectura' y luego toma su instantánea y desbloquea, obtendrá una instantánea consistente.

Si le preocupa que la contención de E / S haga que el volcado demore demasiado, puede agregar una tercera máquina y ejecutar mysqldump en esa red para evitar agotar sus discos.

Dependiendo de su entorno, las instantáneas suelen ser una excelente manera de hacerlo. Particularmente si tiene que hacer una copia de seguridad del maestro por alguna razón. Ejecutamos pares de maestros y esclavos, y utilizamos copias de seguridad de instantáneas en ambos.

1. FLUSH TABLES WITH READ LOCK;
2. Obtenga una instantánea de la base de datos y registre los sistemas de archivos.
3. UNLOCK TABLES;
4. Copie sus archivos de datos de la instantánea a su gusto.

Con las tablas InnoDB, querrá ejecutar SET AUTOCOMMIT=0;antes de ejecutar el bloqueo de lectura.

Eche un vistazo a " Mejores prácticas para hacer una copia de seguridad de una base de datos MySQL de producción ". Es una publicación similar en Stack Overflow.

Podrías hacer una copia de seguridad gradual. Copia de seguridad 1/24 de los registros cada hora. El único problema con este enfoque es que si se bloquea durante las primeras horas del día, perderá algo desde ese momento hasta el momento del accidente. De cualquier manera, se pierden menos de 24 horas de registros (no sé lo importante que es para usted).