Peut-être pousserez-vous du code qui finira par casser un cache qui fournit des données à des millions de personnes,
Peut-être mettrez-vous à jour une application et finirez-vous par anéantir des informations qui ne sont pas sauvegardées,
Ou peut-être pousserez-vous un changement qui « fonctionne sur votre machine » mais monopolisera complètement le référentiel de contrôle des sources.

Et il y a plein d’autres exemples. Je suis sûr que vous pouvez rapidement en nommer cinq autres vous-même.

J’ai commis (jeu de mots, en quelque sorte) ma juste part de tout ce qui précède, mais l’une des choses que je vois des personnes travaillant dans notre espace.

Autrement dit, ceux qui travaillent avec des applications Web basées sur une base de données – est le manque de compréhension de l’organisation de la base de données au niveau du système de fichiers et comment il est possible de reconstruire des données même lorsque vous n’avez pas de sauvegarde standard sur laquelle travailler.

Dans cet article, je vais approfondir l’organisation de la base de données MySQL au niveau du système de fichiers, comment vous pouvez restaurer des informations à partir de cela par rapport à un fichier de sauvegarde si vous vous trouvez dans cette situation, et fournir des références (ou des signets) si vous en avez besoin.

Reconstruction de données MySQL

Pour être clair, je vais parler d’une base de données MySQL exécutée sur une variante d’un système d’exploitation basé sur * nix (vous envisagez donc une distribution Linux ou macOS).

Les emplacements des fichiers (que je couvrirai momentanément) varieront sur un système Windows, mais vous devrez vous référer au manuel MySQL ou à une ressource similaire pour les trouver.

Le point est le suivant : avant d’aller trop loin dans cet article, sachez où se trouvent les fichiers sur votre système d’exploitation. Par exemple, si vous utilisez macOS et que vous le trouverez probablement dans /usr/local/mysql/data.

Je préfère utiliser Homebrew pour que mes bases de données MySQL soient dans /usr/local/var/mysql . Et comme vous pouvez le voir ci-dessus, vous remarquerez des fichiers qui ont le même nom que les bases de données que vous avez sur votre système .

Comment les bases de données sont organisées

Au niveau de la surface, cela semble assez simple. Mais si vous devez ouvrir le répertoire comme mentionné ci-dessus, vous constaterez qu’une grande partie de ce que vous voyez sont des répertoires – pas des fichiers en soi – qui contiennent plus d’informations.

Si vous explorez l’un des répertoires, vous verrez une variété de fichiers :

Ceux-ci incluent des fichiers qui incluent les types suivants :

MONDE
MON JE
FRM
MICI

Et chacun de ces types de fichiers existe pour chaque table de la base de données.

Examinons-les plus en profondeur pour mieux comprendre en quoi consiste exactement une base de données.

1 La base de données est un ensemble de fichiers

D’une manière générale, la plupart d’entre nous savent que MySQL est une base de données relationnelle et que chaque base de données consiste en un ensemble de tables qui stockent toutes différents types d’informations (et de nombreuses tables sont liées les unes aux autres d’une manière ou d’une autre même s’il ne s’agit que d’une valeur dans un seule colonne).

Mais cet article ne traite pas de l’aspect relationnel de la base de données ni de la manière dont nous pouvons exécuter des requêtes sur celle-ci. (Si vous êtes intéressé, allez-y – tout est basé sur le calcul des tuples .)

Au lieu de cela, il s’agit de comprendre que pour chaque table, il existe un ensemble de fichiers qui référencent les informations contenues dans chaque table. Et

2 Comprendre les types de fichiers

Étant donné que chaque table d’une base de données est composée des types de fichiers ci-dessus, examinons le type de fichier individuel, puis déterminons le rôle qu’il joue pour chaque table (et finalement comment cela est pris en compte dans l’ensemble de la base de données).

MYD. Ce fichier contient les données stockées dans les lignes de la table de la base de données. Ce fichier est étroitement lié au fichier FRM.
FRM. Ce fichier contient les données de format de table (qui incluent des éléments tels que la manière dont chaque colonne de la base de données est censée être structurée, le type de données qu’elle contient, etc.).
MYI. Il s’agit de l’index de la base de données. Si vous utilisez une base de données MyISAM (que la plupart d’entre nous utilisent actuellement InnoDB), vous aurez ce fichier. En outre, les données comprennent des informations indiquant si oui ou non les données ont été correctement fermées. Considérez ceci comme un fichier sur l’intégrité de la table elle-même. Pas les informations qu’il contient, pas le format de celui-ci.
MII. Il s’agit d’un type de fichier associé aux tables de base de données InnoDB (vous ne le verrez donc peut-être pas dans le répertoire de votre base de données). Si vous le faites, cependant, il est important de savoir que les bases de données basées sur InnoDB stockeront des informations sur chaque table de ce fichier.

Dans les informations ci-dessus, il y a deux autres sujets qui méritent d’être explorés.

MonISAM
InnoDB

Avant d’examiner chacun d’entre eux, notez que MyISAM et InnoDB sont ce que l’on appelle des moteurs de stockage. Cela semble fantaisiste, mais cela a à voir avec la façon dont le logiciel de base de données gère les opérations de création, de lecture, de mise à jour et de suppression des informations.

MyISAM & InnoDB : Quelle est la différence ?

Chacun de ces moteurs de stockage diffère dans la manière dont il traite les transactions, le verrouillage, les restaurations et les recherches. Pour ceux qui sont administrateurs de base de données, vous connaissez tout ce qui précède (mais vous ne lisez probablement pas non plus ceci 🙃).

Pas ce type de moteur, bien sûr.

Pour le reste d’entre nous, voici ce que nous avons :

Les transactions se produisent chaque fois qu’au moins deux instructions telles que SELECT et UPDATE ou INSERT et DELETE ou toute combinaison des deux (ou plus) sont utilisées conjointement l’une avec l’autre. Donc, si vous deviez SÉLECTIONNER des informations puis SUPPRIMER les résultats, vous auriez une transaction.
- MyISAM ne prend pas en charge les transactions. Cela signifie que si une « transaction » est interrompue, toutes les données qui étaient en cours de traitement pendant l’opération sont affectées. Inutile de dire que cela n’est pas utilisé.
- InnoDB, d’autre part, garantit que les modifications ne seront pas apportées à la table tant que la transaction ne sera pas terminée. En d’autres termes, les modifications ne seront pas validées dans la base de données.
Pour chacun des moteurs de stockage, le verrouillage varie au niveau de la table ou au niveau de la ligne. Chaque fois que vous exécutez une requête sur une table, MyISAM verrouille toute la table jusqu’à ce que le processus soit terminé. InnoDB, d’autre part, ne verrouille que les lignes qui sont affectées. Il s’agit d’une distinction importante car cela signifie que vous pouvez continuer à opérer sur une table, mais pas sur les mêmes lignes, chaque fois que vous utilisez InnoDB.
Les restaurations ne sont pas possibles dans MyISAM. Cela signifie qu’une fois qu’un changement est effectué, c’est fait. InnoDB propose des restaurations. Supposons donc que vous apportiez une modification à la table, que vous ayez accidentellement fait quelque chose que vous ne vouliez pas faire, puis vous pouvez la restaurer à son état précédent. Cela ne doit pas être confondu avec une sauvegarde, cependant. C’est plus comme une opération "annuler" pour une transaction.
La recherche, en particulier dans la manière dont nous structurons nos bases de données, est essentielle dans la manière dont nous organisons les données dans nos bases de données. En termes simples, InnoDB prend en charge l’indexation FULLTEXT (à partir de MySQL 5.6.4). Mais si votre hébergeur ou votre fournisseur n’autorise pas les index FULLTEXT, je dirais que ce n’est pas un dealbreaker.

Compte tenu de toutes les informations ci-dessus, il appartient à chacun de voir que les avantages du moteur de stockage InnoDB l’emportent largement sur ceux du moteur de stockage MyISAM, surtout si vous êtes au-dessus d’utiliser une version de MySQL au moins égale à 5.6.4

3 Recréer la base de données

À ce stade, supposons que vous savez que vous avez accès aux fichiers qui composent la base de données à partir du système d’exploitation.

Il s’agit peut-être d’une sauvegarde précédente, peut-être pouvez-vous localiser les fichiers sur le disque, ou peut-être pouvez-vous les récupérer d’une autre manière – et vous devez restaurer la base de données à un point antérieur.

1 Ne le faites pas en production

Avant de faire quoi que ce soit, configurez une base de données vide sur votre ordinateur local, puis travaillez pour importer les informations. Mais, encore une fois, ce n’est pas comme simplement utiliser une interface de base de données pour importer un fichier SQL.

Au lieu de cela, créez un répertoire qui correspond au nom de la base de données que vous souhaitez créer. Dans cet article, j’utiliserai l’exemple de trunkdev (car c’est là que je travaille avec la version la plus récente de WordPress trunk ).

2 Sauvegardez la base de données existante

Ensuite, sauvegardez autant que possible la base de données existante, que ce soit en utilisant une base de données frontale ou une copie des fichiers. Après cela, copiez les fichiers de l’emplacement source dans le répertoire que vous avez créé.

Vous devriez, à ce stade, être en mesure de charger l’interface de base de données de votre choix et de voir les informations contenues dans les fichiers de base de données que vous venez de copier. Cela dépend du fait que les fichiers ne sont pas corrompus et que le serveur de base de données fonctionne.

3 N’installez pas d’autres logiciels

Notez que, à ce stade, je n’essaierais pas d’installer d’autres logiciels dessus comme WordPress ou toute autre information. Au lieu de cela, travaillez directement avec les données. En supposant qu’il soit visible dans votre interface, effectuez une sauvegarde ou une exportation appropriée du fichier dans un fichier SQL afin de pouvoir restaurer plus facilement les informations à l’avenir.

Certains frontaux vous donneront la possibilité d’exporter uniquement certaines tables. Dans ce cas, sauvegardez tout. Pour certaines bases de données, cela prendra beaucoup de temps ; Pour d’autres, pas tellement. Tout dépend de la taille du projet.

4 Travailler avec les données

À ce stade, vous devriez pouvoir commencer à manipuler la base de données à l’aide du frontal ou de SQL. Si vous n’êtes pas à l’aise ou même sûr de savoir comment procéder, parlez-en à quelqu’un qui l’est, car cela peut être quelque chose d’incroyablement sensible (après tout, vous avez affaire à la reconstruction d’une base de données à partir de fichiers, n’est-ce pas ?)

Une fois que vous pensez que vous avez les informations dans un endroit prêt à être restauré vers n’importe quelle application, des informations perdues, des informations corrompues ou simplement des données mal formées, il est temps de vous préparer à prendre les informations de votre ordinateur local et de les renvoyer au la source.

Retour à la source

Tout d’abord, il est recommandé de faire tout ce qui précède pendant les périodes de faible trafic, alors assurez-vous que chaque fois que vous faites cela, vous ne le ferez pas pendant les heures de pointe. Ça va sans dire.

Ensuite, effectuez une sauvegarde de la base de données avant de commencer à l’utiliser. Enregistrez le fichier dans un emplacement que vous pouvez facilement rappeler et auquel vous pouvez facilement accéder afin que si quelque chose ne va pas avec l’utilisation des informations que vous êtes sur le point d’importer, vous êtes couvert et restaurez simplement ce qui était déjà là. Pour être clair, exportez toute la base de données au format SQL.

Maintenant, prenez la base de données que vous avez sur votre ordinateur local et exportez également ces informations dans un fichier SQL. Ouvrez le fichier exporté et assurez-vous qu’il utilise une instruction CREATE pour créer la base de données avec le nom correct et les tables avec les noms corrects également.

En supposant que tout se passe bien, tout ce que vous avez importé sera restauré exactement comme il se doit et comme vous le voyez sur votre appareil local. Si vous ne le voyez pas, importez le fichier que vous avez exporté précédemment ; sinon, vous êtes prêt à partir.

Et si ça ne marche pas ?

Si cela ne fonctionne pas, vous devrez vous attaquer à la racine du problème :

Cela n’a-t-il pas fonctionné à cause d’un problème avec les fichiers du serveur ?
Cela n’a-t-il pas fonctionné à cause du type de base de données que vous avez créé sur votre ordinateur local ?
Utilisez-vous le même moteur de stockage ? Vous devriez l’être puisque cela vient des fichiers.
L’intégrité de la base de données est-elle solide localement ?
La base de données sur le serveur est-elle supprimée avant d’importer les données de votre ordinateur local ?

Si cela ne fonctionne pas à ce stade, ce sera généralement à cause de quelque chose comme ce qui est ci-dessus. Cependant, il pourrait s’agir d’autre chose. J’ai fait ce que je pouvais pour fournir autant d’informations que possible sur les bases de données MySQL, leur structure et les étapes nécessaires pour reconstruire la base de données à partir de fichiers, mais je ne peux pas capturer tous les cas potentiels.

Sauvegardez toujours les données (et ne supposez pas que cela est fait)

Cela dit, j’espère que toutes les informations ci-dessus vous permettront de mieux comprendre ce qui se cache sous WordPress si vous rencontrez ce problème seul ou avec un client.

Et, enfin, toujours sauvegarder. Faites des sauvegardes manuelles, faites des sauvegardes automatiques et faites-les fréquemment. Ne le limitez pas non plus à la base de données. Sauvegardez la base de données, l’application et tout ce qui est nécessaire pour alimenter la solution.

Si vous le faites, vous n’aurez pas à vous soucier de tout ce qui précède.

Source d’enregistrement: tommcfarlin.com