mover live innodb db de un servidor a otro

mover live innodb db de un servidor a otro

Necesito mover una base de datos innodb de un servidor a otro; también va desde mysql > mariadb. Quiero asegurarme de que no haya ningún problema y con eso usaré mysqldump para exportar y luego importar en el nuevo servidor. La configuración de my.cnf es diferente en el nuevo servidor, por lo que no deseo intentar copiar archivos. Tampoco me preocupa del todo el tiempo de inactividad, siempre y cuando garantice un buen volcado/importación sin problemas.

Debido a que se trata de una base de datos activa, me preocupan los errores en el volcado debido a transacciones o cualquier otra cosa que, al importarse al nuevo servidor, causaría problemas de restricciones/corrupción.

¿Cuál es el mejor procedimiento aquí? Esto es lo que estaba pensando...

  1. reinicie mysql sin acceso de usuario para que nadie pueda leer/escribir en la base de datos.
  2. mysqldump conmysqldump -u [username] -p[password] -h [host] [databaseName] > [backup-name].sql
  3. importar conmysql -u [username] -p[password] -h [host] [databaseName] < [filename].sql

¿Es posible reiniciar MySQL y bloquear a todos los usuarios? ¿Resolvería esto cualquier transacción pendiente y garantizaría que los datos sean legítimos al importarlos? Básicamente, quiero "cerrar" el acceso a la base de datos para siempre una vez que comience el proceso de copia de seguridad, ya que una vez que se importe en el nuevo servidor, nunca será necesario volver a acceder a él y, lo que es más importante, no quiero que se acceda a él durante el volcado. restaurar al otro servidor. Por supuesto, me gustaría dejar la base de datos en el servidor original en caso de que surjan problemas de importación.

Respuesta1

Tenga en cuenta que debe utilizar --hex-blobwith mysqldumpsi tiene campos cifrados en la base de datos. Si --hex-blobno se utiliza, los datos quedarán inútiles cuando se importen.

Antes de realizar una copia de seguridad, haga una FLUSH TABLES WITH READ LOCKpara evitar cualquier cambio. Puede canalizar la copia de seguridad al nuevo servidor en un solo paso, guardando el paso de copiar el archivo SQL.

mysqldump --single-transaction --routines --triggers --events --hex-blob db-name | mysql -h server db-name

Respuesta2

Lo primero que debe hacer es hacer una copia de seguridad de su base de datos y luego importarla al nuevo servidor y probar el nuevo servidor primero si todo está bien. También verifique el tiempo que toma para crear una copia de seguridad y restaurarla en el nuevo servidor. usted sabe cuánto tiempo le llevará poner el nuevo servidor en producción.

cuando esté listo para pasar todo al nuevo servidor, es mejor que desactive todas las conexiones a su base de datos a menos que sea localhost, ya que usará mysqldump para acceder a la base de datos y hacer la copia de seguridad. Si todos los accesos a la base de datos provienen de su servidor web, puede dejarlo. el servidor web, la otra forma sería configurar iptables para bloquear todo el tráfico en su puerto mysql excepto localhost. luego hace una copia de seguridad de su base de datos, la restaura en el nuevo servidor, configura su nuevo servidor en vivo y se asegura de que todas sus conexiones vayan al nuevo servidor.

Respuesta3

Todo esto depende de si su base de datos es lo suficientemente grande o pequeña, también depende del servicio que esté ejecutando, pero supongo que debe haber alguna ventana de mantenimiento, durante los fines de semana a altas horas de la noche, apague su Apache/nginx, también puede reiniciar su base de datos con la red deshabilitada. puerto local con firewall o diferente. exportar:

mysqldump -p --single-transaction --routines --triggers --events DATABASE | gzip > backup.sql.gz

importar:

zcat backup.sql.gz | mysql -f -p DATABASE

volver a comprobar:

mysql_upgrade -p -f

zipyzcat te ayudará a hacerlo más rápido.

información relacionada