Nos hemos encontrado varias veces con un escenario que hace que nuestra base de datos MySQL se corrompa cuando intentamos restaurar un archivo mysqldump. Hemos utilizado los mismos procedimientos (a través de scripts por lotes) durante varios años sin problemas, y recientemente comenzamos a encontrar el problema en los últimos meses.
Estamos ejecutando la versión del servidor MySQL: 5.7.18-0ubuntu0.16.04.1 (Ubuntu 16.04.2 LTS) y estamos restaurando dos tablas MyISAM con ~350 000 registros (combinados).
Usamos el siguiente script cmd para hacer una copia de seguridad de las tablas desde nuestro servidor interno y restaurarlas en el servidor de base de datos remoto:
"%mysql_path%\mysqldump.exe" --user=root --password="%PWD%" --host=%source% ourdbname --tables table1 table2 | "%mysql_path%\mysql.exe" -uroot --password="%PWD%" --host=%dbtarget% -C ourdbname
Donde las %%variables se proporcionan como parte del script por lotes más grande. Básicamente, estamos canalizando la salida del volcado a mysql.exe para restaurarlo en el servidor remoto. El script se ejecuta en una máquina con Windows 10, pero tanto la base de datos de origen como la de destino están en Linux.
La parte de restauración es donde la base de datos se daña, lo que hace que el uso de la CPU del servidor de base de datos aumente al 100% por núcleo. La única forma que hemos encontrado para solucionar este problema es finalizar el proceso mysql, eliminar los .frm, .MYD, .MYIarchivos, luego iniciar mysql y restaurar las tablas localmente (explorar el archivo mysqldump en el servidor y restaurar).
Descubrimos que la base de datos solo se corrompe cuando tenemos tráfico activo en el sitio web. Entonces, podríamos cerrar el sitio (un servidor separado que ejecuta Java se conecta a través de JDBC), ejecutar el script y luego volver a poner el sitio en línea y funciona el 100% del tiempo. Obviamente esto no es lo ideal, pero es la única forma en que podemos hacerlo ahora.
¿Alguna idea de lo que podría estar causando esto? ¿Sugerencias sobre cómo solucionarlo sin tener que desactivar el servidor de aplicaciones para el usuario?
Respuesta1
Parece que está utilizando MyISAM como motor de base de datos para su sitio. Recomiendo usar InnoDB, es mejor en muchos sentidos.
Sin embargo, el principal problema aquí es que lo más probable es que su aplicación web esté escribiendo en la base de datos al mismo tiempo que su copia de seguridad se escribe en la base de datos. Dependiendo del esquema de tabla real, esto puede causar todo tipo de efectos negativos. Usar MyISAM solo hace que funcione, ya que no hay bloqueo a nivel de fila en MyISAM si no recuerdo mal.
Entonces, usar InnoDB podría ayudar con esto, pero, de nuevo, puede que no. La única opción segura podría ser simplemente detener el servidor de aplicaciones para el usuario. Otra opción es crear una API para la aplicación remota que escribiría de forma segura los datos entrantes en la base de datos.