Talvez você envie um código que acabe quebrando um cache que fornece dados para milhões de pessoas,
Talvez você atualize um aplicativo e acabe eliminando informações sem backup,
Ou talvez você empurre uma mudança que “funcione em sua máquina", mas enxugue completamente o repositório de controle de origem.

E há muitos outros exemplos. Tenho certeza que você pode nomear mais cinco rapidamente.

Eu cometi (trocadilhos, mais ou menos) meu quinhão de todos os itens acima, mas uma das coisas que vejo nas pessoas que trabalham em nosso espaço.

Ou seja, aqueles que trabalham com aplicativos da Web baseados em banco de dados – é a falta de compreensão da organização do banco de dados no nível do sistema de arquivos e como é possível reconstruir os dados mesmo quando você não tem um backup padrão do qual trabalhar.

Neste post, vou me aprofundar na organização do banco de dados MySQL no nível do sistema de arquivos, como você pode restaurar informações a partir dele versus um arquivo de backup, caso se encontre nessa situação, e fornecer referências (ou marcadores) você precisa deles.

Reconstrução de dados MySQL

Para ser claro, vou falar sobre um banco de dados MySQL rodando em uma variante de um sistema operacional baseado em *nix (então você está olhando para uma distribuição de Linux ou macOS).

As localizações dos arquivos (que abordarei momentaneamente) variam em um sistema baseado em Windows, mas você terá que consultar o manual do MySQL ou um recurso semelhante para encontrá-los.

O ponto é: antes de ir muito longe neste artigo, saiba onde os arquivos residem em seu sistema operacional. Por exemplo, se você estiver executando o macOS e provavelmente o encontrará em /usr/local/mysql/data.

Eu prefiro usar o Homebrew para que meus bancos de dados MySQL estejam em /usr/local/var/mysql . E como você pode ver acima, você notará arquivos que têm o mesmo nome dos bancos de dados que você tem em seu sistema .

Como os bancos de dados são organizados

No nível da superfície, parece bastante simples. Mas se você abrir o diretório como mencionado acima, você verá que muito do que você vê são diretórios – não arquivos, em si – que contêm mais informações.

Se você detalhar um dos diretórios, verá uma variedade de arquivos:

Isso inclui arquivos que incluem os seguintes tipos:

MUNDO
MYI
FRM
DII

E cada um desses tipos de arquivos existe para cada tabela no banco de dados.

Então, vamos ver isso mais a fundo para entender melhor exatamente em que consiste um banco de dados.

1 O banco de dados é um conjunto de arquivos

De um modo geral, a maioria de nós sabe que o MySQL é um banco de dados relacional e cada banco de dados consiste em um conjunto de tabelas que armazenam diferentes tipos de informações (e muitas tabelas estão relacionadas umas às outras de alguma forma, mesmo que seja apenas um valor em um coluna única).

Mas este post não é sobre o aspecto relacional do banco de dados nem sobre como podemos executar consultas nele. (Se você estiver interessado, experimente – é tudo baseado em cálculo de tuplas .)

Em vez disso, trata-se de entender que, para cada tabela, há um conjunto de arquivos que fazem referência às informações contidas em cada tabela. E

2 Entendendo os tipos de arquivo

Como cada tabela em um banco de dados é composta pelos tipos de arquivo acima, vamos examinar o tipo de arquivo individual e, em seguida, determinar a função que ele desempenha para cada tabela (e, finalmente, como isso afeta todo o banco de dados).

MYD. Este arquivo contém os dados armazenados nas linhas da tabela do banco de dados. Este arquivo está intimamente relacionado ao arquivo FRM.
FRM. Este arquivo contém os dados de formato de tabela (que inclui coisas como como cada coluna do banco de dados deve ser estruturada, o tipo de dados que contém e assim por diante).
MEU. Este é o índice do banco de dados. Se você estiver usando um banco de dados MyISAM (que a maioria de nós está usando InnoDB neste momento), você terá este arquivo. Além disso, os dados incluem informações sobre se os dados foram ou não fechados corretamente. Considere isso como um arquivo sobre a integridade da própria tabela. Não a informação dentro dele, não o formato dele.
DII. Este é um tipo de arquivo associado às tabelas do banco de dados InnoDB (portanto, você pode não ver isso no diretório do seu banco de dados). Se você fizer isso, no entanto, é importante saber que os bancos de dados baseados em InnoDB armazenarão informações sobre cada tabela neste arquivo.

Nas informações acima, há dois outros tópicos que vale a pena explorar.

MyISAM
InnoDB

Antes de examinar cada um deles, observe que MyISAM e InnoDB são chamados de mecanismos de armazenamento. Parece extravagante, mas tem a ver com a forma como o software de banco de dados gerencia as operações de criação, leitura, atualização e exclusão de informações.

MyISAM & InnoDB: Qual é a diferença?

Cada um desses mecanismos de armazenamento difere em como lidam com transações, bloqueios, reversões e pesquisas. Para aqueles que são administradores de banco de dados, você está familiarizado com todos os itens acima (mas provavelmente também não está lendo isso 🙃).

Não este tipo de motor, é claro.

Para o resto de nós, isso é o que temos:

As transações ocorrem sempre que pelo menos duas instruções como SELECT e UPDATE ou INSERT e DELETE ou qualquer combinação das duas (ou mais) são usadas em conjunto. Então, se você SELECIONAR informações e DELETAR os resultados, você terá uma transação.
- MyISAM não suporta transações. Isso significa que, se uma “transação” for interrompida, todos os dados que estavam sendo processados durante a operação serão afetados. É necessário dizer que isso não é usado.
- O InnoDB, por outro lado, garante que as alterações não serão feitas na tabela até que a transação seja concluída. Em outras palavras, as alterações não serão confirmadas no banco de dados.
Para cada um dos mecanismos de armazenamento, o bloqueio varia no nível da tabela ou da linha. Sempre que você estiver executando uma consulta em uma tabela, o MyISAM bloqueará a tabela inteira até que o processo seja concluído. O InnoDB, por outro lado, bloqueará apenas as linhas que estão sendo afetadas. Esta é uma distinção importante porque significa que você pode continuar operando em uma tabela, mas não nas mesmas linhas, sempre que estiver usando o InnoDB.
Rollbacks não são possíveis no MyISAM. Isso significa que uma vez que uma mudança é feita, ela está feita. O InnoDB oferece rollbacks. Então, digamos que você faça uma alteração na tabela, você acidentalmente fez algo que não pretendia fazer, então você pode reverter para seu estado anterior. Isso não deve ser confundido com um backup, no entanto. É mais como uma operação de “desfazer” para uma transação.
A pesquisa, especialmente na forma como estruturamos nossos bancos de dados, é fundamental na forma como organizamos os dados em nossos bancos de dados. Simplificando, o InnoDB suporta indexação FULLTEXT (a partir do MySQL 5.6.4). Mas se o seu host ou provedor não permitir índices FULLTEXT, eu diria que não é um problema.

Dadas todas as informações acima, cabe a cada um ver que as vantagens do mecanismo de armazenamento InnoDB superam em muito as do mecanismo de armazenamento MyISAM, especialmente se você estiver acima para usar uma versão do MySQL que seja pelo menos igual a 5.6.4

3 Recriando o banco de dados

Neste ponto, vamos supor que você saiba que tem acesso aos arquivos que compõem o banco de dados do sistema operacional.

Talvez seja um backup anterior, talvez você consiga localizar os arquivos no disco, ou talvez consiga recuperá-los de alguma outra forma – e você precisa restaurar o banco de dados para um ponto anterior.

1 Não faça isso na produção

Antes de fazer qualquer coisa, configure um banco de dados vazio em sua máquina local e trabalhe para importar as informações. Mas, novamente, isso não é como simplesmente usar um front-end de banco de dados para importar um arquivo SQL.

Em vez disso, crie um diretório que corresponda ao nome do banco de dados que você deseja criar. Neste post, usarei o exemplo do trunkdev (já que é aqui que trabalho usando a versão mais recente do WordPress trunk ).

2 Backup do banco de dados existente

Em seguida, faça o backup do banco de dados existente o máximo possível – seja usando um front-end de banco de dados ou uma cópia dos arquivos. Depois disso, copie os arquivos do local de origem para o diretório que você criou.

Você deve, neste ponto, ser capaz de carregar o front-end de banco de dados de sua escolha e ver as informações contidas nos arquivos de banco de dados que você acabou de copiar. Isso depende dos arquivos não estarem corrompidos e do servidor de banco de dados em execução.

3 Não instale outro software

Observe que, neste momento, eu não tentaria instalar outro software nele como o WordPress ou qualquer outra informação. Em vez disso, trabalhe diretamente com os dados. Supondo que esteja visível em seu front-end, faça um backup adequado ou exporte o arquivo para um arquivo SQL para que você possa restaurar as informações com mais facilidade no futuro.

Alguns front-ends permitem exportar apenas determinadas tabelas. Nesse caso, faça backup de tudo. Para alguns bancos de dados, isso levará muito tempo; Para outros, nem tanto. Tudo depende do tamanho do projeto.

4 Trabalhar com os dados

Neste ponto, você deve ser capaz de começar a manipular o banco de dados usando o front-end ou SQL. Se você não está confortável ou mesmo certo de como fazer isso, converse com alguém que esteja, pois isso pode ser algo incrivelmente sensível (afinal, você está lidando com a reconstrução de um banco de dados a partir de arquivos, certo?)

Uma vez que você acredita que tem as informações em um local que está pronto para ser restaurado para qualquer aplicativo perdido, informações corrompidas ou simplesmente com dados malformados, então é hora de se preparar para pegar as informações de sua máquina local e enviá-las de volta para o fonte.

De volta à fonte

Em primeiro lugar, recomenda-se que todos os itens acima sejam feitos durante os horários de baixo tráfego, portanto, certifique-se de que, sempre que fizer isso, não o faça durante o horário de pico. Isso deve acontecer sem dizer.

Em seguida, faça um backup do banco de dados antes de começar a operar nele. Salve o arquivo em um local que você possa recuperar facilmente e acessar facilmente para que, se algo der errado ao usar as informações que você está prestes a importar, você esteja coberto e simplesmente restaure o que já estava lá. Para ser claro, exporte todo o banco de dados no formato SQL.

Agora pegue o banco de dados que você tem em sua máquina local e exporte essas informações para um arquivo SQL também. Abra o arquivo exportado e certifique-se de que está usando uma instrução CREATE para criar o banco de dados com o nome próprio e as tabelas com os nomes próprios também.

Supondo que tudo corra bem, tudo o que você importou será restaurado exatamente como deveria e como você vê em seu dispositivo local. Se você não vir isso, importe o arquivo exportado anteriormente; caso contrário, você está pronto para ir.

E se não funcionar?

Se não funcionar, você terá que ir até a raiz do problema:

Não funcionou por causa de algo errado com os arquivos do servidor?
Não funcionou devido ao tipo de banco de dados que você criou em sua máquina local?
Você está usando o mesmo mecanismo de armazenamento? Você deveria estar, já que está vindo dos arquivos.
A integridade do banco de dados é sólida localmente?
O banco de dados no servidor está sendo excluído antes de importar os dados de sua máquina local?

Se não estiver funcionando neste momento, geralmente será por causa de algo como o que está acima. No entanto, pode ser outra coisa. Fiz o que pude para fornecer o máximo de informações possível sobre bancos de dados MySQL, como eles são estruturados e as etapas necessárias para reconstruir o banco de dados a partir de arquivos, mas não consigo capturar todos os casos extremos em potencial.

Sempre faça backup dos dados (e não assuma que está sendo feito)

Dito isso, espero que todas as informações acima forneçam uma compreensão mais profunda do que está por baixo do WordPress, caso você enfrente esse problema por conta própria ou com um cliente.

E, finalmente, sempre backup. Faça backups manuais, faça backups automáticos e faça-os com frequência. Também não o limite ao banco de dados. Faça backup do banco de dados, do aplicativo e de tudo o que for necessário para alimentar a solução.

Se você fizer isso, não terá que se preocupar com todos os itens acima.

Fonte de gravação: tommcfarlin.com