Páginas

quarta-feira, 27 de fevereiro de 2013

Migração de Servidores MySQL


Bom pessoal, vou neste post abordar uma migração de Servidores MySQL. Venho compartilhar isso, pois como parte do dia-a-dia de um DBA temos que fazer migrações físicas e logicas de servidores de banco de dados para suportar as aplicações na qual a empresa utiliza.

Descrição do Ambiente:
Servidor Linux Debian 5 com MySQL 5.0.51 para aplicações web (Servidor de produção antigo)
Servidor Linux Debian 6 com MySQL 5.5.30 para aplicações web (Servidor de produção novo)


Vamos ao procedimento de migração:

1. Verifique quais os Schemas que serão migradas


Para verificar os Schemas existentes num banco de dados MySQL, digite o comando abaixo:
mysql> show databases;

Logo após isso verificar quais as bases que serão migradas, verifique a coleção de caracteres que é utilizada nos Schemas, com o comando abaixo:
mysql> select schema_name, default_collation_name, default_character_set_name from information_schema.schemata;

2. Faça o Backup/Dump dos Schemas


Para fazer o backup dos schemas listados no primeiro passo, execute os comandos abaixo:
root # mysqldump --user=root --password=teste --host=127.0.0.1 --port=3306 --routines --triggers --default-character-set=utf8 joomla > backup_joomla_migraca.sql

root # mysqldump --user=root --password=teste --host=127.0.0.1 --port=3306 --routines --triggers --default-character-set=utf8 joomla2 > backup_joomla2_migraca.sql

3. Depois de efetuado o Backup dos Schemas no Servidor antigo de produção, iremos no Servidor novo de produção, verificar quais schemas ele possui e criar os schemas que iram ser importados para o novo servidor:


Conforme feito no antigo servidor antigo anteriormente, vamos listar os schemas deste novo servidor e depois criar os schemas que serão importados. Segue abaixo os comandos utilizados:
mysql> show databases;
mysql> CREATE DATABASE `joomla` DEFAULT CHARACTER SET utf8;
mysql> CREATE DATABASE `joomla2` DEFAULT CHARACTER SET utf8;

4. Crie os usuários no novo servidor que iram ser utilizados pelas aplicações web:


Segue abaixo, comandos utilizado para criação dos usuários que iram acessar o banco de dados pelas aplicações:
mysql> GRANT ALL PRIVILEGES ON joomla.* TO 'joomla'@'localhost' IDENTIFIED BY 'teste123';
mysql> GRANT ALL PRIVILEGES ON joomla2.* TO 'joomla2'@'localhost' IDENTIFIED BY 'teste123';

5. Depois que criarmos no novo servidor de produção que irá receber os dados do antigo servidor, precisamos transferir os arquivos que foram backpeados no antigo servidor para o novo servidor. Para o exemplo aqui utilizado utilizei o utilitário SCP , mais poderíamos transferir através de FTP ou outro meio de compartilhamento de arquivos.


Segue abaixo, comando utilizado:
root # scp backup_joomla_migracao.sql backup_joomla2_migracao.sql turbo@192.168.1.68:/home/turbo/

6. Agora no novo servidor de produção, faça o importe o arquivo de backup transferido para o mesmo.


Segue abaixo, os comandos utilizados para importar as bases de dados:
root # mysql -u root -p joomla < /home/turbo/backup_joomla_migracao.sql
root # mysql -u root -p joomla2 < /home/turbo/backup_joomla2_migracao.sql

7. Verifique se os dados estão validos e consistentes , verifique o numero de tabelas, índices ou procedimentos armazenados caso sua aplicação utilize.

Servidor antigo de produção:


Servidor novo de produção:


Como verificamos, o numero de objetos do nosso banco de dados no novo servidor de produção está igual ao antigo servidor de produção. Para fazer está verificação utilize o select abaixo, depois de conectado no servidor MySQL:


SET @nome_do_schema = 'joomla';
Select
(select schema_name from information_schema.schemata where schema_name=@nome_do_schema) as "Nome do Banco de dados",
(SELECT Round( Sum( data_length + index_length ) / 1024 / 1024, 3 )
FROM information_schema.tables
WHERE table_schema=@nome_do_schema
GROUP BY table_schema) as "Tamanho do Banco de dados em Mega Bytes",
(select count(*) from information_schema.tables where table_schema=@nome_do_schema and table_type='base table') as "Quant. Tabelas",
(select count(*) from information_schema.statistics where table_schema=@nome_do_schema) as "Quant. Índices",
(select count(*) from information_schema.views where table_schema=@nome_do_schema) as "Quant. Views",
(select count(*) from information_schema.routines where routine_type ='FUNCTION' and routine_schema=@nome_do_schema) as "Quant. Funções",
(select COUNT(*) from information_schema.routines where routine_type ='PROCEDURE' and routine_schema=@nome_do_schema) as "Quant. Procedimentos",
(select count(*) from information_schema.triggers where trigger_schema=@nome_do_schema) as "Quant. Triggers",
(select default_collation_name from information_schema.schemata where schema_name=@nome_do_schema)"Default collation do Banco de dados",
(select default_character_set_name from information_schema.schemata where schema_name=@nome_do_schema)"Default charset do Banco de dados",
(select sum((select count(*) from information_schema.tables where table_schema=@nome_do_schema and table_type='base table')+(select count(*) from information_schema.statistics where table_schema=@nome_do_schema)+(select count(*) from information_schema.views where table_schema=@nome_do_schema)+(select count(*) from information_schema.routines where routine_type ='FUNCTION' and routine_schema=@nome_do_schema)+(select COUNT(*) from information_schema.routines where routine_type ='PROCEDURE' and routine_schema=@nome_do_schema)+(select count(*) from information_schema.triggers where trigger_schema=@nome_do_schema))) as "Total de Objetos do Banco de dados"
LIMIT 0, 1000\G

Bom pessoal, espero que esse procedimento de migração possa ajudar a Desenvolvedores e DBAs para migrar suas aplicações para ambientes melhores. Lembrando que este procedimento também se aplica em outros ambientes como Windows ou FreeBSD/Unix. Qualquer dúvida na utilização dos passos do post, favor comentar. Que a Graça e Paz estejam com todos.

6 comentários:

  1. Olá Emerson! Parabéns pelo post! Este realmente é um assunto muito relevante, ainda mais depois do lançamento da versão 5.6. :-)

    Gostaria de acrescentar duas observações que podem ser importantes para cenários mais genéricos.


    Como regra geral, para atualizar o MySQL a partir de uma série versão anterior ao MySQL 5.1, o upgrade para cada série sucessiva de liberação, por sua vez, até que você tenha atingido o MySQL 5.1, e então proceder com a atualização para o MySQL 5.5. Por exemplo, se você está atualmente executando o MySQL 5.0 e deseja atualizar para 5.5, você deve primeiro atualizar para o MySQL 5.1 antes de atualizar para o 5.5, e assim por diante.

    Após a atualização para uma nova versão do MySQL, execute mysql_upgrade. Este programa verifica suas tabelas, e tenta repará-las se necessário. Ele também atualiza metadados para se certificar de que eles têm a estrutura atual de modo que você pode tirar vantagem de quaisquer novos recursos. 

    Mais informações: http://dev.mysql.com/doc/refman/5.6/en/upgrading.html

    Novamente, obrigado pelo post!

    ResponderExcluir
    Respostas
    1. Airton,
      Agradeço pelo comentário que pode acrescentar mais conhecimento e enriquecer esta postagem. Obrigado pela colaboração.

      Att,
      Emerson

      Excluir
  2. Muito bom o Post muito util e muito funcional. Eu tenho uma duvida mais além um pouquinho em caso de migração de servidores antigos, onde voce tenha lá uns 50 usuário no banco com suas devidas permissões para suas: Views, Triggers, Procedures e etc. Como eu faria para trazer esses usuários para o NOVO SERVER???, pois Cadastrar na mão um por um seria muito dificil.

    ResponderExcluir
    Respostas
    1. Bom dia Claudeir,
      Obrigado por visitar o Blog , que bom que o Post te ajudou. Quanto a parte de migração de usuários o MySQL já possui um comando que demonstra os privilégios existentes dos usuários que deseja migrar. Segue abaixo, link para lhe ajudar neste migração:
      http://blog.gaudencio.net.br/2013/08/atribuindo-permissoes-para-usuario-mysql.html
      Qualquer dúvida só comentar aqui.

      Excluir
    2. Ok, Emerson eu entendi, porem a duvida é diferente, deixa eu explicar melhor, no meu Server1(5.1) eu tenho uma Base de Xgb com Xusuários(50 ou mais), X Procedures referentes a cada usuarios e Functions e etc, Mas a tabela USER do Schema Mysql 5.1 é diferente da tabela USER do schema Mysql 5.6, logo se eu simplesmente quiser simplesmente copiar do Server antigo(5.1) para o Server novo(5.6) ele me dá um erro e em um teste que fiz em uma VM chegou a corromper o Mysql. Se eu simplesmente trouxer todas as tabelas dos mysql 5.1 para o 5.6, na hora de contruir as Procedures, View, Fucntions e etc ele não consegue pois não acha os seus Owners respectivos, Entendeu? A dúvida é na migração do 5.1 para 5.6 será que existe alguma ferramenta ou Script pronto que consiga otimizar esse processo, porque se voce tiver uma base antiga com muitos usuarios, imagina voce ter que cadastrar um por um e dar as suas devidas permissões para cada um para DEPOIS restaurar a base???

      Excluir