¿Cómo recuperar la base de datos Xiachian eliminada?

Nuestra base de datos en línea utiliza MySQL. Antes del 23 de abril, nuestro nodo maestro de base de datos en línea tiene tres métodos de respaldo. En primer lugar, hay un nodo de copia de seguridad de la base de datos independiente, que mantiene la sincronización de datos en tiempo real con el servidor en línea y puede cambiarse al uso en línea cuando sea necesario. El segundo es volcar periódicamente toda la base de datos en un archivo SQL para realizar una copia de seguridad y guardarla una vez al día. La fuente de la copia de seguridad es el nodo esclavo de la base de datos. En tercer lugar, el nodo maestro abre el binlog y lo copia. El valor predeterminado es guardar el binlog durante diez días. Si ocurre algún evento dentro de diez días, todos los datos se pueden restaurar por completo desde el registro. Estas tres copias de seguridad se almacenan en dos máquinas físicas diferentes y en tres particiones diferentes. Este es el método más seguro que se me ocurrió en ese momento. El 23 de abril, migramos el nodo maestro de la base de datos a una nueva máquina física y actualizamos la versión a 5.5. Debido a problemas de versión y configuración, el nodo esclavo original no se puede utilizar directamente. Las copias de seguridad diarias se originan en los nodos esclavos (la copia de seguridad del nodo maestro provoca aproximadamente 1 hora de retraso para el sitio web y las aplicaciones móviles), lo que detiene las actualizaciones. Sólo el último binlog sigue ejecutándose. Después de la migración de la base de datos, el servidor de aplicaciones tuvo algunos problemas de rendimiento que tardaron en resolverse, incluida la reparación de la compatibilidad de MySQL 5.5 con el código original, el cambio del servidor de aplicaciones de gunicorn al proxy de red Python uwsgi y luego hubo algunas tareas de desarrollo que retrasaron la nodo de respaldo de reactivación. Nuestros errores en la gestión de la migración de bases de datos fueron la causa principal de este incidente. Sin nodos de respaldo de la base de datos, el trabajo de migración no se puede completar. Todos nosotros en el equipo técnico somos responsables de este incidente y, si bien esta vulnerabilidad podría haberse descubierto en dos meses, cada uno de nosotros puede hacer de este trabajo una alta prioridad. También es posible que todos propongamos medidas correctivas adecuadas para mantener los datos seguros, como extender el tiempo de retención del registro binario antes de habilitar los nodos esclavos. Precisamente por nuestros errores la base de datos se convierte en el eslabón más débil del sistema y no puede soportar el impacto de eventos accidentales.