Português do Brasil English
Devin no Facebook  Devin no Twitter  RSS do Site 
Servidores    

Replicação MySQL


Comentários  46
Visualizações  
236,804

Tem quem goste, tem quem não goste, mas uma coisa é certa: o MySQL é hoje um dos bancos de dados mais utilizados em sistemas Web. Se você é um dos muitos que usam, com certeza deve se preocupar bastante com os dados que estão dentro do banco. A última coisa que queremos é perder os dados, né? :-) Este tutorial mostra um pouco sobre como podemos nos precaver e manter o servidor MySQL funcionando de forma correta e com mais segurança.

A primeira forma de se manter uma segurança adicional do serviço funcionando e de seus dados é a replicação MySQL. A replicação é utilizada para que caso um servidor caia (e se machuque), o HD exploda ou algo parecido, haverá um segundo servidor com todos os dados atualizados e pronto para o uso. Sites sérios que precisam se manter sempre funcionando, com o mínimo de downtime quando algo falha devem utilizar sempre uma forma de replicação.

Mas a replicação em si, sozinha, não basta. Algumas pessoas pensam que só por fazer uma replicação e ter dois servidores funcionando e com os dados, estão seguros. Isto é errado. A replicação só é útil para falhas de hardware, rede, tempestades, furacões e esse tipo de coisa. Se esquecem do mais acontece: erros humanos, erros de sistema, invasões, e tudo mais que prejudica o banco de dados mesmo ele funcionando. Se por exemplo o famoso estagiário apagar uma tabela em um servidor, a replicação vai apagar a mesma tabela no outro servidor! E para esse tipo de problema, só os backups salvam! :-)

Este tutorial cobre a parte de replicação no MySQL.

A replicação MySQL funciona sincronizando os dados entre dois ou mais servidores, em tempo real (ou mais ou menos isso). Em outras palavras, se um usuário criar ou atualizar algum dado em um banco de dados, o outro servidor puxa esse comando e executa nele também. É importante notar que o comando só é feito quando se cria ou atualiza algum dado, pois sincronizar uma leitura não faria o menor sentido…

Existem duas formas de se fazer uma replicação MySQL: master-slave e master-master.

Chamamos de servidor master o principal, aquele em que executamos comandos de criação e modificação. Chamamos de servidor slave aquele que puxa os dados do servidor principal para deixar os dados sincronizados. No modelo master-slave, só podemos executar comandos de escrita e atualização no master, enquanto podemos executar consultas tanto no master quanto no slave.

O modelo master-slave geralmente é o mais utilizado por ser simples de configurar e trabalhar. Seu uso também pode ocorrer em sites que tem muito movimento e que fazem pouca escrita e atualização. Com um master, podemos replicar os dados para vários slaves e distribuir as consultas para os vários slaves. Se um site tem centenas ou milhares de consultas por segundo, fica interessante balancear estas consultas em todos os slaves.

A figura a seguir mostra como funciona a replicação MySQL master-slave:

mysql master slave Replicação MySQL

Preparando a replicação MySQL

Antes de mais nada, você vai precisar confirmar que a replicação pode ser usada em seu servidor master. Depois de instalado o MySQL, dê uma olhada na configuração de logs binários dele, entrando no prompt e executando:

mysql> SHOW GLOBAL VARIABLES WHERE Variable_name = 'log_bin';

+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | OFF   |
+---------------+-------+
1 row in set (0.02 sec)

…que no meu caso está desligado. Os logs binários são um registro das ações de modificações de dados em um banco. Esses logs binários são necessários na replicação pois o servidor slave puxa as linhas desses logs binários para executar nele também. Para ligar os logs binários, edite o arquivo my.cnf (no RedHat/Fedora está em /etc, no Debian/Ubuntu está em /etc/mysql) e adicione a seguinte linha após a seção [mysqld]:

# Localização do arquivo do log binário
log-bin=/var/lib/mysql/mysql-bin.log

# Número de identificação do servidor. O banco de dados
# Master é o 1, seguido dos Slaves a partir de 2.
server-id=1

Atenção: a variável global log_bin só pode ser recarregada reiniciando o MySQL. Antes de continuar com os passos, reinicie o serviço.

Ao reiniciar o MySQL, note que ele criou os seguintes arquivos:

  • /var/lib/mysql/mysql-bin.index
  • /var/lib/mysql/mysql-bin.000001

O arquivo mysql-bin.index contém uma lista dos logs binários disponíveis. Já os arquivos numerados mysql-bin.NNNNNN (onde N é um número sequencial) contém os logs binários. Se os arquivos foram criados, é porque está funcionando. Experimente também rodar o comando anterior (SHOW GLOBAL VARIABLES [...]) para ver a opção ativa.

Note também que no arquivo my.cnf eu defini a identificação do server (server-id) como 1. A identificação é muito importante e faz parte do controle da replicação. Você nunca poderá ter dois servidores com o mesmo ID se comunicando).

Usuário da replicação

Como vimos anteriormente, o servidor slave tem que se conectar ao servidor master para puxar os dados para replicação. Essa conexão é feita através da porta TCP do MySQL, assim como qualquer outra conexão. Em outras palavras, uma conexão entre servidores master e slave é como qualquer outra conexão de qualquer sistema. A diferença é que o usuário e senha que serão utilizados pelo slave terão permissões especiais para puxar todos os dados dos logs binários.

Sendo assim, entre no servidor MySQL Master e crie esse usuário:

mysql> GRANT REPLICATION SLAVE ON *.* TO 'replication'@'192.168.0.2' IDENTIFIED BY 'senhasecreta';
Query OK, 0 rows affected (0.01 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

Nota: no primeiro comando, é importante notar que demos o tipo de permissão REPLICATION SLAVE em todo o banco de dados (*.*) para o usuário. Não é possível dar permissões de replicação para um ou outro banco de dados apenas, tem que ser tudo. Veja também que o usuário criado foi o replication@192.168.0.2, ou seja, o nome do usuário é replication e ele só pode se conectar vindo do IP 192.168.0.2.

Replicação MySQL Master / Slave

Para começar a implementar a replicação, façamos a primeira pergunta: seu banco de dados master é novo ou já está sendo usado?

Antes de começar a replicar de um servidor para outro, é necessário deixar os dois bancos de dados iguais. Se o seu banco de dados é novo, vazio, então o slave também estará vazio e essa sincronização especial não é necessária. Por outro lado, e como é na maioria das vezes, se já existir alguma coisa no banco de dados master, você precisará pegar os dados de um e colocar no outro para ficarem iguais.

Ainda mais quando o servidor já está funcionando e você não pode pará-lo… A técnica aqui consiste primeiro em obter um LOCK em todas as tabelas e fazer um backup de todos os bancos de dados. Durante o backup, todo mundo que estiver conectado no servidor poderá ler as tabelas e linhas, mas todas as inserções e atualizações vão ficar paradas até o backup acabar. Em outras palavras, dependendo do tempo do backup, um sistema pode ficar lento, esperando escrever nas tabelas.

Antes de começar, entre no servidor MySQL Master e execute:

mysql> SHOW MASTER STATUS;

+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000005 |      602 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

Se o servidor está em atividade, executar esse comando novamente vai mostrar que o arquivo e posição estão aumentando. Estes dados correspondem a posição atual do log binário e vão ser necessários para o slave saber de onde começar a replicação.

Agora abra um outro terminal e execute o comando de backup:

servidor-master$ mysqldump -u root -p --all-databases --master-data=1 > backup-master.sql
Password: <suasenhasecreta>

Fazendo isso, praticamente não existirá downtime e os sistemas que usam o banco de dados serão afetados o mínimo possível. O backup então é guardado no arquivo backup-master.sql.

Explicando as opções do comando mysqldump, o –all-databases diz para fazer um backup de todos os bancos de dados existentes no servidor, o que é perfeito para nossa cópia exata para o slave. Agora, importante é o parâmetro –master-data=1. Este parâmetro faz com que o comando obtenha um LOCK de todas as tabelas do servidor (como expliquei antes) e escreva dentro do arquivo de backup a posição do log binário (o mesmo mostrado pelo SHOW MASTER STATUS).

Dica: Você pode fazer o backup e compactar ao mesmo tempo com o comando:

servidor-master$ mysqldump -u root -p --all-databases --master-data=1 | gzip -c > backup-master.sql.gz

Dica: Se todo o seu banco de dados for do tipo InnoDB, você não precisa aplicar um LOCK nas tabelas. Basta adicionar o parâmetro –single-transaction ao comando mysqldump. Como o InnoDB é transacional, o –single-transaction faz o backup precisar do LOCK apenas no começo, ao iniciar a transação.

Agora vá ao servidor slave e restaure o banco de dados com o comando:

servidor-slave$ mysql -u root -p < backup-master.sql

(Ou se tem um arquivo compactado com gzip):

servidor-slave$ zcat backup-master.sql.gz | mysql -u root -p

Feito isso, o servidor slave está pronto para ficar sincronizado com o master e começar a replicação.

Iniciando a replicação

Verifique primeiro se no my.cnf o parâmetro server-id está diferente do master. Se o master é 1, coloque o server-id igual a 2 no slave.

Agora é hora de configurar a replicação. Primeiro de tudo, veja qual o arquivo e posição do backup, no começo do arquivo:

$ head -n 100 backup-master.sql | grep "^CHANGE MASTER"

CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000005', MASTER_LOG_POS=602;

Iremos usar esse mesmo comando, mas com informações a mais. Entre no prompt MySQL Slave e execute:

mysql> CHANGE MASTER TO
       MASTER_HOST='192.168.0.1',
       MASTER_USER='replication',
       MASTER_PASSWORD='senhasecreta',
       MASTER_LOG_FILE='mysql-bin.000005',
       MASTER_LOG_POS=602;
  • MASTER_HOST: O IP do servidor master, que aqui é 192.168.0.1;
  • MASTER_USER: O usuário slave para replicação. Criamos anteriormente com o GRANT SLAVE REPLICATION;
  • MASTER_PASSWORD: A senha do usuário replication, criados anteriormente também;
  • MASTER_LOG_FILE: O arquivo atual de log binário do servidor master, indicado na linha que buscamos no backup;
  • MASTER_LOG_POS: A posição atual no arquivo de log binário, indicado também no backup.

Nota: Depois de executado esse comando uma vez, se precisar refazer a sincronia entre os servidores, basta restaurar o arquivo de backup, pois a posição do log binário já está no arquivo de backup como indicado anteriormente. Precisamos executar esse comando da primeira vez para indicar o IP do servidor, usuário e senha.

Agora que a replicação foi configurada, basta iniciá-la. No prompt do MySQL Slave:

mysql> START SLAVE;
Query OK, 0 rows affected (0.00 sec)

Pronto! Se fez tudo certo, a replicação já deve estar funcionando. Tente criar bancos de dados ou tabelas no master e verifique que também devem estar no slave.

Verificação

Com tudo rodando, você pode querer saber como estão as coisas, querer monitorar ou verificar se existe algum erro ou problema de desempenho. Existe um comando que pode ser feito no servidor MySQL Slave que nos mostra algumas informações:

mysql> SHOW SLAVE STATUS \G

*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.0.1
                  Master_User: replication
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000005
          Read_Master_Log_Pos: 602
               Relay_Log_File: mysqld-relay-bin.000002
                Relay_Log_Pos: 253
        Relay_Master_Log_File: mysql-bin.000005
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 602
              Relay_Log_Space: 410
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 1
1 row in set (0.00 sec)

As primeiras linhas que temos que olhar são:

  • Slave_IO_Running: Se a replicação está rodando e conseguiu se conectar no servidor master. Caso esteja como No, verifique se executou o START SLAVE, se há problemas de conectividade entre as máquinas, usuário e senha corretos, etc;
  • Slave_SQL_Running: Se os comandos SQL estão sendo executados ou pronto para serem executados. Se não estiver como Yes, significa que deu algum erro no meio da replicação: dados duplicados, tabelas incorretas, banco dessincronizado, etc.

Em ambos os casos, quando dar algum erro, você pode consultar o erro nas linhas Last_IO_Error e Last_SQL_Error.

Outra linha importante é a Seconds_Behind_Master. Essa linha indica o quão atrasado o servidor Slave está em relação ao Master. Idealmente, o valor aqui deve ser sempre 0, ou seja, todos os dados estão sempre sincronizados. Mas se por algum problema de desempenho o slave não conseguir fazer todas as inserções e updates do Master, ele vai aumentando o número (uma estimativa em segundos). Não é um problema quando não for zero, desde que não seja um número muito alto ou constantemente crescente.

Quando você para um servidor slave e o inicia, digamos, depois de 30 minutos, ele recomeça a replicação de onde parou, então você pode ver o número do Seconds_Behind_Master diminuírem.

Outro ponto interessante é saber sempre a posição de log binário que o slave está pegando do Master (o mesmo do SHOW MASTER STATUS do Master). Essa informação é representada pelas linhas Master_Log_File e Read_Master_Log_Pos.

Replicação MySQL Master / Master

A replicação master-master tem como objetivo ter os mesmos dados nos dois servidores, assim como o master-slave. Mas no master-master, os sistemas podem inserir e modificar os dados nos dois servidores. A vantagem deste modo de operação é que se um cair, o outro pode assumir imediatamente todas as funcionalidades: leitura e escrita. No modelo master-slave, se o master cair, é necessário que um dos slaves se torne um master, e a replicação para outros servidores tem que ser refeita (além de geralmente necessitar de configuração manual nos sistemas).

A seguinte imagem ilustra como vai funcionar:

mysql master master Replicação MySQL

Para fazer o master, basta seguir todos os procedimentos do Master/Slave, só que trocando os servidores. O servidor master vai ser também um slave do outro servidor. Na prática, os dois são masters, os dois são slaves um do outro.

Porém, há uma característica muito importante que devemos lembrar: o autoincrement. O autoincrement é um recurso que o banco de dados oferece para ir incrementando automaticamente os números em uma coluna de dados. Ele é geralmente usado para colunas que indicam um ID único de uma linha. O problema com o autoincrement é que quando duas inserções de linha acontecem ao mesmo tempo nos dois servidores, o MySQL vai gerar o mesmo número. Quando um slave for pegar a inserção do master, ele vai tentar inserir uma outra linha com o mesmo número ID. Ao tentar fazer isso, dará um erro na replicação dizendo que essa coluna não pode ser repetida com esse ID.

Para contornar isso, temos que indicar ao banco de dados para utilizar números pares em um servidor e números ímpares em outro servidor.

Nota: Como deu pra perceber, ao usar qualquer coluna de tabela com autoincrement, a complexidade da replicação aumenta. Por isso, se você usa autoincrement em alguma tabela, você provavelmente não vai querer usar mais de dois servidores, senão a técnica dos números pares e ímpares não dará certo.

Você vai precisar das seguintes linhas no my.cnf do primeiro servidor:

auto-increment-increment = 2
auto-increment-offset = 1

E no my.cnf do segundo servidor:

auto-increment-increment = 2
auto-increment-offset = 2

Depois, em resumo, basta seguir os passos da replicação, explicados anteriormente:

  1. Certifique-se que as linhas de server-id tenham valores diferentes em cada servidor;
  2. Certifique-se que os logs binários (log-bin no my.cnf) estejam ativados nos dois servidores;
  3. Crie os usuários de replicação em cada um dos servidores;
  4. Caso necessário, sincronize os dados de um servidor em outro utilizando o mysqldump;
  5. Utilize o comando CHANGE MASTER TO para configurar a replicação, cada servidor apontando como master o outro;
  6. Verifique com o SHOW SLAVE STATUS em cada um dos servidores para ver se está tudo OK.

FAQ – Dúvidas comuns

Sempre surge alguma dúvida né? Ou até serve como curiosidades…

Como obter as informações do master em um slave?

Esqueceu a senha hein?

Depois de usar o comando CHANGE MASTER TO, os dados ficam gravados no arquivo master.info dentro do diretório de dados do MySQL, que geralmente fica em /var/lib/mysql. O arquivo está em texto plano e pode ser visualizado com qualquer editor de texto ou o cat. Inclusive, o usuário e senha de replicação ficam à mostra (e tem que ficar).

Em termos de segurança, certifique-se que as permissões do usuário de replicação estão apenas para o host que vai conectar e que o arquivo master.info esteja com a permissão para apenas o usuário do mysql ler e escrever.

Como replicar apenas algumas tabelas?

Apesar de não ser muito recomendado no MySQL, você pode filtrar quais tabelas serão replicadas ou não. Existem duas maneiras de se fazer isso: do lado do master e do lado do slave. Em ambas, é necessário colocar alguns parâmetros no my.cnf e reiniciar o serviço MySQL.

Do lado do master, as opções binlog-do-db e binlog-ignore-db fazem isso. Quando o binlog-do-db é utilizado, ele vai gravar no log binário apenas as tabelas que você especificar na opção. Quando o binlog-ignore-db é utilizado, ele grava no log binário todos os bancos de dados, menos os que você especificou.

Mas um jeito melhor de usar é no slave. Ao invés de não gravar o log binário de algumas coisas, é preferível que o master registre tudo, enquanto o slave selecione o que quer e o que não quer.

Eis alguns exemplos… Quero puxar apenas o banco de dados banco_radical:

replicate-do-db = 'banco_radical'

Ou eu quero replicar dois bancos de dados, e por isso tem que se usar duas opções:

replicate-do-db = 'banco_radical'
replicate-do-db = 'billing'

Agora um bastante comum: eu quero replicar todos os bancos de dados, menos o banco mysql, que contém definições de usuários específicas para cada servidor:

replicate-ignore-db = 'mysql'

Vou mais longe, agora eu quero replicar apenas a tabela objetos_radicais do banco de dados banco_radical:

replicate-do-db = 'banco_radical'
replicate-do-table = 'objetos_radicais'

Um prático: quero replicar apenas várias tabelas de um blog WordPress, que utiliza o prefixo wp_42_:

replicate-do-db = 'wordpress'
replicate-wild-do-table = 'wp\_42\_%'

E por aí vai. O comando SHOW SLAVE STATUS também mostra essas opções caso você tenha utilizado.

Referências


Comentários  46
Visualizações  
236,804


TagsLeia também

Apaixonado por Linux e administração de sistemas. Viciado em Internet, servidores, e em passar conhecimento. Idealizador do Devin, tem como meta aprender e ensinar muito Linux, o que ele vem fazendo desde 1997 :-)


Leia também



Comentários

46 respostas para “Replicação MySQL”

  1. Elton Lima disse:

    Tudo que eu precisava para fazer meu lab de mysql com replicação. Show !

    • eitchugo disse:

      Depois nos conte se deu tudo certo no lab! :)

      • Horacio Mondlane disse:

        Boa tarde Pessoal, Eu tenho um problema parecido.
        Tenho duas bases de dados mysql em duas maquinas isoladas mas iguais em termos de estrutura, contendo informações diferentes, lógico. Eu preciso de unir as informações nelas existentes, isto eh, passando a ter uma base com informação proveniente das duas bases de dados isoladas.
        Alguém pode ajudar me? Por favor.

  2. Wasley Almeida disse:

    Bom dia Hugo,
    Implementei essa tecnologia e esta funcionando perfeitamente.

    Minha duvida é a seguinte: queria que o bando de dados do MySQL não fosse replicaod, no seu post você informa que tenho de colocar esse parametro, replicate-ignore-db = 'mysql' mais onde coloco esse parametro, no my.cnf do master?

    Desde já agradeço.

  3. Roger Taipina disse:

    PESSOAL, IMPLEMENTEI UMA REPLICAÇÃO MULT-MASTER SINGLE SLAVE, ONDE UMA PROCEDURE EXECUTA UM CHANGE MASTER TO DE 1 EM 1 MINUTO, APONTANDO PARA SERVIDORES DISTINTOS… EU PASSO TODAS AS COORDENADAS DO MASTER_LOG_POS…. OK.. FICA REPLICANDO DURANTE UM TEMPO.. PORÉM, CHEGA UM MOMENTO QUE DÁ UM ERRO "Could not execute Write_rows event on table base.tabela; Duplicate entry 24-715 for key PRIMARY, Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the events master log mysql24-bin.000002, end_log_pos 671" …. DAI EU PERCEBI QUE NÃO ESTOU INFORMANDO NO CHANGE MASTER TO O NOME DO MASTER_LOG_FILE … A MINHA DUVIDA É A SEGUINTE: COMO O MYSQL CRIAR MAIS DE UM ARQUIVO DE LOG BINARIO NO MASTER, EM QUAL DEVO INFORMAR NO CHANGE MASTER TO ? SEMPRE O mysql_bin.00001 ?

    • eitchugo disse:

      Que tipo de implementação é essa que roda change master de 1 em 1 minuto? Qual o objetivo? O problema de entradas duplicadas é quando o SLAVE tenta escrever algo que já existe como chave primária no banco. Acontece geralmente quando você usa auto_increment sem os offsets. Dá uma lida na parte de Master-Master desse artigo.

      Se você tá querendo fazer um slave de DOIS masters ao mesmo tempo, sinto lhe dizer mas não acho que isso seja possível nesses modelos master/slave e master/master. :(

      O MASTER_LOG_POS e o MASTER_LOG_FILE são dinâmicos, mudam a toda consulta e são diferentes para cada servidor, não dá para saber um valor fixo.

  4. Allan Novaes disse:

    O mais explicado, mto bom!

  5. warley disse:

    amigo uma duvida , por exemplo eu faço uma replicação master -master , se um dos dois cair e eu fizer uma inserção em um quando estiver desligado , quando eu religar ele ele vai pegar esse registro do outro que eu inseri enquanto ele estava desligado?

    • eitchugo disse:

      Sim, a replicação é feita com o servidor indo buscar as queries no outro servidor sequencialmente (master log position). Quando um dos servidores cai, essa posição do log para. Quando ele volta, ele continua de onde parou.

  6. paulo roberto disse:

    ola tudo bem .. gostaria de saber o seguinte tenho replicaçao master > master mas tenho alguns problemas com query duplicada onde tenho que ficar dando o comando SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; existe algum comando para que o mysql ignore as query duplicadas e que não pare a replicacao

    • eitchugo disse:

      Pode sim, mas não é muito recomendado pois você pode ganhar um banco de dados totalmente inconsistente. O ideal é você tentar ver porque está ocorrendo esses erros (por exemplo, os valores do autoincrement podem gerar os duplicados, e zoar totalmente a consistência em alguns sistemas).

      Pra ignorar qualquer erro de slave, basta você colocar no my.cnf essa linha:

      slave-skip-errors = XXX

      Onde XXX é o número do tipo de erro que você quer ignorar.

  7. Rafael disse:

    Boa tarde Hugo,

    Cara primeiramente venho te parabenizar pelos seus posts, são de ótimo nível. A minha dúvida é o seguinte, sabemos que o MariaDb e Percona são derivados do Mysql, já venho utilizando o Maria em localhost, com isso a parte de replicação tb é a mesma coisa para os três ou vc acha que devo me alertar para alguma particularidade?

    • eitchugo disse:

      Acredito que nessas versões o MariaDB seja bem similar ao MySQL nas replicações, mas como não o conheço bem não posso falar nada com certeza. Sugiro se alertar para algumas particularidades sim :) Mas o princípio e a lógica devem ser os mesmos.

  8. Adevalmir disse:

    Hugo, me tira uma duvida..
    No sistema MASTER-SLAVE posso inserir dados normalmente nos slave(s) que irá replicar para o MASTER tudo que for inserido nos slave?
    E no master posso fazer alguma alteração tipo estrutura e dados, que iram replicar para os slaves?

    • eitchugo disse:

      No sistema Master-Slave, você só pode fazer qualquer alteração no master. Se você fizer alterações no slave pode dar defeito na sua replicação. Fazendo tudo no master, qualquer coisa que você fizer vai ser replicada no Slave.

  9. Denilson Paiva disse:

    Bom dia.

    é possível sincronizar dados de 2 tabelas com nomes diferentes em banco de dados diferentes mas os 2 sendo mysql?? pois tenho uma tabela(produto) de uma loja virtual que quero sincronizar com a tabela (prod) de outro sistema, sendo que os campos e nomes são diferentes. é possivel?

  10. Muito bom o artigo, só tenho uma dúvida. Caso o servidor master saia do ar, como posso proceder para que o servidor slave assuma o papel do master ?

    • eitchugo disse:

      Basta colocar a aplicação para se conectar no servidor slave e inverter a replicação (ou seja, fazer o mesmo procedimento, só que ao contrário, tornando o antigo slave agora o master). Infelizmente isso é algo que se tem que fazer separado (e talvez manualmente).

  11. everaldo disse:

    Legal o post. Uma dúvida, tem alguma forma de garantir que o script foi aplicado com sucesso na replica? Por exemplo, se diminuir o tamanho de um campo no slave por engano. Na hora que houver a replicação e vier um dado que nao caiba neste campo.

    • eitchugo disse:

      Não sei como ver isso, só comparando os dois servidores mesmo: nesse caso pode-se tirar um dump das duas estruturas e compará-las para ver se está igual.

      O mais importante é verificar com frequencia se existe erros nas linhas Last_IO_Error e Last_SQL_Error do 'SHOW SLAVE STATUS'

  12. Parabéns muito boa explicação.

    Vamos lá, na empresa onde trabalho temos um sistema em php desenvolvido com framework(codeigniter) que roda online em nosso VPS com apache e mysql.

    Várias clientes(escolas) utilizam este sistema.

    Meu problema começa quando a internet do cliente(escola) cai ou fica muita lenta fazendo o sistema ficar inoperante.

    O chefe pediu para configurar um servidor local para cada cliente(escola) onde o problema de internet é maior, e fazer a sincronização de dados entre as bases de dados, a sincronização poderia ser uma vez por dia. ou ainda melhor usando o modelo do seu artigo master-master.

    Pelo que entendi o modelo master-master seria apenas para uma escola.

    O problema é que o cliente(escola) gera pedido o tempo todo e também existem pedidos online.

    Todas as tabelas do banco de dados são autoincremento.

    Estou montando um script que faria o sincronismo mas meu problema é com os IDs.

    Estou louco atraz de uma solução.

    Alguma idea para este caso?

    Agradeço!

    • eitchugo disse:

      Fica bem complicado. Se uma escola precisa *escrever* no banco, ele estando totalmente offline do master, esse banco precisa ser master. Se cada escola utilizar isso… Seria um modelo com muitos masters.

      Uma forma de simplificar isso seria separar as tabelas por escola, e aí rodar a replicação apenas nelas. Mesmo assim é complicado.

      Outra forma de fazer isso é usando o SymmetricDS, que eu conheci há dois meses. Ele faz muito bem esse serviço, pois faz essas replicações via triggers e webservices, totalmente independente do daemon do MySQL. Achei ele bem legal para replicações mais complexas.

  13. Álvaro disse:

    Olá Hugo, sua solução caiu como uma luva pra mim! Só tenho uma dúvida: Se o usuário alterar algum campo em uma tabela do slave, na replicação (master-slave), ele mantém esta alteração no slave, ou não?

    • eitchugo disse:

      Olá Álvaro, se o usuário escrever qualquer coisa no slave, ele vai manter sim esta alteração. Mas isso também significa que os dados do master não estarão iguais aos do slave e pode ser que ocorra alguma quebra na replicação, impedindo-a de continuar. Então tem que tomar muito cuidado com isso.

      Nesse modelo, o recomendado é sempre fazer tudo no master mesmo.

      • Álvaro disse:

        Voce disse "impedindo-a de continuar", então se o slave estiver com dados diferentes do Master, não vai ser feito a replicação?
        A minha intenção é que o usuário que trabalhar com o slave, faça alteração se necessárias nos campos, e quando houver a replicação as alterações sejam mantidas, isso vai acontecer?

  14. Horacio Mondlane disse:

    Boa tarde Pessoal, Eu tenho um problema parecido.
    Tenho duas bases de dados mysql em duas maquinas isoladas mas iguais em termos de estrutura, contendo informações diferentes, lógico. Eu preciso de unir as informações nelas existentes, isto eh, passando a ter uma base com informação proveniente das duas bases de dados isoladas.
    Alguém pode ajudar me? Por favor. –

  15. Renato disse:

    Hugo, parabéns pelo post, mas ainda estou com uma duvida, eu tenho varios bancos dentro de uma mesma instância, eu gostaria de replicar uma table de um banco para outro.

    Por exemplo tabela usuários do banco 1 para o banco 2

    Hj tenho dois sistemas distintos, mas o login dos meus usuários tem que ser igual nos dois, teria como deixar essas tabelas em modo de replicação automatica ?

    • eitchugo disse:

      Apesar de eu nunca ter visto alguém fazer isso, pode ser possível utilizando a opção replicate-same-server-id, assim você pode definir o servidor como slave se conectando nele mesmo. A opção serve para que mesmo com o id igual, ele vai replicar (no tutorial repare que o id do slave sempre precisa ser sempre diferente do master).

      Juntando essa opção com o replicate-do-db e replicate-do-table, talvez você consiga replicar apenas essa tabela que você quer… Mas mesmo assim não sei direito como fazer… Nesse caso, teste e nos avise o que aconteceu! :)

  16. Marcio Oliveira disse:

    Boa Noite, implemente a replicação master-master com haproxy fazendo balanceamento de conexão entres os master1 e master2 hoje deu um problema na replicação e como tem balanceamento as bases ficaram inconsistentes, como devo proceder par atualizar as bases e voltar a replicação ?

    • eitchugo disse:

      O grande problema das replicações master-master é justamente esse "split-brain", quando as duas estão funcionando, mas inconsistentes. Isso tem que ser evitado ao máximo, pois infelizmente não há uma maneira "fácil" de se consertar, e vai de problema a problema. Algumas soluções:

      - Escolher um dos bancos e refazer a replicação baseado nele (perdendo os dados do outro)
      - Analisar o que há em um que não há no outro e tentar fazer um merge das duas bases (bem dificil)
      - Olhar os logs de erro da replicação (SHOW SLAVE STATUS) ajuda em saber quais foram os itens que deram problema

      É importante saber também porque o erro de replicação aconteceu. Em teoria, mesmo um ou outro banco caindo, não deveria dar problema de split-brain pois quando a replicação voltasse a funcionar, os dados faltando teriam que ser adicionados. Não é pra dar conflito (e é justamente por isso que usamos os parametros auto-increment-increment e auto-increment-offset por exemplo).

  17. Fábio disse:

    Boa tarde Hugo, está de parabéns pelo post, porém estou com uma séria dúvida.
    Eu tenho um servidor com diversas base, e gostaria de fazer a configuração master-master sendo uma base do servidor para cada computador cliente. É possível?
    Eu tive uma solução de montar uma instância de mysql por base para que possa fazer isso, só que seria totalmente inviável ter que montar uma instância para cada base de dados no servidor.
    Poderia me dar um help?

  18. Laiton Garcia disse:

    Boa noite Hugo. Gostei de seu tutorial, muito bem explicado e didático, mas não só em seu post mas em outros vejo solicitando isso: "edite o arquivo my.cnf". Rapaz tenho meu MySQL, que gosto muito, no w7. Preciso aprender a fazer essa replicação mas não consigo justo pelo fato de não conseguir achar esse bendito arquivo para editar. Poderia ajudar de alguma forma? Desde já obrigado.

    • Robson disse:

      Olá Laiton!
      No Win7 o arquivo é my.ini.
      Exemplo: D:Program FilesMySQLMySQL Server 5.1my.ini
      Lembrando que minha instalação aqui esta com unidade D: a sua pode estar diferente.

  19. Rafael Oliveira disse:

    Olá, no artigo você diz que não é possível usar auto_increment no master-master com mais de 2 servidores. Acredito que é possível usar com N servidores. Seria configurando auto-increment-increment = N em todos os servidores e o auto-increment-offset variando de 1 até N em cada servidor.

    • eitchugo disse:

      Oi Rafael! Você tem razão, matematicamente isso faz todo o sentido! Não sei nem como não tinha pensado nisso antes :)

      Eu nunca tentei e nem vi alguém fazendo isso, mas vale a tentativa

    • Osmar Dordal disse:

      Uma duvida:

      - No Master / Slave posso ter chaves primarias em AUTO_INCREMENT o que salvar com chave 1, 2, 3, …, N no servidor Master vai salvar com chave 1, 2, 3,…, N no servidor Slave.

      - Já na configuração Master / Master se tiver as chaves primarias em AUTO_INCREMENT as chaves que serão salvas no Master_1 são na sequencia 1, 3, 5, 7,…,(N=ímpar) e no Master_2 as chaves serão com a sequencia 2, 4, 6, 8,…,(N=par)?

      • eitchugo disse:

        Isso mesmo Osmar.

        O 'increment' significa de "quanto em quantos" números ele vai incrementar. Supondo que o primeiro valor seja 1, se usarmos um increment de 2, ficaria:

        1, 3, 5, 7, 9, [...]

        Se usarmos um increment de 10, ficaria:

        1, 11, 21, 31, 42, [...]

        Pra especificar de onde começar (no exemplo acima foi o 1), a gente usa o 'offset'.

        'increment em 2, com 'offset', 2:

        2, 4, 6, 8, 10, [...]

        'increment' em 10, com 'offset' 2:

        2, 12, 22, 32, 42, [...]

  20. Wasley Almeida disse:

    Boa tarde Hugo,
    Estou com uma situação pra resolver e não sei como fazer, veja se pode me ajudar.
    Tenho uma replicação master – master, o no qual parou de funcionar. minha duvidas são:

    1 – Como descobro quando a replicação parou de funcionar?
    2 – Como reativa-la de forma que os dados voltem a ser replicado do ponto onde parou?
    3 – Você indica alguma ferramenta grafica pra monitorar a replicação?

    Desde já agradeço.

  21. Claudeir Jose disse:

    Olá Hugo, muito bom o seu post, a minha dúvida é com relação a replicação "Master – Slave", se por algum motivo o meu Slave parar e isso só foi detectado horas depois ou mesmo no final do dia por um problema de hardware(exemplo) no meu servidor de produção, é possível continuar a replicação de onde parou??? ou terá que ser refeito todo o processo de replicação??

    Desde já obrigado pela sua atenção.

  22. Liane disse:

    Muito interessante o assunto. Mas minha reclamação são essas dores. Quando tive uma crise de lombalgia, o médico me falou desse colchão magnético . Quem daqui já ouviu falar? Ouvi dizer que melhora até insonia.

Deixe uma resposta