Recuerda que en las ciencias informáticas un error casi siempre tiene varias soluciones, pero nosotros mostraremos la mejor y más eficiente.
Solución:
Si está utilizando principalmente tablas de innodb, aumente el tamaño de innodb_buffer_pool_size lo más grande posible (~ 80-90% del sistema asumiendo que nada más que mysqld realmente está consumiendo RAM). Sin embargo, esto requiere un reinicio de mysqld
Antes de la recarga, también puede configurar innodb_flush_log_at_trx_commit=2 para acelerar las cosas. Esto deshabilita el vaciado al disco cada confirmación (rompiendo la D en ACID), pero debería estar bien para una restauración. Si hay una falla catastrófica durante este proceso, de todos modos está comenzando desde cero. Asegúrese de volver a establecerlo en uno después de la restauración.
Esto se puede cambiar dinámicamente sin un rebote
Asegúrese de que innodb_flush_method = O_DIRECT esté configurado en su cnf. Esto requiere un reinicio
¿Se está vinculando a la CPU en la parte superior? Si tiene muchos datos de tabla comprimidos, serán inherentemente más lentos. No se puede hacer mucho al respecto aparte de obtener un núcleo más rápido. Multi core no lo ayudaría aquí ya que la carga se realiza en serie de todos modos.
Si está utilizando discos giratorios, si es posible, asegúrese de que el archivo de origen .sql se lea desde un conjunto diferente de HDD. Del mismo modo, durante la recarga (a menos que intente permitir que la recarga se replique), asegúrese de que el registro binario y el registro general estén desactivados.
Si está ejecutando 5.6, asegúrese de que el esquema de rendimiento sea no activado.
Esto es de esperar, ya que la restauración desde mysqldump lleva más tiempo que la copia de seguridad.
Para acelerar el proceso, considere otras herramientas de copia de seguridad:
-
copia de seguridad adicional. sin bloqueo para InnoDB, casi tan rápido como la copia de archivos. toma una copia de seguridad binaria (= copia el espacio de tablas de InnoDB).
-
midumper Realiza copias de seguridad lógicas, pero puede hacerlo en varios subprocesos, por lo que es más rápido que mysqldump
-
mylvmbackup. También muy rápido, pero requiere LVM, afecta el rendimiento cuando se crea una instantánea.
Yo iría con la opción #1.
Por lo general, mysqldump tardará tanto en hacer una copia de seguridad como xtrabackup, pero mucho más lento en la restauración. porque xtrabackup se copia por bloques, mientras que el archivo sql exportado por mysqldump tiene que ejecutarse uno a uno.
Estoy bastante seguro de que usar algunas formas podría mejorar la velocidad de importación, pero aún así le costará mucho tiempo, especialmente para una base de datos tan grande.
Por lo tanto, le recomiendo que instale xtrabackup, haga una copia de seguridad completa y luego restaure en el nuevo servidor.
o incluso de una manera más simple, considerando que podría hacer una copia de seguridad en frío, apagar el servidor mysql, copiar todos los archivos incluidos ibdata1, ib_logfile*carpeta mysql, etc. a la nueva ubicación, modifique my.cnf con nueva ubicación si se cambia. Todavía no lo he probado, pero no he visto ningún problema.
la primera forma es absolutamente la mejor.
¡Espero que esto haya sido útil!
Si tienes algún disgusto y capacidad de ascender nuestro post te inspiramos escribir un paráfrasis y con mucho placer lo leeremos.