La restauración de una copia de seguridad MYSQL es muy lenta

Estoy restaurando un archivo de volcado mysql de 26 GB en un MySQL de 16 GB de RAM que se ejecuta en MacOS.

Primero intenté restaurar la copia de seguridad de MySQL como esta

mysql -ufoo -pbar foo < foo.dump

Esto bloqueó mySQL porque foo.dump contiene muchos caracteres internacionales muy divertidos y el comando anterior no se ocupaba de las codificaciones.

Así que lo intenté

mysql -uroot -p --default-character-set=utf8 foo
mysql> SET names 'utf8'
mysql> SOURCE foo.dump

Esto funcionó y el proceso de restauración no se bloqueó porque supongo que los divertidos personajes internacionales se manejaron correctamente.

Pero ahora el proceso de restauración es muy lento. Para el archivo de 26 GB, se ejecuta durante toda la noche (una tabla que tiene 40 millones de filas es la culpable). Puedo ver que está restaurando aproximadamente 3000 filas cada 15 segundos. Pero a este ritmo, el proceso de restauración llevará una eternidad.

Entonces, ¿hay alguna manera de restaurar el archivo de volcado rápidamente y no estropear las codificaciones?

Su proceso es lento debido a la gran I/Oactividad del disco para las operaciones de SQL. Necesita optimizar innodb para operaciones intensivas. Modifique su archivo de configuración mysql para tener estas líneas:

innodb_buffer_pool_size = 4G
innodb_log_buffer_size = 256M
innodb_log_file_size = 1G
innodb_write_io_threads = 16

innodb_buffer_pool_size: el área de memoria donde InnoDB almacena en caché la tabla y los datos de índice. Cuando los datos de la tabla se almacenan en caché en el grupo de búferes InnoDB, se puede acceder a ellos repetidamente mediante consultas sin requerir ninguna E / S de disco. Los cambios de datos se almacenan en caché en lugar de escribirse inmediatamente en el disco.

Una agrupación de almacenamiento intermedio más grande requiere menos E / S de disco para acceder a los mismos datos de la tabla más de una vez. En un servidor de base de datos dedicado, puede establecer el tamaño de la agrupación de almacenamiento intermedio en el 80% de la memoria física de la máquina; de lo contrario, usar el 50 to 75porcentaje de memoria del sistema. El tamaño predeterminado de la agrupación de almacenamiento intermedio es 128 MB

innodb_log_buffer_size: el tamaño en bytes del búfer que InnoDB usa para escribir en los archivos de registro en el disco.

Un búfer de registro grande permite ejecutar transacciones grandes sin la necesidad de escribir el registro en el disco antes de que se confirmen las transacciones. Por lo tanto, si tiene transacciones que actualizan, insertan o eliminan muchas filas, hacer que el búfer de registro sea más grande ahorra E / S de disco.

innodb_log_file_size: el tamaño en bytes de cada archivo de registro en un grupo de registro. Un tamaño grande asegura que el servidor pueda suavizar los picos y los canales en la actividad de carga de trabajo, lo que a menudo significa que hay suficiente espacio de rehacer registro para manejar más de una hora de actividad de escritura. Cuanto mayor sea el valor, se requiere menos actividad de vaciado del punto de control en el grupo de búferes, lo que ahorra E / S de disco

Innodb_write_io_threads: el número de subprocesos de E / S para operaciones de escritura en InnoDB. El valor predeterminado es 4. InnoDB utiliza subprocesos en segundo plano para atender varios tipos de solicitudes de E / S. . Puede configurar la cantidad de subprocesos en segundo plano que sirven para leer y escribir E / S en páginas de datos utilizando los parámetros de configuración innodb_read_io_threads e innodb_write_io_threads.

Estos parámetros significan el número de subprocesos en segundo plano utilizados para las solicitudes de lectura y escritura, respectivamente. Cada subproceso en segundo plano puede manejar hasta 256 solicitudes de E / S pendientes.