En mi publicación anterior, expliqué cómo realizar una copia de seguridad lógica utilizando las utilidades de mysql shell. En esta publicación, compararemos la velocidad del proceso de copia de seguridad y restauración.
Prueba de velocidad de MySQL Shell
Vamos a hacer una comparación de la velocidad de copia de seguridad y recuperación de las herramientas de utilidad mysqldump y MySQL shell.
Las siguientes herramientas se utilizan para comparar la velocidad:
- mysqldump
- util.dumpInstance
- util.loadDump
Configuración de hardware
Dos servidores independientes con configuraciones idénticas.
Servidor 1
* IP:192.168.33.14
* CPU:2 núcleos
* RAM:4 GB
* DISCO:SSD de 200 GB
Servidor 2
* IP:192.168.33.15
* CPU:2 núcleos
* RAM:4 GB
* DISCO:SSD de 200 GB
Preparación de la carga de trabajo
En el Servidor 1 (192.168.33.14), hemos cargado aproximadamente 10 GB de datos.
Ahora, queremos restaurar los datos del Servidor 1 (192.168.33.14) al Servidor 2 (192.168.33.15).
Configuración de MySQL
Versión MySQL:8.0.22
Tamaño del grupo de búfer InnoDB:1 GB
Tamaño del archivo de registro de InnoDB:16 MB
Registro binario:activado
Cargamos 50 millones de registros usando sysbench.
[[email protected] sysbench]# sysbench oltp_insert.lua --table-size=5000000 --num-threads=8 --rand-type=uniform --db-driver=mysql --mysql-db=sbtest --tables=10 --mysql-user=root --mysql-password=****** prepare
WARNING: --num-threads is deprecated, use --threads instead
sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2)
Initializing worker threads...
Creating table 'sbtest3'...
Creating table 'sbtest4'...
Creating table 'sbtest7'...
Creating table 'sbtest1'...
Creating table 'sbtest2'...
Creating table 'sbtest8'...
Creating table 'sbtest5'...
Creating table 'sbtest6'...
Inserting 5000000 records into 'sbtest1'
Inserting 5000000 records into 'sbtest3'
Inserting 5000000 records into 'sbtest7
.
.
.
Creating a secondary index on 'sbtest9'...
Creating a secondary index on 'sbtest10'...Caso de prueba uno
En este caso, vamos a realizar una copia de seguridad lógica mediante el comando mysqldump.
Ejemplo
[[email protected] vagrant]# time /usr/bin/mysqldump --defaults-file=/etc/my.cnf --flush-privileges --hex-blob --opt --master-data=2 --single-transaction --triggers --routines --events --set-gtid-purged=OFF --all-databases |gzip -6 -c > /home/vagrant/test/mysqldump_schemaanddata.sql.gzhora_inicio =2020-11-09 17:40:02
hora_finalización =2020-11-09 37:19:08
Tomó casi 20 minutos y 19 segundos realizar un volcado de todas las bases de datos con un tamaño total de alrededor de 10 GB.
Caso de prueba dos
Ahora intentemos con la utilidad de shell MySQL. Vamos a utilizar dumpInstance para realizar una copia de seguridad completa.
Ejemplo
MySQL localhost:33060+ ssl JS > util.dumpInstance("/home/vagrant/production_backup", {threads: 2, ocimds: true,compatibility: ["strip_restricted_grants"]})
Acquiring global read lock
Global read lock acquired
All transactions have been started
Locking instance for backup
Global read lock has been released
Checking for compatibility with MySQL Database Service 8.0.22
NOTE: Progress information uses estimated values and may not be accurate.
Data dump for table `sbtest`.`sbtest1` will be written to 38 files
Data dump for table `sbtest`.`sbtest10` will be written to 38 files
Data dump for table `sbtest`.`sbtest3` will be written to 38 files
Data dump for table `sbtest`.`sbtest2` will be written to 38 files
Data dump for table `sbtest`.`sbtest4` will be written to 38 files
Data dump for table `sbtest`.`sbtest5` will be written to 38 files
Data dump for table `sbtest`.`sbtest6` will be written to 38 files
Data dump for table `sbtest`.`sbtest7` will be written to 38 files
Data dump for table `sbtest`.`sbtest8` will be written to 38 files
Data dump for table `sbtest`.`sbtest9` will be written to 38 files
2 thds dumping - 36% (17.74M rows / ~48.14M rows), 570.93K rows/s, 111.78 MB/s uncompressed, 50.32 MB/s compressed
1 thds dumping - 100% (50.00M rows / ~48.14M rows), 587.61K rows/s, 115.04 MB/s uncompressed, 51.79 MB/s compressed
Duration: 00:01:27s
Schemas dumped: 3
Tables dumped: 10
Uncompressed data size: 9.78 GB
Compressed data size: 4.41 GB
Compression ratio: 2.2
Rows written: 50000000
Bytes written: 4.41 GB
Average uncompressed throughput: 111.86 MB/s
Average compressed throughput: 50.44 MB/s Tomó un total de 1 minuto y 27 segundos realizar un volcado de toda la base de datos (los mismos datos que se usaron para mysqldump) y también muestra su progreso, lo que será realmente útil para saber cuánto de la copia de seguridad se ha completado. Indica el tiempo que se tardó en realizar la copia de seguridad.
El paralelismo depende de la cantidad de núcleos en el servidor. Aumentar aproximadamente el valor no será útil en mi caso. (Mi máquina tiene 2 núcleos).
Prueba de velocidad de restauración
En la parte de restauración, restauraremos la copia de seguridad de mysqldump en otro servidor independiente. El archivo de copia de seguridad ya se movió al servidor de destino usando rsync.
Caso de prueba 1
Ejemplo
[[email protected] vagrant]#time gunzip < /mnt/mysqldump_schemaanddata.sql.gz | mysql -u root -pTomó alrededor de 16 minutos y 26 segundos restaurar los 10 GB de datos.
Caso de prueba 2
En este caso, estamos utilizando la utilidad mysql shell para cargar el archivo de copia de seguridad en otro host independiente. Ya movimos el archivo de copia de seguridad al servidor de destino. Empecemos el proceso de restauración.
Ejemplo
MySQL localhost:33060+ ssl JS > util.loadDump("/home/vagrant/production_backup", {progressFile :"/home/vagrant/production_backup/log.json",threads :2})
Opening dump...
Target is MySQL 8.0.22. Dump was produced from MySQL 8.0.22
Checking for pre-existing objects...
Executing common preamble SQL
Executing DDL script for schema `cluster_control`
Executing DDL script for schema `proxydemo`
Executing DDL script for schema `sbtest`
.
.
.
2 thds loading \ 1% (150.66 MB / 9.78 GB), 6.74 MB/s, 4 / 10 tables done
2 thds loading / 100% (9.79 GB / 9.79 GB), 1.29 MB/s, 10 / 10 tables done
[Worker001] [email protected]@@37.tsv.zst: Records: 131614 Deleted: 0 Skipped: 0 Warnings: 0
[Worker002] [email protected]@@37.tsv.zst: Records: 131614 Deleted: 0 Skipped: 0 Warnings: 0
Executing common postamble SQL
380 chunks (50.00M rows, 9.79 GB) for 10 tables in 2 schemas were loaded in 40 min 6 sec (avg throughput 4.06 MB/s)Tomó alrededor de 40 minutos y 6 segundos restaurar los 10 GB de datos.
Ahora intentemos deshabilitar el registro de rehacer e iniciar la importación de datos usando mysql utilidad de shell.
mysql> alter instance disable innodb redo_log;
Query OK, 0 rows affected (0.00 sec)
MySQL localhost:33060+ ssl JS >util.loadDump("/home/vagrant/production_backup", {progressFile :"/home/vagrant/production_backup/log.json",threads :2})
Opening dump...
Target is MySQL 8.0.22. Dump was produced from MySQL 8.0.22
Checking for pre-existing objects...
Executing common preamble SQL
.
.
.
380 chunks (50.00M rows, 9.79 GB) for 10 tables in 3 schemas were loaded in 19 min 56 sec (avg throughput 8.19 MB/s)
0 warnings were reported during the load.Después de deshabilitar el registro de rehacer, el rendimiento promedio aumentó hasta 2 veces.
Nota:No deshabilite el inicio de sesión de rehacer en un sistema de producción. Permite apagar y reiniciar el servidor mientras el registro de rehacer está deshabilitado, pero una parada inesperada del servidor mientras el registro de rehacer está deshabilitado puede provocar la pérdida de datos y la corrupción de la instancia.
Copias de seguridad físicas
Como habrá notado, los métodos lógicos de copia de seguridad, incluso si son de subprocesos múltiples, consumen bastante tiempo, incluso para un pequeño conjunto de datos con el que los probamos. Esta es una de las razones por las que ClusterControl proporciona un método de copia de seguridad física que se basa en la copia de los archivos; en tal caso, no estamos limitados por la capa de SQL que procesa la copia de seguridad lógica, sino por el hardware:qué tan rápido el disco puede leer los archivos y qué tan rápido la red puede transferir datos entre el nodo de la base de datos y el servidor de respaldo.
ClusterControl viene con diferentes formas de implementar copias de seguridad físicas, el método que esté disponible dependerá del tipo de clúster y, a veces, incluso del proveedor. Echemos un vistazo al Xtrabackup ejecutado por ClusterControl que creará una copia de seguridad completa de los datos en nuestro entorno de prueba.
Esta vez vamos a crear una copia de seguridad ad-hoc pero ClusterControl permite también crea un programa completo de copia de seguridad.
Aquí elegimos el método de copia de seguridad (xtrabackup) así como el host que van a tomar la copia de seguridad de. También podemos almacenarlo localmente en el nodo o transmitirlo a una instancia de ClusterControl. Además, puede cargar la copia de seguridad en la nube (se admiten AWS, Google Cloud y Azure).
La copia de seguridad tardó unos 10 minutos en completarse. Aquí los registros del archivo cmon_backup.metadata.
[[email protected] BACKUP-9]# cat cmon_backup.metadata
{
"class_name": "CmonBackupRecord",
"backup_host": "192.168.33.14",
"backup_tool_version": "2.4.21",
"compressed": true,
"created": "2020-11-17T23:37:15.000Z",
"created_by": "",
"db_vendor": "oracle",
"description": "",
"encrypted": false,
"encryption_md5": "",
"finished": "2020-11-17T23:47:47.681Z"
}Ahora intentemos lo mismo para restaurar usando ClusterControl. ClusterControl> Copia de seguridad> Restaurar copia de seguridad
Aquí elegimos la opción de restauración de copia de seguridad, admitirá tiempo y registro recuperación también.
Aquí elegimos la ruta de origen del archivo de respaldo y luego el servidor de destino. También debe asegurarse de que se pueda acceder a este host desde el nodo ClusterControl mediante SSH.
No queremos que ClusterControl configure el software, así que deshabilitamos esa opción. Después de la restauración, el servidor seguirá funcionando.
Tomó alrededor de 4 minutos y 18 segundos restaurar los 10 GB de datos. Xtrabackup no bloquea su base de datos durante el proceso de copia de seguridad. Para bases de datos grandes (más de 100 GB), proporciona un tiempo de restauración mucho mejor en comparación con la utilidad mysqldump/shell. También lustreControl admite la copia de seguridad y la restauración parciales, como explicó uno de mis colegas en su blog:Copia de seguridad y restauración parciales.
Conclusión
Cada método tiene sus pros y sus contras. Como hemos visto, no existe un método que funcione mejor para todo lo que necesitas hacer. Necesitamos elegir nuestra herramienta en función de nuestro entorno de producción y el tiempo objetivo para la recuperación.
