Autor: Zhouyu
Enlaces: cnblogs.com/zhouyu629/p/3734494.html
Experimentado dos días de esfuerzos continuos, finalmente, se reanudaron los datos del servidor de producción el mal uso, una vez eliminados.
El proceso del accidente y soluciones en este registro, alertar a sí mismo ya otros que sugieren Mo cometió este error.
Espero que los problemas encontrados amigos puede encontrar un rastro de inspiración para resolver el problema.
01 fondo accidente
Organizar una hermana instalado en una instalación de lado la investigación de vanguardia hermana servidor de producción de Oracle, la instalación no se siente listo para volver a instalar desinstalación.
Encuentra desinstalación de Internet, donde la línea de comandos para ejecutar eliminar el directorio de instalación de Oracle, el comando es el siguiente:
rm -rf $ORACLE_BASE/*
Si no se asigna la variable ORACLE_BASE, a continuación, el comando se convierte en:
rm -rf /*
Y así sucesivamente, pero mi hermana utiliza Raíz cuenta ah. De esta manera, la totalidad de los archivos de disco eliminan todo, incluida la aplicación de Tomcat, MySQL base de datos y así sucesivamente ......
base de datos MySQL no se está ejecutando? Linux puede borrar el archivo que se está ejecutando? Debido a que se elimina por completo, y finalmente dejó un archivo de Tomcat de Log, se estima que el archivo es demasiado grande, ya veces no se elimina correctamente.
Viendo los ojos hermana remordimiento, es esta cosa que hice arreglos para que ella haga, no decirle la apuesta clara, sin ningún tipo de formación, la responsabilidad sólo puede haber una persona hacia atrás, y además de cómo hacer que sea hermoso oso esta responsabilidad ?
Una llamada a la habitación, colgar el disco a otro servidor, vista SSH recuperación de todos los archivos se borran, este servidor se está ejecutando, pero el sistema de producción de un cliente, ah, ha estado funcionando durante seis meses, fue restaurada tan pronto como sea posible ah.
Entonces envió para fuera de línea de seguridad de la base de datos, buscar el archivo de copia de seguridad sólo 1 KB, que está a sólo unas pocas líneas de comentario mysqldump familiarizado (escritura de reserva Crontab basa su éxito en cuestión), la copia de seguridad más cercano es en diciembre de 2013 de una casa muy permeable todas las noches de lluvia ah.
Piense en ello un líder dijo que el caso: Cuando un sistema de producción de colgar, encontrar todos los respaldos tienen preguntas, DVD también tiene rasguños, unidades de cinta también es mala (una industria de alto nivel, las estimaciones anteriores también hacen un CD-ROM de copia de seguridad ), no esperaba a cumplido realmente mi cuerpo, ¿cómo?
Después de que el departamento de cabezas conscientes de la situación, el peor de los casos se ha realizado el Plan B: AA y el liderazgo de producto dirigió personalmente Domingo donde los clientes corrieron a la ciudad de lunes a comunicación de liderazgo; BB y CC pasan por allí para encontrar maneras de administrador de cliente convencer a los clientes ......
02 paja: ext3grep
A la Internet para encontrar información rápidamente ser eliminado por error de recuperación de datos, encontrar un muy ext3grep puede recuperar archivos borrados por rm-rf, que el formato del disco también ext3, y hay muchas historias de éxito en línea.
Así que encendió una luz de esperanza, tan pronto como sea posible en el disco umount, para prevenir la re-escrito para dar a borrará sector de archivos. Descargar ext3grep, instale (compilar e instalar el laborioso proceso, por el momento no es la tabla).
En primer lugar realizar un comando de exploración nombre de archivo:
ext3grep /dev/vgdata/LogVol00 --dump-names
Imprimir todos los archivos borrados y caminos, alegría, sin llevar a cabo un plan B, los archivos están en el mismo.
Este software puede restaurar los archivos de directorio, todos los comandos sólo se puede ejecutar la recuperación:
ext3grep /dev/vgdata/LogVol00 --restore-all
Los resultados de la actual falta de espacio en disco, de ninguna manera sólo puede restaurar archivos, tratan algunos archivos, pero todavía falla parcial éxito parcial:
ext3grep /dev/vgdata/LogVol00 --restore-file var/lib/mysql/aqsh/tb\_b\_attench.MYD
No se puede evitar un resfriado, es que fue escrito para eliminar archivos en el disco? La probabilidad de recuperación no es, ah, puede restaurar algunas recuento de algunos archivos MYD, tal vez sólo importantes archivos de datos puede ser restaurada.
Así que en primer lugar los nombres de los archivos redirigidos a un archivo en el archivo:
ext3grep /dev/vgdata/LogVol00 --dump-names >/usr/allnames.txt
Filtrar todo el nombre del archivo de base de datos MySQL guardado como mysqltbname.txt.
Recuperar archivos de secuencias de comandos:
while read LINE
do
echo "begin to restore file " $LINE
ext3grep /dev/vgdata/LogVol00 --restore-file $LINE
if \[ $? != 0 \]
then
echo "restore failed, exit"
fi
done < ./mysqltbname.txt
Ejecución, correr alrededor de 20 minutos, la recuperación de archivos de más de 40, pero no lo suficiente ah, que tienen casi 100 tablas, cada tabla FRM, myd, MYI tres documentos, la forma de decir que hay algo más que 300 ah!
Volverá archivos adjuntos a una base de datos existente, sino también a los permisos de archivo a 777, MySQL reinicio, se puede considerar parte de la espalda de datos, pero el cliente es importante para firmar los datos de asistencia, los informes lado del teléfono de los datos (estos datos se dice por el cliente hacer desempeño de los empleados) no venir ah espalda.
Se supone que? Medio y probó otra Extundelete herramienta, con la gramática ext3grep básicamente el mismo principio debe ser el mismo, pero se dice que restaurar por el directorio.
Bueno, que darle una oportunidad:
extundelete /dev/vgdata/LogVol00 --restore-directory var/lib/mysql/aqsh
En el momento justo, la recuperación no sale! ! ! ! ! ! ! ! Estos archivos han sido destruidos. Con el liderazgo del informe, la aplicación del plan B ahora ...... desesperación a casa del trabajo. (Fin de semana, volver atrás y tomar un descanso, pensar en una manera)
03 tuvieron una idea: binlog
A la mañana siguiente se despertó temprano en la mañana (problemas del corazón ah), la parte posterior del equipo, vaya a la empresa (este fin de semana será reembolsado, no criticado, notificación, multas, el despido por el bien, pero también lo que el ah fin de semana).
Aún ejecutar ext3grep, Extundelete, receta ah que pondrá a los sistemas de rack de servidor de prueba, puede mirar los datos para encontrar maneras de arreglarla.
Llevado a cabo en un servidor de prueba mysqldump, recuperar archivos, recuperar de nuevo la cubierta del archivo, agregar permisos para el archivo, reiniciar MySQL.
Espera, espera, no hay que binlog? Nuestros servicios están obligados a binlog abierta, tal vez usted puede recuperar los datos binlog en ella?
Así que encontrar los archivos de volcado de binlog el nombre de archivo de un total de tres:
-
mysql-binlog0001
-
mysql-bin.000009
-
mysql-bin.000010
Restaurar aproximadamente 0001:
ext3grep /dev/vgdata/LogVol00 --restore-file var/lib/mysql/mysql-bin.000001
En realidad no ...... vistazo a los otros dos archivos, mysql-bin.000010 probablemente unos pocos cientos de MB, debe ser un poco difícil, lleve a cabo el comando de restauración, en realidad un éxito!
SCP tan pronto como sea posible para el servidor de prueba. Ejecución binlog restaurar:
mysqlbinlog /usr/mysql-bin.000010 | mysql -uroot -p
Introduzca la contraseña, pegado (un signo bueno), después de una larga espera ha terminado. Abrir la aplicación, oh, gracias circuito cerrado de televisión, MTV, los datos de vuelta!
04 PostScript
También quiero recordar el accidente, no volverá a cometer el mismo error. accidente de la reflexión de la siguiente manera:
-
No antelación para organizar su tiempo de este mantenimiento del servidor MM explicar la situación, y él no dan importancia a la gestión de caos, confusión proceso. Un sistema de producción en línea, cualquier cambio debe planificar primero y luego pasar.
-
problemas de seguridad automáticas, nadie cheques. el personal de seguridad sin conexión 1K por descargar archivos desde el servidor, pero nunca en serio. Necesitamos una clara responsabilidad en el lugar de trabajo.
-
Después del accidente, que no descubrió, haciendo que parte de los datos escritos en el disco, lo que resulta en un problema irrecuperable. Necesidad de programa de control de la aplicación de escritura, una vez que el servicio es anormal, alertas SMS a la persona responsable.
-
De acuerdo con comentarios recordatorios, además de un: No se puede utilizar el usuario Root para operar. Usted debe ofrecer diferentes niveles de privilegios de usuario en el servidor.
A través de este accidente
Compartir bajo las herramientas de enlace utilizado en este documento:
1.https: //code.google.com/p/ext3grep/
2.http: //extundelete.sourceforge.net/
función Ext3grep con principios similares también debe ser similar. Compilar e instalar las dependencias más, usted puede buscar en Internet acerca de la instalación. [Por desgracia se le dio autor howto una pared, voy a FQ howto descargar el documento pdf, después de leer que tendrá una mejor comprensión del sistema de archivos de Linux. Descargar: http: //pan.baidu.com/s/1kT1ETVp].
Por último, espero que los colegas pequeños amigos pueden recordar este evento artículo, feliz de tocar el código, nunca se equivoca -
