Tal vez envíe un código que termine rompiendo un caché que sirve datos a millones de personas,
Tal vez actualice una aplicación y termine eliminando información de la que no se ha hecho una copia de seguridad,
O tal vez impulsará un cambio que "funciona en su máquina" pero que limpia completamente el repositorio de control de código fuente.

Y hay muchos otros ejemplos. Estoy seguro de que usted mismo puede nombrar rápidamente cinco más.

He cometido (juego de palabras, más o menos) mi parte justa de todo lo anterior, pero una de las cosas que veo de las personas que trabajan en nuestro espacio.

Es decir, aquellos que trabajan con aplicaciones web respaldadas por bases de datos, es la falta de comprensión de la organización de la base de datos a nivel del sistema de archivos y cómo es posible reconstruir datos incluso cuando no tiene una copia de seguridad estándar con la que trabajar.

En esta publicación, voy a profundizar en la organización de la base de datos MySQL a nivel del sistema de archivos, cómo puede restaurar la información de eso en comparación con un archivo de respaldo en caso de que se encuentre en esa situación, y proporcionar referencias (o marcadores) debe Los necesitas.

Reconstrucción de datos MySQL

Para ser claros, voy a estar hablando de una base de datos MySQL que se ejecuta en una variante de un sistema operativo basado en *nix (por lo que está viendo una distribución de Linux o macOS).

Las ubicaciones de los archivos (que cubriré momentáneamente) variarán en un sistema basado en Windows, pero deberá consultar el manual de MySQL o un recurso similar para encontrarlos.

El punto es: antes de profundizar demasiado en este artículo, sepa dónde residen los archivos en su sistema operativo. Por ejemplo, si está ejecutando macOS y es probable que lo encuentre en /usr/local/mysql/data.

Prefiero usar Homebrew para que mis bases de datos MySQL estén en /usr/local/var/mysql . Y como puede ver arriba, notará archivos que tienen el mismo nombre que las bases de datos que tiene en su sistema .

Cómo se organizan las bases de datos

A nivel superficial, parece bastante simple. Pero si va a abrir el directorio como se mencionó anteriormente, encontrará que gran parte de lo que ve son directorios, no archivos per se, que albergan más información.

Si profundiza en uno de los directorios, verá una variedad de archivos:

Estos incluyen archivos que incluyen los siguientes tipos:

MUNDO
MI YO
FRM
EII

Y cada uno de estos tipos de archivos existe para cada tabla en la base de datos.

Entonces, analicemos estos más en profundidad para obtener una mejor comprensión de en qué consiste exactamente una base de datos.

1 La base de datos es un conjunto de archivos

En términos generales, la mayoría de nosotros sabemos que MySQL es una base de datos relacional y que cada base de datos consta de un conjunto de tablas, todas las cuales almacenan diferentes tipos de información (y muchas tablas están relacionadas entre sí de alguna manera, incluso si es solo un valor en un una sola columna).

Pero esta publicación no trata sobre el aspecto relacional de la base de datos ni sobre cómo podemos ejecutar consultas en ella. (Si está interesado, hágalo: todo se basa en el cálculo de tuplas ).

En cambio, se trata de comprender que para cada tabla hay un conjunto de archivos que hacen referencia a la información contenida en cada tabla. Y

2 Comprender los tipos de archivos

Dado que cada tabla en una base de datos se compone de los tipos de archivos anteriores, veamos el tipo de archivo individual y luego determinemos el papel que desempeña para cada tabla (y, en última instancia, cómo esto influye en toda la base de datos).

MYD _ Este archivo contiene los datos que se almacenan en las filas de la tabla de la base de datos. Este archivo está estrechamente relacionado con el archivo FRM.
FRM. Este archivo contiene los datos del formato de la tabla (que incluye cosas como la estructura de cada columna de la base de datos, el tipo de datos que contiene, etc.).
MYI. Este es el índice de la base de datos. Si está utilizando una base de datos MyISAM (que la mayoría de nosotros usamos InnoDB en este momento), tendrá este archivo. Además, los datos incluyen información sobre si los datos se han cerrado correctamente o no. Considere esto como un archivo sobre la integridad de la tabla en sí. No la información dentro de él, no el formato de la misma.
EII. Este es un tipo de archivo que está asociado con las tablas de la base de datos InnoDB (por lo que es posible que no lo vea en el directorio de su base de datos). Sin embargo, si lo hace, es importante saber que las bases de datos basadas en InnoDB almacenarán información sobre cada tabla en este archivo.

En la información anterior, hay otros dos temas que vale la pena explorar.

MiISAM
InnoDB

Antes de ver cada uno de estos, tenga en cuenta que MyISAM e InnoDB son lo que se conoce como motores de almacenamiento. Suena elegante, pero tiene que ver con la forma en que el software de la base de datos administra las operaciones de creación, lectura, actualización y eliminación de información.

MyISAM e InnoDB: ¿Cuál es la diferencia?

Cada uno de estos motores de almacenamiento difiere en la forma en que maneja las transacciones, el bloqueo, las reversiones y las búsquedas. Para aquellos que son administradores de bases de datos, están familiarizados con todo lo anterior (pero también es probable que no estén leyendo esto 🙃).

No este tipo de motor, por supuesto.

Para el resto de nosotros, esto es lo que tenemos:

Las transacciones ocurren siempre que al menos dos declaraciones como SELECCIONAR y ACTUALIZAR o INSERTAR y ELIMINAR o cualquier combinación de las dos (o más) se usan en conjunto. Entonces, si tuviera que SELECCIONAR información y luego ELIMINAR los resultados, tendría una transacción.
- MyISAM no admite transacciones. Esto significa que si una «transacción" se interrumpe entonces, cualquier dato que se estaba procesando durante la operación se ve afectado. No hace falta decir que esto no se usa.
- InnoDB, por otro lado, garantiza que los cambios no se realizarán en la tabla hasta que se complete la transacción. En otras palabras, los cambios no se confirmarán en la base de datos.
Para cada uno de los motores de almacenamiento, el bloqueo varía a nivel de tabla o de fila. Siempre que esté ejecutando una consulta en una tabla, MyISAM bloqueará toda la tabla hasta que se complete el proceso. InnoDB, por otro lado, solo bloqueará las filas que se vean afectadas. Esta es una distinción importante porque significa que puede continuar operando en una tabla, pero no en las mismas filas, siempre que esté usando InnoDB.
Las reversiones no son posibles en MyISAM. Esto significa que una vez que se realiza un cambio, ya está hecho. InnoDB ofrece reversiones. Entonces, digamos que hace un cambio en la tabla, accidentalmente hizo algo que no tenía intención de hacer, luego puede revertirlo a su estado anterior. Sin embargo, esto no debe confundirse con una copia de seguridad. Es más como una operación de "deshacer" para una transacción.
La búsqueda, especialmente en la forma en que estructuramos nuestras bases de datos, es clave en la forma en que organizamos los datos en nuestras bases de datos. En pocas palabras, InnoDB admite la indexación de TEXTO COMPLETO (a partir de MySQL 5.6.4). Pero si su host o proveedor no permite índices de TEXTO COMPLETO, diría que no es un factor decisivo.

Dada toda la información anterior, cada uno debe ver que las ventajas del motor de almacenamiento InnoDB superan con creces las del motor de almacenamiento MyISAM, especialmente si está arriba para usar una versión de MySQL que es al menos igual a 5.6.4

3 Recreando la base de datos

En este punto, supongamos que sabe que tiene acceso a los archivos que componen la base de datos del sistema operativo.

Tal vez sea una copia de seguridad anterior, tal vez pueda ubicar los archivos en el disco, o tal vez pueda recuperarlos de alguna otra manera, y necesita restaurar la base de datos a un punto anterior.

1 No lo hagas en producción

Antes de hacer nada, configure una base de datos vacía en su máquina local y luego trabaje para importar la información. Pero, de nuevo, esto no es como simplemente usar una interfaz de base de datos para importar un archivo SQL.

En su lugar, cree un directorio que coincida con el nombre de la base de datos que desea crear. En esta publicación, usaré el ejemplo de trunkdev (ya que aquí es donde trabajo usando la versión más reciente de WordPress trunk ).

2 Copia de seguridad de la base de datos existente

A continuación, haga una copia de seguridad de la base de datos existente tanto como sea posible, ya sea utilizando una interfaz de base de datos o una copia de los archivos. Después de eso, copie los archivos desde la ubicación de origen al directorio que creó.

En este punto, debería poder cargar el front-end de su base de datos de su elección y ver la información contenida en los archivos de la base de datos que acaba de copiar. Esto depende de que los archivos no estén dañados y el servidor de la base de datos se esté ejecutando.

3 No instale otro software

Tenga en cuenta que, en este punto, no intentaría instalar otro software como WordPress o cualquier otra información. En su lugar, trabaje directamente con los datos. Suponiendo que esté visible en su front-end, haga una copia de seguridad adecuada o exporte el archivo a un archivo SQL para que pueda restaurar la información más fácilmente en el futuro.

Algunas interfaces le darán la posibilidad de exportar solo ciertas tablas. En este caso, haga una copia de seguridad de todo. Para algunas bases de datos, esto llevará mucho tiempo; Para otros, no tanto. Todo depende del tamaño del proyecto.

4 Trabajar con los datos

En este punto, debería poder comenzar a manipular la base de datos utilizando el front-end o SQL. Si no se siente cómodo o no está seguro de cómo hacer esto, entonces hable con alguien que lo esté, ya que esto puede ser algo increíblemente sensible (después de todo, está lidiando con la reconstrucción de una base de datos a partir de archivos, ¿verdad?)

Una vez que crea que tiene la información en un lugar que está listo para ser restaurado a cualquier aplicación que haya perdido información, dañado información o simplemente tenga datos mal formados, entonces es hora de prepararse para tomar la información de su máquina local y enviarla de regreso al fuente.

Volver a la fuente

Primero, se recomienda hacer todo lo anterior durante las horas de poco tráfico, así que asegúrese de que cada vez que haga esto, no lo haga durante las horas pico de trabajo. Esto debería ser evidente.

A continuación, realice una copia de seguridad de la base de datos antes de comenzar a operar en ella. Guarde el archivo en una ubicación que pueda recuperar y acceder fácilmente para que, si algo sale mal con el uso de la información que está a punto de importar, esté cubierto y simplemente restaure lo que ya estaba allí. Para que quede claro, exporte toda la base de datos en formato SQL.

Ahora tome la base de datos que tiene en su máquina local y exporte esa información a un archivo SQL también. Abra el archivo exportado y asegúrese de que esté usando una instrucción CREAR para crear la base de datos con el nombre correcto y las tablas también con los nombres correctos.

Suponiendo que todo vaya bien, todo lo que hayas importado se restaurará exactamente como debería ser y como lo ves en tu dispositivo local. Si no ve eso, importe el archivo que exportó anteriormente; de lo contrario, estás listo para irte.

¿Qué pasa si no funciona?

Si no funciona, tendrá que llegar a la raíz del problema:

¿No funcionó por algún problema con los archivos del servidor?
¿No funcionó debido al tipo de base de datos que creó en su máquina local?
¿Está utilizando el mismo motor de almacenamiento? Deberías serlo ya que proviene de los archivos.
¿La integridad de la base de datos es sólida localmente?
¿Se está eliminando la base de datos en el servidor antes de importar los datos de su máquina local?

Si no funciona en este punto, generalmente se debe a algo como lo que está arriba. Sin embargo, podría ser otra cosa. Hice lo que pude para proporcionar la mayor cantidad de información posible sobre las bases de datos MySQL, cómo están estructuradas y los pasos necesarios para reconstruir la base de datos a partir de archivos, pero no puedo capturar todos los casos potenciales.

Siempre haga una copia de seguridad de los datos (y no asuma que se está haciendo)

Dicho esto, espero que toda la información anterior brinde una comprensión más profunda de lo que hay debajo de WordPress en caso de que enfrente este problema por su cuenta o con un cliente.

Y, por último, siempre copia de seguridad. Realice copias de seguridad manuales, realice copias de seguridad automáticas y hágalas con frecuencia. Tampoco lo limite a la base de datos. Haga una copia de seguridad de la base de datos, la aplicación y cualquier otra cosa que sea necesaria para impulsar la solución.

Si lo hace, entonces no tendrá que preocuparse por todo lo anterior.

Fuente de grabación: tommcfarlin.com