¿Cuál es la forma más rápida de volcar & amp; cargar una base de datos MySQL InnoDB usando mysqldump?

StackOverflow https://stackoverflow.com/questions/131085

  •  02-07-2019
  •  | 
  •  

Pregunta

Me gustaría crear una copia de una base de datos con aproximadamente 40 tablas InnoDB y alrededor de 1,5 GB de datos con mysqldump y MySQL 5.1.

¿Cuáles son los mejores parámetros (es decir: - transacción única) que resultarán en el volcado y la carga más rápidos de los datos?

Además, al cargar los datos en el segundo DB, es más rápido:

1) canalice los resultados directamente a la segunda instancia del servidor MySQL y use la opción --compress

o

2) cárguelo desde un archivo de texto (es decir: mysql < my_sql_dump.sql)

¿Fue útil?

Solución

Canalícelo directamente a otra instancia, para evitar la sobrecarga del disco. No se moleste con --compress a menos que esté ejecutando en una red lenta, ya que en una LAN rápida o loopback, la sobrecarga de la red no importa.

Otros consejos

RÁPIDAMENTE volcar una base de datos inactiva:

Uso de " -T " La opción con mysqldump da como resultado muchos archivos .sql y .txt en el directorio especificado. Esto es ~ 50% más rápido para volcar tablas grandes que un solo archivo .sql con instrucciones INSERT (toma 1/3 menos tiempo de reloj de pared).

Además, hay una gran ventaja al restaurar si puede cargar varias tablas en paralelo y saturar múltiples núcleos. En una caja de 8 núcleos, esto podría ser tanto como una diferencia de 8X en el tiempo del reloj de pared para restaurar el volcado, además de las mejoras de eficiencia proporcionadas por "-T". Porque " -T " hace que cada tabla se almacene en un archivo separado, cargarlas en paralelo es más fácil que dividir un archivo .sql masivo.

Llevando las estrategias anteriores a su extremo lógico, uno podría crear un script para volcar una base de datos ampliamente en paralelo. Bueno, eso es exactamente lo que hace el Maakit mk-parallel-dump (ver http: // www .maatkit.org / doc / mk-parallel-dump.html ) y las herramientas mk-parallel-restore son; scripts perl que realizan múltiples llamadas al programa mysqldump subyacente. Sin embargo, cuando intenté usarlos, tuve problemas para completar la restauración sin duplicar los errores clave que no ocurrieron con los volcados de vainilla, así que tenga en cuenta que su kilometraje puede variar.

Volcado de datos de una base de datos LIVE (sin interrupción del servicio):

El modificador de transacción única es muy útil para realizar un volcado de una base de datos en vivo sin tener que detenerla o volcar una base de datos esclava sin tener que detener la esclavitud.

Lamentablemente, -T no es compatible con una sola transacción, por lo que solo obtienes una.

Por lo general, hacer el volcado es mucho más rápido que restaurarlo. Todavía hay espacio para una herramienta que toma el archivo de volcado monolítico entrante y lo divide en varias partes para cargarlo en paralelo. Que yo sepa, dicha herramienta aún no existe.

La transferencia del volcado a través de la red suele ser una victoria

Para escuchar un volcado entrante en una ejecución de host: 

nc -l 7878 > mysql-dump.sql

Luego, en su host DB, ejecute 

mysqldump $OPTS | nc myhost.mydomain.com 7878

Esto reduce la contención de los ejes del disco en el maestro al escribir el volcado en el disco, lo que acelera ligeramente su volcado (suponiendo que la red sea lo suficientemente rápida como para mantenerse al día, una suposición bastante segura para dos hosts en el mismo centro de datos). Además, si está creando un nuevo esclavo, esto ahorra el paso de tener que transferir el archivo de volcado una vez que finaliza.

Advertencias: obviamente, debe tener suficiente ancho de banda de red para no ralentizar las cosas insoportablemente, y si la sesión TCP se interrumpe, debe comenzar de nuevo, pero para la mayoría de los volcados esto no es una gran preocupación.

Por último, quiero aclarar un punto de confusión común.

A pesar de la frecuencia con la que ve estos indicadores en ejemplos y tutoriales de mysqldump, son superfluos porque están activados de forma predeterminada:

  • --opt
  • --add-drop-table
  • --add-locks
  • --create-options
  • --disable-keys
  • --extend-insert
  • --lock-tables
  • --quick
  • --set-charset .

De http://dev.mysql.com/doc/refman /5.1/en/mysqldump.html :

  

El uso de --opt es lo mismo que especificar --add-drop-table, --add-locks, --create-options, --disable-keys, --extended-insert, --lock-tables , --quick, y --set-charset. Todas las opciones que significa --opt también están activadas de forma predeterminada porque --opt está activado de forma predeterminada.

De esos comportamientos, " - rápido " es uno de los más importantes (omite el almacenamiento en caché de todo el conjunto de resultados en mysqld antes de transmitir la primera fila), y puede estar con " mysql " (que NO activa --quick por defecto) para acelerar drásticamente las consultas que devuelven un gran conjunto de resultados (por ejemplo, volcar todas las filas de una tabla grande).

creo que será mucho más rápido y le ahorrará espacio en disco si intenta replicación de base de datos en lugar de usar mysqldump. personalmente uso sqlyog enterprise para mi trabajo realmente pesado, pero también hay una serie de otras herramientas que pueden proporcionar los mismos servicios. a menos, por supuesto, que desee utilizar solo mysqldump.

Para innodb, --order-by-primary --extended-insert suele ser el mejor combo. Si después de cada último bit de rendimiento y el cuadro de destino tiene muchos núcleos de CPU, es posible que desee dividir el archivo de volcado resultante y realizar inserciones paralelas en muchos hilos, hasta innodb_thread_concurrency / 2.

Además, modifique innodb_buffer_pool_size en el objetivo al máximo que pueda pagar, y aumente innodb_log_file_size a 128 o 256 MB (cuidado con esto, debe eliminar los archivos de registro antiguos antes de reiniciar el demonio mysql, de lo contrario no se reiniciará)

Utilice la herramienta mk-parallel-dump de Maatkit.

Al menos eso probablemente sería más rápido. Confiaría en mysqldump más.

¿Con qué frecuencia haces esto? ¿Es realmente un problema de rendimiento de la aplicación? Quizás debería diseñar una forma de hacerlo que no necesite volcar todos los datos (¿replicación?)

Por otro lado, 1.5G es una base de datos bastante pequeña, por lo que probablemente no será un gran problema.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top