Tengo una situación con una tabla particular que ahora cree que contiene 4 petabytes de datos. Sé que suena bien, pero te aseguro que sólo está en una partición de 60 GB.
Esta tabla tiene 9 campos. Uno de ellos es un domain_idcampo. Es el mejor campo para identificar las filas, ya que solo hay aproximadamente 6300. La única otra opción de campo que puede igualar tiene más de 2 millones de registros, y eso es simplemente más difícil.
No puedo hacer un mysqldump directo porque intentará generar todos los 4 PB de datos y llenar la unidad mucho antes de que se acerque a eso, por lo que necesito eliminar quirúrgicamente las cosas buenas, destruir la base de datos y recrearla.
Creo que si puedo hacer un volcado para cada domain_idregistro, obtendré la mayoría de los datos utilizables. Esto es lo que estoy tratando de usar:
mysqldump -u root --skip-opt -q --no-create-info --skip-add-drop-table \
--max_allowed_packet=1000000000 database table --where="domain_id=10" \
> domains10.sql
Al usar esto, espero domain_id 10que se exporten todas las filas con.
Sin embargo, cuando verifico la exportación, solo obtengo 1 fila; sin embargo, cuando miro la base de datos, hay muchas filas. Es como si el operador simplemente encontrara uno y luego se diera por vencido.
He probado varios operadores. Usando <o >puedo obtener más datos, pero la exportación se detiene en ciertas filas donde los datos se han visto comprometidos. Con más de 6000 por revisar, no puedo delimitar con suficiente facilidad qué filas se ven afectadas en la exportación.
Entonces, lo que necesito es un operador que básicamente haga lo que pensé =que haría, simplemente exportar todos los registros que coincidan con el campo específico.
También tenga en cuenta que la única forma de conseguir que esta base de datos sea accesible es a través de innodb force recovery 3. Así que necesito hacer esto bien, porque una vez hecho esto, tengo que eliminar la base de datos para que mysql vuelva a funcionar.
Esperamos respuestas útiles.
Respuesta1
Por lo que escribe, parece que la base de datos se ha corrompido (pensar en 4PB en lugar de 60GB es una especie de obsequio).
Dudo que pueda obtener alguna garantía de confiabilidad de la información recuperada, a menos que repare la base de datos primero. ¿Has probado esto?
De lo contrario, ¿qué sucede si presiona la tecla "-f" para continuar incluso si se encuentran errores?
Respuesta2
¿Qué tamaño crees que debería tener realmente la mesa?
Podrías intentar convertirlo a myisam:
alter table ggg engine=myisam;
Sin embargo, parece que tienes una base de datos dañada.
El mejor plan podría ser contactar a los chicos de innodb para obtener ayuda.
Respuesta3
No soy administrador de bases de datos, así que tal vez esta idea sea totalmente equivocada, pero ¿hay datos en el volcado que deberían ser consistentes en todos los registros con una cadena de texto? Me preguntaba si es posible hacer un volcado de su base de datos de "4 petabytes" y redirigirla a través de un filtro grep/strings para que, si los datos dañados no son una cadena válida, no se escriban en el disco. Sin embargo, esto dependería de si los datos corruptos eran simplemente basura incomprensible...
De lo contrario, alguien más tendrá que sugerir una herramienta de reparación para intentar arreglar la base de datos.
Respuesta4
Intente agregar --skip-extended-insert. Es posible que las cosas se estropeen al escribir en el archivo.