it-swarm-es.com

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 desconectar el servidor web Y la copia de seguridad tarda unos 5 minutos. Si no desactivo el servidor web, tarda una eternidad y nunca termina + el sitio web se vuelve inaccesible durante la copia de seguridad.

¿Existe una manera mejor o más rápida de hacer una copia de seguridad de mis 22 GB y mi base de datos en crecimiento?

Todas las tablas son MyISAM.

28
unknown (yahoo)

Si.

Configure 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 su maestro y nunca tendrá que desconectarlo.

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

También es teóricamente posible restaurar una base de datos usando un estado conocido y binlogs. Nunca lo he hecho, así que investigue primero, pero podría hacer una copia de seguridad de un estado conocido de su base de datos, luego hacer una copia de seguridad de todos los nuevos registros de binlog y reproducirlos si alguna vez necesita restaurarlos. Dado que los binlogs se escriben linealmente, sincronizar nuevos binlogs a una computadora remota sería muy rápido.

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

Esta pregunta está muy relacionada

28
John Douthat

Disculpe por asumir que el sistema operativo es Linux. Si no está utilizando LVM, debería hacerlo. Si es así, aquí hay una forma muy sencilla 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 todas las noches 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.

5
Bruno Bronosky

FLUSH TABLES WITH READ LOCK no es algo que desee hacer de forma regular (o incluso semi-regular) en un sistema de producción. Debería ser solo un último recurso.

Configure al menos dos esclavos de replicación (esto requerirá un FLUSH TABLES WITH READ LOCK, por supuesto). Una vez que estén configurados, puede realizar una copia de seguridad de uno mientras el otro permanece sincronizado como maestro de repuesto.

Además, si uno de sus esclavos falla, puede usar una instantánea de ese para reconstruir un segundo (o tercer) esclavo. Si todos tus esclavos fallan, volverás a DESCARGAR MESAS CON BLOQUEO DE LECTURA.

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 de configurar, consulte la documentación de Maatkit para obtener más detalles).

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

2
MarkR

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

  1. Configure la replicación de su servidor a un esclavo que puede desconectar. La mejor manera de hacer esto es hacer un volcado de la base de datos usando mysqldump y el parámetro --master-data.
  2. Configure copias de seguridad nocturnas en el esclavo. Puede usar mysqldump con los indicadores --master-data --flush-logs y --single-transaction, o puede detener el servidor mysql, copiar los archivos de datos en el disco y reiniciarlo (la replicación continuará donde se detuvo).
  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 python script para hacerlo, que puedes usar.

Tenga en cuenta que si está usando InnoDB para sus tablas, puede usar la marca --single-transaction para evitar tener que hacer bloqueos de tabla y aún obtener un volcado consistente 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 'vacía tablas 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 tome demasiado tiempo, puede agregar una tercera máquina y ejecutar mysqldump en ella a través de la red para evitar dañar sus discos.

1
Dan Udey

Podría hacer una copia de seguridad gradual. Copia de seguridad de 1/24 de los registros cada hora. El único problema con este enfoque es que si falla durante las primeras horas del día, perderá cualquier cosa desde ese momento hasta el momento del accidente. De cualquier manera, son menos de 24 horas de registros perdidos (no sé qué tan importante es eso para ti).

0
musicfreak

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 maestro y esclavo, y usamos copias de seguridad instantáneas en ambos.

  1. FLUSH TABLES WITH READ LOCK;
  2. Extraiga una instantánea de la base de datos y los sistemas de archivos de registro.
  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.

0
jasonjwwilliams

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

0
Charles Faiga