¿Cómo volcar de manera eficiente una gran base de datos innodb de MySQL?

Obtuve un servidor de base de datos MySQL de producción Ubuntu 10.04 donde el tamaño total de la base de datos es de 260 GB, mientras que el tamaño de la partición raíz es de 300 GB donde se almacena la base de datos, esencialmente significa alrededor del 96% de / está lleno y no queda espacio para almacenar volcado / copia de seguridad etc. Ningún otro disco está conectado al servidor a partir de ahora.

Mi tarea es migrar esta base de datos a otro servidor que se encuentre en un centro de datos diferente. La pregunta es cómo hacerlo de manera eficiente con un tiempo de inactividad mínimo.

Estoy pensando en línea de:

• Solicite adjuntar una unidad adicional al servidor y realice un volcado en esa unidad. [EDITAR: no es posible ahora.]
• Transfiera el volcado al nuevo servidor, restaurelo y haga que el nuevo servidor sea esclavo del existente para mantener los datos sincronizados
• Cuando se necesite la migración, interrumpa la replicación, actualice la configuración esclava para aceptar solicitudes de lectura / escritura y haga que el servidor antiguo sea de solo lectura para que no entretenga ninguna solicitud de escritura y diga a los desarrolladores de aplicaciones que actualicen su configuración con una nueva dirección IP para db.

¿Cuáles son sus sugerencias para mejorar este o cualquier otro enfoque alternativo para esta tarea?

Si está pensando en migrar a otro DB Server con exactamente la misma versión de MySQL, es posible que desee rsyncel datadirdel servidor antiguo al nuevo servidor.

Esto funcionará independientemente del diseño del archivo InnoDB o incluso de la presencia de tablas MyISAM.

1. instale la misma versión de mysql en ServerB que ServerA tiene
2. En ServerA, ejecute RESET MASTER;para borrar todos los registros binarios antes del proceso rsycn. Si el registro binario no está habilitado, puede omitir este paso.
3. En ServerA, ejecute SET GLOBAL innodb_max_dirty_pages_pct = 0;desde mysql y aproximadamente 10 minutos (Esto purga las páginas sucias del InnoDB Buffer Pool. También ayuda a realizar un apagado de mysql más rápido) Si su base de datos es todo MyISAM, puede omitir este paso.
4. rsync / var / lib / mysql de ServerA a / var / lib / mysql en ServerB
5. Repita el paso 3 hasta que un rsync tome menos de 1 minuto
6. service mysql stop en el servidor A
7. Realice una rsync más
8. scp ServerA: /etc/my.cnf to ServerB: / etc /.
9. service mysql start en ServerB
10. service mysql start en el servidor A (opcional)

Esencialmente, esto es lo que le gustaría a este script

mysql -u... -p... -e"RESET MASTER;"
mysql -u... -p... -e"SET GLOBAL innodb_max_dirty_pages_pct = 0;"
RSYNCSTOTRY=10
cd /var/lib/mysql
X=0
while [ ${X} -lt ${RSYNCSTOTRY} ]
do
    X=`echo ${X}+1|bc`
    rsync -r * targetserver:/var/lib/mysql/.
    sleep 60
done
service mysql stop
rsync -r * targetserver:/var/lib/mysql/.
service mysql start

Un miembro del StackExchange de DBA dijo que debería alejarme de FLUSH TABLES WITH READ LOCK;algo basado en mysqlperformanceblog.com

Leí y aprendí que los SELECT contra las tablas de InnoDB en el medio de un FLUSH TABLES WITH READ LOCK;todavía pueden permitir que las escrituras ocurran de alguna manera. Como se señaló en el comentario de Arlukin , LVM funcionaría bien FLUSH TABLES WITH READ LOCKen InnoDB (+1 por su comentario).

• http://www.mysqlperformanceblog.com/2012/03/23/how-flush-tables-with-read-lock-works-with-innodb-tables/
• http://forums.mysql.com/read.php?22,184590,184610

Para todos los usuarios que no son LVM, está de acuerdo con una base de datos de MyISAM para usar FLUSH TABLES WITH READ LOCK;. Para InnoDB, --single-tranactionmanténgase en uso en mysqldumps por favor.

Un volcado y restauración de una base de datos de ese tamaño llevaría horas. Lo haría, dependiendo de las versiones de mysql siempre que el número de versión aumente y no haya saltos en el número de revisión principal. Debería poder tomar los archivos de la base de datos sin formato en / var / lib / mysql y ponerlos en el nuevo servidor, establecer los permisos y encender el servidor con el modificador --skip-grant-tables. Agregue las subvenciones necesarias para los usuarios que reflejen la nueva dirección IP y luego reinicie normalmente.

Me ocuparía del tamaño de su base de datos, ya que es demasiado grande para ser eficiente.

Puede seguir estos pasos para migrar esta enorme base de datos InnoDB.

• Instale SSHFS y monte la partición relevante del servidor remoto en el servidor de producción
• Use Percona XtraBackup para obtener una copia de la base de datos InnoDB y guardarla directamente en el directorio montado SSHFS

• Esta tarea llevará varias horas. Para minimizar el efecto de la secuencia de comandos hotcopy en el servidor en vivo, establezca una prioridad baja usando renice

  $ renice -n 5 -p <SCRIPT-PID>

• Asegúrese de que ambos servidores estén ejecutando la misma versión del servidor MySQL.
• Una vez completada la copia en caliente, puede restaurarla en el nuevo servidor para iniciar el proceso de replicación

Puede experimentar lentitud durante este proceso, pero definitivamente no hay tiempo de inactividad. Percona XtraBackup creará una copia en caliente que es más rápida y consume menos recursos en comparación con mysqldump. Esto es ideal para una gran base de datos InnoDB.

Dependiendo de los patrones de uso y las estadísticas, puede ejecutar este proceso cuando haya un tráfico mínimo en el servidor. ¿Quizás hacer esto durante el fin de semana es una buena idea? Lo anterior es solo un resumen del proceso. Es posible que deba revisar la documentación de Percona XtraBackup y SSHFS.

Podrías volcar la base de datos directamente al servidor remoto ...

$ mysqldump | ssh user@server 'cat - > dumpfile.sql.gz'

... SQL debería comprimir bien, por lo que debería hacer esto mucho más rápido con una de estas opciones, aunque también dependerá de la cantidad de RAM que tenga en la caja ...

$ mysqldump | ssh -C user@server 'cat - > dumpfile.sql.gz'
$ mysqldump | gzip -c | ssh user@server 'cat - > dumpfile.sql.gz'