Cómo recuperar una mesa innodb cuyos archivos se movieron

Question

Así que tengo un servidor DB de prueba que se configuró en un flujo de replicación. Sobre el nombre se produjo una optimización que rápidamente llenó el espacio en los esclavos Datadir. MySQL obedientemente solo estaba esperando más espacio.

Este DataDir es un sistema de archivos utilizado solo como DataDir de MySQL, por lo que no había nada más que liberar.

Tenía una mesa de pruebas de 4 gigos innodb que no era parte de la corriente de replicación, así que pensé que intentaría algo para ver si funcionaba, y al ser un entorno de prueba no estaba demasiado preocupado si las cosas salían terriblemente mal.

Aquí están los pasos que tomé

1. Enjugué la mesa que estaba a punto de mover
2. Colocó un bloqueo de lectura (aunque nada le estaba escribiendo y no estaba en el flujo de replicación)
3. Copió el .FRM y .IBD a un sistema de archivos con una habitación libre
4. Desbloqueado la mesa
5. Trunció esa tabla: esto liberó suficiente espacio para que la optimización finalice que la replicación comience a seguir adelante.
6. Deja de esclavizar/apagar mysql
7. Copie el archivo fuera de TMP nuevamente al Dir de datos
8. Reiniciar mysql

Nada aparece en el registro .err, las cosas se ven bien. Me conecto y uso mydb; Y vea la mesa con la que estaba jugando en las mesas de exhibición. Pero, si lo intento

select * from testtable limit 10;

Recibo el error

ERROR 1146 (42S02): Table 'mydb.testtable' doesn't exist

Por lo que puedo decir hasta ahora puedo leer de todas las otras tablas bien y la replicación comenzó sin ninguna queja.

¿Hay algo que pueda hacer para recuperarme de este punto? Puedo reconstruirlo desde cero si es necesario, pero tenía curiosidad por saber lo que otros pensaban sobre esta empresa en general. ¿Hubo algo sobre la serie de pasos que tomé que habrían terminado con más resultados impecables?

¿Qué pasaría si este no fuera un servidor de prueba, no podría "hacerlo en vivo" y ver qué sucede? ¿Qué tendría la mejor manera de liberar espacio temporalmente en un esclavo de producción si tuviera que gustarme eso?

Answer 1

Lo más importante que la mayoría de la gente olvida de la mesa truncada es que La mesa truncada es DDL y no DML. En InnoDB, los metadatos dentro de IBDATA1 contienen una lista numerada de tablas innoDB. El uso de la tabla Truncate hace que la identificación de metadatos internos de la tabla innoDB cambie. Esto sucede porque Truncate Table efectivamente hace lo siguiente:

Ejemplo: truncar una mesa innodb llamada mydb.mytb

USE mydb
CREATE TABLE newtb LIKE mytb;
ALTER TABLE mytb RENAME oldtb;
ALTER TABLE newtb RENAME mytb;
DROP TABLE oldtb;

El nuevo MYTB tendría una identificación de metadatos internos diferentes.

Cuando copió el archivo .ibd a otro lugar, el .IBD contiene dentro de la identificación de metadatos internos originales. Simplemente poner el archivo .ibd de vuelta no causa una reconciliación de la ID de metadatos internos con la de la de IBDATA1.

Lo que deberías haber hecho es esto:

Copie el archivo .ibd de la tabla innodb. Entonces, ejecuta esto

ALTER TABLE tablename DISCARD TABLESPACE;

Para volver a traerlo más tarde, copie el archivo .ibd de nuevo en Datadir y luego ejecute

ALTER TABLE tablename IMPORT TABLESPACE;

Esto habría conservado la identificación de metadatos internos.

Asegúrese de que .FRM siempre esté presente.

Una vez ayudé a un cliente a restaurar 30 mesas innoDB que manejó de la misma manera. Tuve que usar otro servidor de DB y jugar algunos juegos con agregar y soltar tablas innoDB para buscar la identificación de metadatos internos correctos.

El cliente encontró este artículo: http://www.chriscalender.com/?tag=innodb-error-tablespace-id-in-file . Lo usamos y ayudó mucho. Espero que te ayude.

Answer 2

Experimenté con mi Mac, antes de vender a un amigo, simplemente copie la carpeta XAMPP solo a mi disco duro. (No es el éxito) Desafortunadamente, me trajo problemas, porque probé los siguientes pasos: Instalo XAMPP fresco y copio todo el httdocs y var mysql a mi nueva Mac, esos DB solo con .FRM y .IBD,, No funciona, todavía no puedo acceder a las tablas dentro de PhPMyAdmin ... - Traté de instalar la misma versión de XAMPP y repetir los pasos anteriores, todavía no funciona. - Decidí ir a la cama.

(Éxito) - Esta mañana, traje mi disco de respaldo y lo intenté con Windows 7. - Instale el último XAMPP nuevo para Windows, C: XAMPP - Tengo uno de sitios web (carpeta) desde mi copia de seguridad de mi copia de seguridad y corresponde a la carpeta de base de datos dentro var mysql están listos en mi Windows 7, solo quiero probar con un sitio web y luego probar el resto porque tengo muchos proyectos dentro de httdocs y var mysql - copio la carpeta httdocs a windows c: xampp httdocs y copiar el var mysql a c: xampp mysql data

Aún no ha pasado el último todavía, IB_LOGFILE0, IB_LOGFILE1, IBDATA1 de mi archivo de copia de seguridad a Windows XAMPP C: XAMPP MYSQL DATA

Refresco el http: // localhost/mywebsite

Wow wow hecho ... está funcionando ...