Você sabe como exportar uma ou mais tabelas InnoDB de um database para outro ou de um servidor para outro apenas movendo os arquivos de dados?

Como sabemos, com tabelas InnoDB não podemos fazer igual fazemos com tabelas MyISAM, onde basta copiarmos os 3 arquivos(MYD, MYI e FRM) da tabela MyISAM e enviar para onde quisermos. Mas tem um recurso nativo e que permite fazer algo bem semelhante e pode ajudar muito.

Assista o video e veja como isso funciona.

 

 Pré-requisitos

  1. MySQL 5.6.6 ou superior
  2. InnoDB File Per table ativado

 

Como fazer

Independente se deseja enviar para um database no mesmo servidor ou para outro servidor os procedimentos são os mesmos.

Os exemplo abaixo são os mesmos mostrados no video acima, então para um melhor entendimento das instruções abaixo assista o video .

 

Criar uma tabela com a mesma estrutura no database que irá receber os dados.

(seguindo os mesmos passos do video)

Servidor Origem:

mysql> show create table c;
+-------+---------------- +
| Table | Create Table   |
+-------+-----------------+
| c     | CREATE TABLE `c` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `dt` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=25496 DEFAULT CHARSET=latin1 |
+-------+----------------+

Servidor destino:

mysql> CREATE TABLE `c` (
    ->   `id` int(11) NOT NULL AUTO_INCREMENT,
    ->   `dt` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
    ->   PRIMARY KEY (`id`)
    -> ) ENGINE=InnoDB AUTO_INCREMENT=25496 DEFAULT CHARSET=latin1;
Query OK, 0 rows affected (0,01 sec)

Descartar o tablespace da tabela que acabou de ser criada no servidor de destino.

Ao descartar o tablespace o MySQL vai excluir o arquivo .ibd que contém os dados e índices da tabela e preparar para que possa ser feita uma importação de tablespace na sequência.

Muito cuidado para executar esse comando no servidor de destino e não no servidor de origem, se executar na origem vai apagar todos os dados.

mysql> ALTER TABLE c DISCARD TABLESPACE;
Query OK, 0 rows affected (0,00 sec)

Preparar o MySQL para exportar a tabela, e fazer o envio dos arquivos e liberando a tabela no servidor de origem.

Servidor de Origem:
Preparar o MySQL para permitir que uma tabela seja exportada.

mysql> FLUSH TABLES c FOR EXPORT;
Query OK, 0 rows affected (0,06 sec)

Esse comando fez com que a tabela c receba um lock e também gera um arquivo chamado c.cfg que deverá ser enviado para o servidor de destino junto com o c.ibd.
O arquivo c.cfg é um arquivo que será usado no servidor de destino para validar a estrutura da tabela que já criamos com a estrutura da tabela do servidor de origem, assim garantindo a compatibilidade de estruturas e podendo concluir a importação com sucesso.

Agora basta enviar os arquivo c.cfg e c.ibd para o servidor de destino.

cd /var/lib/mysql/performancedb/
scp c.cfg root@157.230.129.20:/var/lib/mysql/pdb/                                  
scp c.ibd root@157.230.129.20:/var/lib/mysql/pdb/

Agora precisamos liberar o lock da tabela liberando ela para ser usada novamente.

mysql> UNLOCK TABLES;
Query OK, 0 rows affected (0,06 sec)

Ajustando as permissões dos arquivos enviados no servidor de destino                                           

Agora que  os arquivos cfg e ibd já estão no servidor de destino, é necessário verificar se eles estão com as permissões corretas. O usuário e o grupo dos arquivos no linux devem ser o mysql.

-rw-r-----. 1 root  root   405 Jan 11 18:09 c.cfg
-rw-r-----. 1 mysql mysql 8,4K Jan 11 18:05 c.frm
-rw-r-----. 1 root  root  9,0M Jan 11 18:10 c.ibd
chown mysql:mysql c.cfg
chown mysql:mysql c.ibd
-rw-r-----. 1 mysql mysql  405 Jan 11 18:09 c.cfg
-rw-r-----. 1 mysql mysql 8,4K Jan 11 18:05 c.frm
-rw-r-----. 1 mysql mysql 9,0M Jan 11 18:10 c.ibd

Importando o tablespace no servidor destino

Tudo pronto, arquivos enviados do servidor de origem para o servidor de destino, permissões ajustadas, agora só falta importar o tablespace novamente. Esse procedimento de importar o tablespace basicamente faz o link entre o arquivo de dados(c.ibd) com a tabela na engine InnoDB do servidor.

mysql> alter table c import tablespace;
Query OK, 0 rows affected (0,07 sec)
mysql> select count(*) from c;
+----------+
| count(*) |
+----------+
|    41297 |
+----------+
1 row in set (0,02 sec)

 

Pronto, a tabela foi copiada de um servidor MySQL em funcionamento e enviada para outro.
Claro que tem situações que é mais simples fazer isso com o mysqldump, mas como disse no video, se for uma tabela grande e o tempo de backup, enviar o arquivo e restore será demorado, esse se torna um procedimento bem útil.

Links de referência

Esse é um post é um pouco diferente dos outros, pois esse não é nada técnico e mão na massa, e sim com o intuito de conscientização.

Infelizmente muitas empresas não compreendem a importância de ter DBA trabalhando em conjunto com o time de desenvolvimento em todas as etapas do projeto, o DBA ainda é visto como a pessoa que será acionada apenas quando problemas no ambiente de produção acontecerem e com SLA nível 0. Mas mal sabem que o trabalho do DBA é para que isso nunca aconteça.

Então qual a importância e as suas atribuições de envolver o DBA em um projeto desde o inicio?

Bem, o DBA tem dois papeis fundamentais no processo de desenvolvimento de um projeto, que podem ser ou não desempenhados pela mesma pessoa(normalmente é, se você está em uma empresa que não é, pode ter certeza que já é um privilegiado).
Apesar que mais recentemente apareceram(ou ficaram mais famosas) várias nomenclaturas para as atividades do DBA(DBA, DBO, DA, DS, etc…), na essência o trabalho do DBA vai se dividir entre Administração do servidores de banco de dados e Desenvolvimento de banco de dados, que é o DBA que vai trabalhar mais com o foco na modelagem e desenvolvimento de queries.

O trabalho do DBA deve iniciar no momento zero de cada projeto, pois a definição de qual banco de dados será utilizado pode ser fundamental para um sistema saudável no futuro, por exemplo, usar um banco de dados NoSQL para um sistema que precisa de características relacionais já é um baita tiro no pé e quando ele estiver em produção as chances de problemas de todos os tipos, sem contar que com esse cenário a responsabilidade dos dados passa para a programação, e o banco de dados serve apenas como um lugar que armazena os dados.

Com o banco de dados(SGDB) definido, inicia o trabalho de modelagem de dado. Nesse momento será desenhado o esqueleto de sustentação de um sistema, pois por mais que venham a existir inúmeras regras de negócio, a execução, validação e bom funcionamento dessas regras de negócio será muito mais simples com uma modelagem de dados bem feita.
Deve existir uma harmonia entre  a modelagem de dados e o diagrama de classes, eles devem ser construídos juntos. Uma coisa que me me deixa triste é quando o diagrama de classes está pronto, todos os requisitos levantados, os programadores iniciando a escrever as primeiras linhas de código e nesse momento o DBA é envolvido para dar uma olhadinha nas tabelas que foram criadas, muitas vezes sem regras de nomenclatura, sem uma correta definição dos tipos de dados, engines, posicionamento de colunas, chaves estrangeiras, índices, dimensionamento do hardware, etc…
Sim, se o DBA for envolvido desde o inicio, na versão inicial da modelagem tudo isso ja vai estar bem encaminhado, claro que irá ter alterações, mas em menor quantidade e com menos impacto possível para o desenvolvimento. E como já dizia o É o Tcham “Pau que nasce torto nunca se endireita”. Isso significa que depois que o desenvolvimento já iniciou qualquer alteração que visa a saúde do banco de dados fica de difícil implementação e cara e normalmente não é feita, ja que na maioria das vezes arrumar esses problemas de estruturas e conceitos é o mesmo que reescrever parte do sistema.

Ok, entendi, então o DBA modela o banco e pronto? tudo vai ser um livro com final feliz?

Não!
Mas isso vai contribuir para que os problemas não aconteçam, ou se acontecer eles tenham o menor impacto possível.

Em paralelo ou depois com a modelagem(depende de quantos DBAs tem no projeto) inicia a fase de planejar o ambiente de banco de dados, configurar, “tunar”, ajustar monitoramento, políticas de backup e restore, redundância, failover, etc…

Mas não para por aqui, tem toda a parte de segurança de acesso aos dados, segurança dos dados, auditoria, é um trabalho que inicia no momento 0 e nuca mais termina, o acompanhamento do banco de dados será até o fim da vida do sistema.

O DBA não faz parte do projeto apenas para resolver os problemas de lentidão apresentados, ele está lá para evitar que esses problemas aconteçam e quanto menos problemas, mais horas de sono para todos e credibilidade o sistema vai ter.

Então nada de colocar na cabeça que a primeira coisa que o DBA aprende é ser chato, acontece que que assim como o time de desenvolvimento o DBA tem muitas tarefas e responsabilidades e muito desse trabalho vai sim entrar em conflito com o desenvolvimento mas sempre pelo bem do projeto. Mas a segunda coisa que o DBA aprende é ser chato sim, pois sem ser chato dificilmente as regras e necessidades do banco de dados sejam atendidas, e por último o DBA aprende que as coisas tem que ser feitas da forma correta já no inicio, pois depois as melhorias viram lenda.

Então cuidado para o barato não sair caro.