Hacer copias de seguridad incrementales es un requisito importante para las bases de datos de gran producción. Sin una copia de seguridad incremental segura, no puede decirse a sí mismo que tiene una base de datos de producción confiable. Porque debe tener suficientes datos para recuperar su base de datos en casos de emergencia. Después de algunas búsquedas en Internet, no pude encontrar ninguna herramienta que pueda hacer una copia de seguridad incremental completa para MyISAM e InnodB en un entorno mixto donde las aplicaciones usan ambos motores de base de datos simultáneamente (tal vez no soy un experto en búsquedas en Google e Internet). Así que decidí escribir este, pero para evitar perder el tiempo y beneficiarme de otras soluciones de código abierto, preferí agregar esta característica a -automysqlbackup-script, que es el mejor script para copias de seguridad completas con simplicidad y uso generalizado.
Mecanismo
Usamos la función Post y Pre de automysqlbackup para hacer una copia de seguridad incremental. Antes de iniciar una copia de seguridad completa, mysql-backup-pre ejecuta una consulta para bloquear toda la base de datos durante el proceso de copia de seguridad porque tenemos que congelar el binlog para evitar cualquier cambio mientras se ejecuta la copia de seguridad. Es posible que el nombre y la posición del binlog no cambien durante la copia de seguridad. La posición del registro binario es muy importante en el proceso de copia de seguridad incremental posterior y se utilizará como punto de partida para comenzar la siguiente copia de seguridad incremental. Después de finalizar la copia de seguridad completa, mysql-backup-post elimina el bloqueo de la base de datos.
Consulta de bloqueo:FLUSH TABLAS CON BLOQUEO DE LECTURA; SELECCIONE DORMIR(86400)
Buscar consultas de bloqueo:mysql -u [nombre de usuario] -p [contraseña] -e "mostrar lista de procesos" | grep "SELECCIONAR DORMIR (86400)" | awk '{imprimir $1}'
Requisitos
- privilegios de root para instalar el paquete y actualizar mysql.conf
- paquete mysql-community-client
- instalación automysqlbackup y mysql-incremental
Instalación
Instale el paquete mysql-community-client para su distribución.
Nota:después de la instalación de MySQL debe tener el comando 'mysqlshow'.
Instalar automysqlbackup:
download the package from https://sourceforge.net/projects/automysqlbackup/
tar -xzf [PathYouSavedTarFile] -C /tmp/
cd /tmp/
./install.sh
Durante la instalación de automysqlbackup, se le preguntará sobre la ruta de automysqlbackup.conf y su binario, puede dejar los valores predeterminados sin ningún cambio.
rm /etc/automysqlbackup/myserver.conf
Instale mysql-incremental:descargue el paquete desde https://sourceforge.net/projects/mysqlincrementalbackup/
cd /tmp
wget http://downloads.sourceforge.net/project/mysqlincrementalbackup/mysql-incremental.tar.gz
tar xfz mysql-incremental.tar.gz
cp mysql-incremental /etc/automysqlbackup/
chmod 755 /etc/automysqlbackup/mysql-incremental
cp mysql-backup-post /etc/automysqlbackup/
chmod 755 /etc/automysqlbackup/mysql-backup-post
cp mysql-backup-pre /etc/automysqlbackup/
chmod 755 /etc/automysqlbackup/mysql-backup-pre
Actualice automysqlbackup.conf:
Encuentre los siguientes parámetros, elimine los comentarios y cámbielos:
CONFIG_mysql_dump_username='Mysql user name. It must has privileges to get Lock'
CONFIG_mysql_dump_password='Password'
CONFIG_backup_dir='The backup directory you want to store full and incremental backup'
CONFIG_db_names=('databaseName1' 'databaseName2' )
CONFIG_db_month_names=('databaseName1' 'databaseName2' )
CONFIG_mysql_dump_master_data=2
CONFIG_prebackup="/etc/automysqlbackup/mysql-backup-pre"
CONFIG_postbackup="/etc/automysqlbackup/mysql-backup-post"
Actualizar mi.cnf:
Edite el archivo de configuración de MySQL:
nano /etc/mysql/my.cnf
1- Formato BinLog
Debido a alguna limitación en el formato DECLARACIÓN, mi recomendación es configurar el formato basado en ROW. Para obtener más información, consulte la sección 'solución de problemas' en este instructivo. Puede verificar el tipo de formato de registro binario ejecutando "select @@binlog_format;" consulta. Para modificar el formato logbin, debe agregar binlog_format =ROW a mysql.conf o my.cnf.
2- binlog_do_db
Debe especificar las bases de datos que desea que tengan los cambios relacionados en el registro binario. Tenga en cuenta que si no especifica ninguna base de datos, cualquier cambio en cualquier base de datos se registrará en el registro binario. En este caso, si elige el formato DECLARACIÓN, tal vez tenga algunos problemas al restaurar desde copias de seguridad incrementales y archivos binlog. Puede agregar bases de datos a esta opción:
binlog_do_db = DATABASENAME1 binlog_do_db = DATABASENAME2
3- expire_logs_days
Para tener archivos de registro binarios durante más tiempo, puede aumentar este parámetro a un valor más alto. Mi recomendación es de 60 días. Por lo tanto, debe agregarlo o cambiarlo a "expire_logs_days =60".
4- bin de registro
El directorio donde se almacenarán los registros binarios. En versiones anteriores de MySQL, es posible que mysql-incremenetal no pueda encontrar la ruta correcta. Entonces, si obtiene un error al respecto después de ejecutar mysql-incremental, debe actualizar el script mysql-incremental y establecer la ruta de registro binario.
5-log_slave_updates
Si está configurando una copia de seguridad incremental de mysql en un servidor esclavo, debe habilitar esta opción. Normalmente, un esclavo no registra actualizaciones en su propio registro binario, ya que se recibieron de un servidor maestro. Esta opción le dice al esclavo que registre las actualizaciones realizadas por sus subprocesos SQL en su propio registro binario. http://dev.mysql.com/doc/refman/5.1/en/replication-options-slave.html#option_mysqld_log-slave-updates
Ejecutar automysqlbackup
Ejecute automysqlbackup manualmente para tener al menos una copia de seguridad completa de las bases de datos especificadas.
automysqlbackup
Después de ejecutar el comando con éxito, verifique el archivo /[BackupDirInAutomysqlbackup]/status/backup_info para ver la información recién agregada sobre la copia de seguridad diaria. Para obtener detalles del error, consulte /var/log/Backup_Post_Pre_log . El archivo de copia de seguridad se almacenará en el directorio /[BackupDirInAutomysqlbackup]/daily/[DatabaseName]/ .
Ejecutar mysql-incremental
Ejecute mysql-incremental manualmente ahora para tener al menos una copia de seguridad cada hora.
mysql-incremental
En caso de error, los detalles se registran en el archivo "/var/log/Backup_Incremental_Log" . Los archivos de copia de seguridad incremental se almacenarán en el directorio /[BackupDirInAutomysqlbackup]/IncrementalBackup/ .
Editar el crontab raíz
Puede programar mysql-incremental durante más de una hora. Puede encontrar el tiempo total de la copia de seguridad completa de backup_status y luego, en función de ese valor, establecer un horario de programación preciso. Por supuesto, la copia de seguridad incremental de mysql tiene un mecanismo para encontrar cualquier copia de seguridad completa en ejecución antes de comenzar, por lo que no hay preocupación por el conflicto entre la copia de seguridad incremental y la completa.
crontab -e
5 00 * * * root /usr/local/bin/automysqlbackup 25 * * * * root /etc/automysqlbackup/mysql-incremental
Restaurar base de datos
Para restaurar hasta un momento específico (recuperación de un punto en el tiempo), primero debe restaurar una copia de seguridad diaria completa y luego restaurar los archivos de copia de seguridad incrementales relacionados secuencialmente. Para aclarar más, aquí están los pasos para recuperar la base de datos testDB. En el escenario de muestra, tenemos la intención de recuperar nuestros datos hasta el 2015-5-01 a las 2 a.m. hemos configurado /backup como nuestro directorio de respaldo principal y testDB como nuestra base de datos de destino:
1- mysql -u root -p DatabaseName < /backup/daily/testDB/daily_DatabaseName_2015-05-16_00h05m_Saturday.sql.gz 2- mysql -u root -p DatabaseNAme < /backup/IncrementalBackup/2015-5-01_Incremental/testDB/testDB_IncrementalBackup_2015-5-01_00h25m.1 3- mysql -u root -p DatabaseNAme < /backup/IncrementalBackup/2015-5-01_Incremental/testDB/testDB_IncrementalBackup_2015-5-01_01h25m.2 4- mysql -u root -p DatabaseNAme < /backup/IncrementalBackup/2015-5-01_Incremental/testDB/testDB_IncrementalBackup_2015-5-01_02h25m.3
Notas importantes y solución de problemas
MySQL admite diferentes formatos para el registro binario. Algunas versiones de Mysql usan 'basado en sentencias' como formato de registro binario que este tipo de registro binario tiene algunas limitaciones a las que debemos prestar mucha atención cuando intentamos usarlo en el procedimiento de copia de seguridad incremental. Cuando mysql está configurado en formato de base de declaración, no puede filtrar correctamente en función de las bases de datos. Si configura 'USE o \u' para cambiar la base de datos y luego actualiza otra base de datos que no está incluida en binlog-do-db, la declaración se registrará en el archivo binlog de que no es un estado deseable. y expondrá algunos problemas al restaurar en función de una base de datos específica y también si cambia a otra base de datos que no está incluida en binlog-do-db y actualiza una base de datos que está incluida en binlog-do-db, la declaración no se registrará en archivo binlog. nuestro propósito al agregar bases de datos a binlog-do-db es filtrar según la base de datos, pero no funciona como se esperaba. Si no se ejecuta USE o \u antes de ejecutar consultas, mysqlbinlog no puede extraer 'consultas de actualización' relacionadas con una base de datos. Explicaremos más este problema con los siguientes escenarios:
databases:
- binlog
- person (table)
- binlog2
- person (table)
binlog-do-db=binlog2 (it is supposed only change of this database are logged to binlog file)
--------Scenario 1---------
\u binlog2
insert into person (data) values ('17') ---> loged in binlog *desired state*
insert into binlog.person (data) values ('25'); ---> logged in binlog (target database is 'binlog' ) *undesired state*
--------Scenario 2---------
\u binlog
insert into person (data) values ('17') ---> is not logged in binlog *desired state*
insert into binlog2.person (data) values ('25'); ---> is not logged in binlog (target database is 'binlog2' ) *undesired state* because the binlog2 database
is begin changed, so we want to have this change,but it will not logged in logbin file
--------Scenario 3---------
if you just connect to database without any USE or \u statement, all of updates on any databases will be logged, but mysqlbinlog can not able to filter
based on specific database, so that is not desirable state for our purpose in incremental backup. Using USE or \u before executing update queries, is very
important. Because mysqlbinlog finds update queries based on USE statement in binlog file. Solucionar el problema mencionado
1) Al definir usuarios en las bases de datos de manera que cada usuario solo tenga acceso a una base de datos para actualizar (usuario de la aplicación) y cuando se conecte a la base de datos, se debe especificar el nombre de la base de datos. Por supuesto, la mayoría de las aplicaciones tienen un archivo de configuración en el que se establecen las credenciales y el nombre de la base de datos, por lo que en ese caso no tendrá un acceso cruzado a las bases de datos y no habrá preocupaciones sobre el uso de "\USE o \u ".
2) Si usa el formato binlog basado en filas, todos los problemas mencionados desaparecerán. en otras palabras, el formato basado en filas es un método mucho más adecuado para binlog. https://dev.mysql.com/doc/refman/5.1/en/replication-options-binary-log.html
Archivos de registro
Intenté registrar todo en un archivo de registro para que pueda encontrar suficiente información en los registros:
/var/log/Backup_Post_Pre_log
/var/log/Backup_Incremental_Log
/[SpecifiedBackupDirInAutomysqlbackup.conf]/status/backup_info
El archivo "backup_info" contiene información detallada sobre la copia de seguridad y cuándo finalizó la copia de seguridad (los tiempos están en formato Unix Time). Contiene el nombre del binlog y la posición del momento en que se inició la copia de seguridad, el tipo de copia de seguridad, la cantidad de copias de seguridad desde la última copia de seguridad completa y la duración de la copia de seguridad.
Ejemplo de copia de seguridad_info:
1431043501,mysql-bin.000026,120,Daily,2015-05-08,0,24 1431044701,mysql-bin.000026,120,Hourly,2015-05-08,1,1
Aquí hay una descripción de los diferentes valores:
1th) 1431043501 : indicates the time when the backup has been finished. You can run date --date @1431043501 command on the server the backup has been done to view it in human readable format. 2th) Mysql-bin.000026 : indicates the binary log name that backup up to this file has been done. 3th) 120 : indicates the position of binlog that backup up to this position in binary log has been done. 4th) Daily/Hourly: indicates type of backup. Daily does mean the full backup by automysqlbackup script and Hourly is done by mysql-incremental script. 5th) 2015-05-08: The date that backup has been done. This date will be used in creating directory for incremental backup and also as a base for restore hourly backups. In restoring procedure, first a full backup is restored and then sequentially other incremental backup are restored. 6th) 0 : indicates number of backups from previous full backup. 0 does mean the backup is full and others mean hourly. This number is very important in restoring procedure. 7th) 24: The backup duration in second.
Informe de error
Puede informar errores o dar sus sugerencias y revisiones en https://sourceforge.net/projects/mysqlincrementalbackup .