XOOPS Brasil

 

4.11. Replicação no MySQL

Capacidades de replicação permitidindo que os bancos de dados em um servidor MySQL seja duplicado em outro foram introduzidos no MySQL versão 3.23.15. Esta seção descreve os vários recursos da replicação no MySQL. Ele serve como uma referência para as opções disponíveis na replicação. Você será introduzido a replicação e aprenderá como implementá-la. Em direção ao final, existem algumas questões mais perguntadas (FAQ), descrições de problemas e como resolvê-los.

Sugeriemos que você visite nosso website em MySQL frequentemente e leia as atualizações desta seção. A replicação esta constantemente sendo melhorada e nós atualizamos o manual frequentemente com a informação mais atual.

4.11.1. Introdução

A partir da versão 3.23.15, o MySQL suporta replicação de uma via internamente. Um servidor atua como o master, enquando o outro atua como slave. O servidor master mantêm um log binário de atualizações (see Seção 4.10.4, “O Log Binário”). É mantido também um arquivo de índices dos logs binários para manter os registro da rotatividade dos logs. Cada slave, na conexão, informa ao master onde parou desde a última atualização propagada com sucesso, realiza a atualização e então para e espera o master informar sobre novas atualizações.

Um slave também pode ser um master se você condigurar uma cadeia de servidores em replicação.

Note que se você estiver usando replicação, todas atualizações nas tabelas replicadas devem ser realizadas no servidor master. Senão, você sempre deve ter cuidados para evitar conflitos entre as atualizações que os utilizadores enviam ao master e aquelas que os utilizadores enviam ao slave.

Replicação de uma via trazem benefícios de robustez, velocidade e administração do sistema:

  • A robustez é aumentada com uma configuração master/slave. No evento de problemas com o master, você pode trocar para o slave como um backup.

  • A velocidade extra é alcançada dividindo a carga das consultas dos clientes em processamento para entre os servidores master e slave, resultando em melhor tempo de resposta. Consultas SELECT podem ser enviadas para o slave para reduzir a carga do processamento das consultas do master. Consultas que modificam dados devem ainda ser enviados para o master e slave para não ficarem fora de sincronia. Esta estratégia de balancemento de carga é efetiva se consultas que não sejam de atualização dominarem, mas este é o caso normal.

  • Outro benefício de utilizar replicação é que pode-se obter backups intantâneos do sistema fazendo backups no slave em vez de fazê-los no master. Veja mais informações sobre isto na Seção 4.5.1, “Backups dos Bancos de Dados”.

4.11.2. Visão Geral da Implementação da Replicação

A replicação no MySQL baseia-se no fato do servidor master manter o registro de todas as alterações de seus bancos de dados (atualizações, deleções, etc) no log binário. (see Seção 4.10.4, “O Log Binário”). Cada servidor slave recebe do master consultas salvas no log binário, para que assim execute as mesmas consultas nos seus dados replicados.

É muito importante entender que o log binário é simplesmente um registro iniciando a partir de um ponto fixo no tempo (o momento que você habilitou o log binário). Quaisquer slaves que você configure necessitará de cópias do banco de dados do seu master como eles existiam no momento em que o log binário foi habilitado no master. Se você iniciar os slaves com dados diferentes daqueles do master quando o log binário foi iniciado, seus slaves falharão.

A seguinte tabela indica a compatibilidade de replicação master/slave entre diferentes versões do MySQL.

  MasterMasterMasterMaster
  3.23.33 e posterior4.0.04.0.14.0.3 e posterior
Slave3.23.33 e posteriorsimnãonãonão
Slave4.0.0nãosimnãonão
Slave4.0.1simnãosimnão
Slave4.0.3 e posteriorsimnãonãosim

Como regra geral, sempre é recomendado usar versões MySQL recentes, porque as capacidades de replicação estão sendo continuamente melhoradas. Com relação a versão 4.0, recomendamos usar a mesma versão para o master e o slave, com exceção de que o 4.0.2 não é recomandado para replicação.

Note qye quando você atualiza um mestre do MySQL 3.23 para o MySQL 4.0 (ou 4.1) você não deve reiniciar a replicação usando o log binário antigo da versão 3.23, porque isto infelizmente deixa o slave 4.0 confuso. A atualização pode seguramente feita deste modo, assumindo que você tenha uma mestre 3.23 para atualizar e você tenha slaves 4.0:

  1. Bloqueie todas as atualizações no mestre (FLUSH TABLES WITH READ LOCK).

  2. Espere até que todos os slaves tenham buscados todas as alterações pelo master (use SHOW MASTER STATUS no master, e SELECT MASTER_POS_WAIT() nos slaves). Então execute STOP SLAVE nos slaves.

  3. Finalize o MySQL no master e atualize o master para o MySQL 4.0.

  4. Reinicie o MySQL no master. Grave o nome <name> do log binário mais recentemente criado do master. Você pode obter o nome dos arquivos executando SHOW MASTER STATUS no master. Então envie estes comando em cada slave:

    mysql> CHANGE MASTER TO MASTER_LOG_FILE='<name>', MASTER_LOG_POS=4;
    mysql> START SLAVE;
    

Se você também deve atualizar seus slaves da versão 3.23 para 4.0, você deve primeiro atualizar seus slaves: Desligue cada um, atualize-os e os reinicie. Então atualize o master como descrito.

A partir da versão 4.0.0, pode se usar LOAD DATA FROM MASTER para configurar um escrao. Esteja certo que LOAD DATA FROM MASTER funciona atualmente apenas se todas as tabelas no master são do tipo MyISAM. Além disso, estas instrução irão adquirir lock global de leitura, assim nenhuma escrita será possível enquanto as tabelas estão sendo transferidas do master. Quando implementarmos hot backup de tabelas sem lock (no MySQL 5.0), este lock global de leitura não será mais necessário.

Devido a estas limitações, recomendamos que você só use LOAD DATA FROM MASTER se o conjunto de dados de master for relativamente pequeno, ou se um lock de leitura prolongado no master é aceitável. Enquanto a velocidade atual do LOAD DATA FROM MASTER pode variar de sistema para sistema, uma boa regra do dedão de quanto tempo será necessário é considerar 1 segundo por 1 MB do arquivo de dados. Você ficará próximo da estimativa se tanto o master quanto o slave forem equivalentes a um Pentium 700 Mhz e estiverem conectado a uma rede de 100 MBits/s. É claro, esta é apenas uma estimativa grosseira da ordem de magnitude.

Uma vez que o slave foi configurado corretamente e está em execução, ele simplesmente conectará ao master e esperará por atualizações nos processos. Se o master for desligado ou o slave perder conectividade com seu master, ele tentará conectar periodicamente até conseguir reconectar e constinuar as atualizações. O intervalo de tentativa é controlado pela opção --master-connect-retry. O padrão é 60 segundos.

Cada slave mantêm registro de onde parou. O servidor master não tem conhecimento de quandos slaves existem ou quais estão atualizados em um determinado momento.

4.11.3. Detalhes de Implementação da Replicação

Três threads estão envolvidas na replicação: uma no master e duas no slave. Quando START SLAVE é executado, a thread de E/S é criada no slave. Ela se conecta ao master e pede pelo envio de seus logs binários. Então uma thread (chamada Binlog dump no SHOW PROCESSLIST no master) é criada no master para enviar estes logs binários. A thread de E/S lê o que o Binlog dump envia e simplesmente a copia para algum arquivo local no diretorio de dados do slave chamado relay logs. A última thread, a thread de SQL, é criada no slave; ela lê o relay logs e executa as consultas contidas nele.

Note que o master tem uma thread para cada servidor slave atualmente conectado.

Com SHOW PROCESSLIST você pode saber o que está acontecendo no master e no slave em relação a replicação.

O exemplo seguinte ilustra como as três threads aparecem em SHOW PROCESSLIST. O formato da saída é aquele usado por SHOW PROCESSLIST a partir do MySQL versão 4.0.15, quando o conteúdo da coluna State foi alterado para ser mais significativo comparado com versões alterações.

No servidor master a saída se parece com isto:

mysql> SHOW PROCESSLIST\G
*************************** 1. row ***************************
Id: 2
User: root
Host: localhost:32931
db: NULL
Command: Binlog Dump
Time: 94
State: Has sent all binlog to slave; waiting for binlog to be updated
Info: NULL

No servidor slave, a saída se parece com isto:

mysql> SHOW PROCESSLIST\G
*************************** 1. row ***************************
Id: 10
User: system user
Host:
db: NULL
Command: Connect
Time: 11
State: Waiting for master to send event
Info: NULL
*************************** 2. row ***************************
Id: 11
User: system user
Host:
db: NULL
Command: Connect
Time: 11
State: Has read all relay log; waiting for the slave I/O thread to update it
Info: NULL

Aqui a thread 2 está no master. A thread 10 é a thread de E/S no slave. A thread 11 é a thread de SQL no slave; note que o valor na coluna Time pode dizer quando o slave é comparado com o master (see Seção 4.11.9, “FAQ da Replicação”).

A lista a seguir mostra os estados mais comuns que você verá na coluna State para a thread Binlog Dump do master. Se você não ver estas threads em um servidor master, a replicação não está sendo executada.

  • Sending binlog event to slave

    Logs binários consistem de eventos, onde um evento é normamente uma consulta mais alguma informação. A thread lê um evento do log binário e ele é enviado para o slave.

  • Finished reading one binlog; switching to next binlog

    A thread finalizou a leitura de um log binário e está abrindo o seguinte a ser enviado para o slave.

  • Has sent all binlog to slave; waiting for binlog to be updated

    A thread leu todos os log binários e está inativa. Ela está esperando por conexões no master para gravar mais dados no log binário, se ele quiser.

  • Waiting to finalize termination

    Estado muito breve que ocorre quando a thread para.

Aqui estão os estados mais comuns que você verá na coluna State para a thread de E/S de um servidor slave. A partir do MySQL 4.1.1, este estado também aparece na coluna Slave_IO_State da saída de SHOW SLAVE STATUS. Isso significa que você pode ter uma boa visão do que está acontecendo apenas com SHOW STATUS SLAVE.

  • Connecting to master.

    Conectando ao master.

  • Checking master version.

    Estado muito breve que ocorre um pouco depois da conexão ser estabelecida.

  • Registering slave on master.

    Estado muito breve que ocorre um pouco depois da conexão ser estabelecida.

  • Requesting binlog dump.

    Estado muito breve que ocorre um pouco depois da conexão com o master ser estabelecida. A thread envia ao master um pedido para envio do conteúdo de seu log binário, iniciando a partir do log binário requisitado e sua posição.

  • Waiting to reconnect after a failed binlog dump request.

    Se o pedido de dump do log binário falhar (devido a desconexão), a thread fica neste estado enquanto está inativa. A thread fica inativa por master-connect-retry segundos antes de uma nova tentativa.

  • Reconnecting after a failed binlog dump request.

    Então a thread tenta se conectar com o master.

  • Waiting for master to send event.

    A thread conectou e está esperando que os eventos do log binário cheguem. Isto pode demorar se o master estiver inativo. Se a espera for maior que slave_read_timeout segundos, o tempo se esgotará. Neste ponto, a thread irá considerar a conexão quebrada e fará uma nova tentativa de conexão.

  • Queueing master event to the relay log.

    A thread leu o evento e o está copiando para o ser relay log para que a thread SQL possa processá-lo

  • Waiting to reconnect after a failed master event read.

    Um erro ocorreu durante a leitura (devido a desconexão); inativo por master-connect-retry segundos antes de tentar se reconectar.

  • Reconnecting after a failed master event read.

    Então a thread tenta se reconectar. Quando a conexão é estabelecida novamente, o estado se tornará Waiting for master to send event.

  • Waiting for the slave SQL thread to free enough relay log space

    Você está usando um valor relay_log_space_limit diferente de zero e os relay logs tem crescido tanto que o seu tamanho combinado excedem este valor. A thread E/S então espera até que a thread SQL libere espaço suficiente deletando o conteúdo dos relay logs e assim poder deletar alguns arquivos de relay logs.

  • Waiting for slave mutex on exit.

    Estado muito breve que ocorre quando a thread esta parando.

Aqui estão os estado mais comuns que você verá na coluna State para a thread de SQL de um servidor slave:

  • Reading event from the relay log

    A thread leu um evento do relay log para poder processá-lo.

  • Has read all relay log; waiting for the slave I/O thread to update it

    A thread processou todos os eventos nos arquivos de relay logs e está esperando a thread de E/S gravar novos eventos no relay log.

  • Waiting for slave mutex on exit.

    Estado muito breve que ocorre quando a thread é parada.

A coluna State para a thread de E/S também podem mostrar um string de consulta. Isto indica que a thread leu um evento do relay log, extraiu a conulta dele e está a está executando.

Antes do MySQL 4.0.2, as threads de E/S e SQL eram combinadas em uma só e nenhum relay log era usado. A vantagem do uso de duas threads é que elas separam a leitura e a execução da consulta em duas tarefas independentes, e assim o trabalho de leitura da consulta não se torna lento se a execução da consulta for lento. Por exemplo, se o servidor slave não estiver em execução por um instante, a sua thread de E/S pode rapidamente buscar todos o conteúdo dos logs binários do master quando o slave iniciar, mesmo se a thread de SQL demorar e levar horas para pegar os logs. Se o slave parar antes da thread SQL executar todas as consultas buscadas, a thread de E/S terá finalmente buscado tudo e assim um cópia segura das consultas estará armazenada localmente nos relay logs do slave para execução na próxima execução do slave. Isto permite que os log binários sejam apagados no master, já que não há mais necessidade de esperar que o slave busque o conteúdo deles.

Por padrão, relay logs são nomeados usando nome de arquivos da forma host_name-relay-bin.nnn, onde host_name é o nome da máquina servidora slave e nnn é uma sequência numérica. Arquivos de relay logs sucvessivos são criados usando uma sequência de números sucessiva, começando com 001. O slave mantém registro dos relay logs em uso atualmente em um arquivo de índice. O nome de arquivo padrão dos relay logs é host_name-relay-bin.index. Por padrão estes arquivos são criados no diretório de dados do slave. O nome de arquivo padrão pode ser sobrescrito com as opções --relay-log e --relay-log-index do servidor.

Relay logs têm o mesmo formato dos logs binários, assim ele podem ser lidos com mysqlbinlog. Um relay log é automaticamente deletado pela thread de SQL tão logo não seja mais necessária (ex.: assim que tiver sido executado todos os seus eventos). Não existem comandos para deletar relay logs já que a thread SQL cuida de fazê-lo. No entanto, a partir do MySQL 4.0.14, FLUSH LOGS rotaciona os relay logs), o que irá influenciar quando a thread de SQL deletá-los.

Um novo relay log é criado sob as seguintes condições:

  • A primeira vez que a thread de E/S inicia depois que o servidor slave inicia (No MySQL 5.0, um novo relay log será criado a cada vez que a thread de E/S inicia, não apenas pela primeira vez.)

  • Uma instrução FLUSH LOGS é executada (a partir da versão 4.0.14).

  • O tamanho do relay log atual se torna muito grande. O significado de ``muito grande'' é determinado da seguinte forma:

    • max_relay_log_size, se max_relay_log_size > 0

    • max_binlog_size, se max_relay_log_size = 0 ou o MySQL é mais velho que 4.0.14

Um servidor de replicação slave cria dois arquivos pequenos no diretório de dados. Estes arquivos são chamados master.info e relay-log.info por padrão. Eles possuem informação como aquela mostrada na saída da instrução SHOW SLAVE STATUS (see Seção 4.11.8, “Instruções SQL para Controle do Servidor Slave” para uma descrição deste comando). Como imagem de discos, eles sobrevivem ao desligamento do slave. A próxima vez que o slave é reiniciado, ele pode ler estes arquivos para saber o quanto ele processou do log binário do master e do seus próprios relay logs.

O arquivo master.info é atualizado pela thread de E/S.

A correspondência entre as linhas do arquivo e as colunas mostradas por SHOW SLAVE STATUS aparece a seguir:

LinhaDescrição
1Master_Log_File
2Read_Master_Log_Pos
3Master_Host
4Master_User
5Senha (não mostrado por SHOW SLAVE STATUS)
6Master_Port
7Connect_Retry

O arquivo relay-log.info é atualizada pela thread de SQL. A correspondência entre as linhas do arquivo e as colunas mostradas por SHOW SLAVE STATUS apaerece a seguir:

LinhaDescrição
1Relay_Log_File
2Relay_Log_Pos
3Relay_Master_Log_File
4Exec_Master_Log_Pos

Quando você faz backup dos dados de seu slave, você deve fazer backup destes 2 pequenos arquivos, junto com seus relay logs pois eles são necessários para continuar a replicação depois que você restaurar os dados do slave. Se você perder os seus relay logs mas ainda tiver o arquivo relay-log.info, você pode verifclos para determinar por quanto tempo a thread de SQL executou no log binário do master. Então você pode usar CHANGE MASTER TO com as opções MASTER_RELAY_LOG e MASTER_RELAY_POS para dizer ao slave para reler os log binários a partir deste ponto. Isto exige que o log binário ainda exista no servidor master. é claro.

Se seu slave está sujeito a replicação de instruções LOAD DATA INFILE, você também deve fazer backup dos arquivos SQL_L0AD-* que podem existir no diretório que o slave utiliza para este propósito. O slave precisará destes arquivos para continuar a replicação de qualquer instrução LOAD DATA INFILE interrompido.

A localização do diretório é especificada usando a opção --slave-load-tmpdir. Seu valor padrão, se não especificado, é o valor da variável tmpdir.

4.11.4. Como Configurar a Replicação

Aqui está uma descrição rápida de como configurar uma replicação completa em seu servidor MySQL atual. Ele assume que você deseja replicar todos os bancos de dados e nunca configurou uma replicação anteriormente. Você precisará desligar seu servidor master rapidamente para completar os passos delineados abaixo.

O procedimento é gravado para a configuração de um único slave, mas você pode usá-lo para configurar vários slaves.

Este método é o modo mais direto de se configurar um slave, mas ele não é o único. Por exemplo, se você já tem uma cópia instantânea dos dados do master, e o master já tem o seu ID do servidor definido e o log binário habilitado, você pode configurar um slaver sem desligar o master ou mesmo bloquear suas atualizações. Para maiores detalhes, veja Seção 4.11.9, “FAQ da Replicação”.

Se você deseja administrar uma configuração de replicação MySQL, sugerimos que leia todo este capítulo e experimente todos os comandos mencionados em Seção 4.11.7, “Instruções SQL para Controle do Servidor Master” e Seção 4.11.8, “Instruções SQL para Controle do Servidor Slave”. Você também deve se familiarizar com as opções de inicialização da replicação em my.cnf na Seção 4.11.6, “Opções de Inicialização da Replicação”.

Note que este procedimento e algumas das instruções SQL da replicação em seções posteriores se referrem ao privilégio SUPER. Antes do MySQL 4.0.2, use o privilégio PROCESS.

  1. Certifique-se que você possui uma versão recente do MySQL instalado no servidor master e no(s) slave(s), e que estas versões sào compatíveis de acordo com a tabela mostrada em Seção 4.11.2, “Visão Geral da Implementação da Replicação”.

    Por favor não relate os erros até que você tenha verificado que o problema está presente na última distribuição.

  2. Configure uma conta no servidor master com o com a qual o slave possa se conectar. Deve ser dada a esta conta o privilégio REPLICATION SLAVE. (Se a versão do MySQL for anterior a 4.0.2, de à conta o privilégio FILE.) Se a conta é somente para a replicação (o que é recomendável), então você não precisará fornecer nenhum privilégio adicional para ele.

    O nome de máquina no nome da conta deve ser aquele usado por cada um dos servidores slaves para conectar ao master. Por exemplo, para criar um utilizador chamado repl que pode acessar seu master de qualquer máquina, você deve utilizar este comando:

    mysql> GRANT REPLICATION SLAVE ON *.* TO repl@'%' IDENTIFIED BY '<password>';
    

    Para versões do MySQL anteriores a 4.0.2, use este comando:

    mysql> GRANT FILE ON *.* TO repl@'%' IDENTIFIED BY '<password>';
    

    Se você planeja usar as instruções LOAD TABLE FROM MASTER ou LOAD DATA FROM MASTER a partir da máquina slave, você precisará de permissão para esta conta adicional.

    • Conceda a conta os privilégios globais SUPER e RELOAD.

    • Conceda o privilégio SELECT em todas as tabelas que você deseja carregar. Qualquer das tabelas master nas quais a conta não possa fazer um SELECT serão ignoradas por LOAD DATA FROM MASTER.

  3. Se você estiver usando tabelas MyISAM, descarregue todas as tabelas e bloqueie as consultas de escrita executando o comando FLUSH TABLES WITH READ LOCK

    mysql> FLUSH TABLES WITH READ LOCK;
    

    e faça uma cópia de todos os dados existentes em seu servidor master.

    A maneira mais fácil de fazer isto é simplesmente usar um programa (tar no Unix, PowerArchiver, WinRAR, WinZip ou qualquer outro software similar no Windows) para produzir um arquivo de banco de dados no diretório de dados do seu master. Por exemplo, para usar tar que cria um arquivo que inclui todos os bancos de dados, altere a localização no diretório de dados do servidor master, e então execute este comando:

    shell> tar -cvf /tmp/mysql-snapshot.tar .
    

    Se você quiser que o arquivo inclua apenas um banco de dados chamado estebd, utilize este comando:

    shell> tar -cvf /tmp/mysql-snapshot.tar ./this_db
    

    Então copie o arquivo para o diretório /tmp na máquina servidora slave. Naquela máquina, altere a localização em um diretório de dados do slave e desempacote o arquivo usando este comando:

    shell> tar -xvf /tmp/mysql-snapshot.tar
    

    Você pode não desejar replicar o banco de dados mysql. Se não, você pode excluí-lo do arquivo. Você também não precisa incluir qualqer arquivo de log nos arquivos master.info ou relay-log.info.

    Enquanto o lock de leitura colocado por FLUSH TABLES WITH READ LOCK estiver em funcionando, leia o valor atual do nome do log binário e offset no master:

    mysql > SHOW MASTER STATUS;
    +---------------+----------+--------------+------------------+
    | File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
    +---------------+----------+--------------+------------------+
    | mysql-bin.003 | 73 | test,bar | foo,manual,mysql |
    +---------------+----------+--------------+------------------+
    1 row in set (0.06 sec)
    

    A coluna File mostra o nome do log, enquanto Position mostra o offset. No exemplo acima, o valor do log binário é mysql-bin.003 e o offset é 73. Grave os valores. Você precisará usá-los mais tarde quando estiver configurando o slave.

    Uma vez realizada a cópia e gravado o nome do log e offset, você pode reabilitar a atividade de escrita no master:

    mysql> UNLOCK TABLES;
    

    Se você estiver usando tabelas InnoDB, você deve usar a ferramente InnoDB Hot Backup que está disponível para aqueles que compraram as licenças comerciais do MySQL, suporte ou a própria ferramenta de backup. Ele faz uma cópia consistente sem fazer nenhum lock no servidor master, e grava o nome do log e o offset correspondente em um snapshot para ser usado postriormente no slave. Mais informações sobre esta ferramenta esta disponível em http://www.innodb.com/order.php.

    Sem a ferramenta Hot Backup, o modo mais rápido para tirar uma cópia das tabelas InnoDB é desligar o servidor master e copiar os arquivos e logs de dados do InnoDB e os arquivos de definição de tabela (.frm). Para gravar o nome e offset do arquivo de log atual você deve fazer o seguinte antes de desligar o servidor:

    mysql> FLUSH TABLES WITH READ LOCK;
    mysql> SHOW MASTER STATUS;
    

    E então grave o nome e offset do log da saída de SHOW MASTER STATUS como mostrado anteriormente. Uma vez gravado o nome e o offset do log, desligue o servidor sem destravar as tabelas para se certificar que ele finalizará com a cópia correspondente ao arquivo de log e offset:

    shell> mysqladmin -uroot shutdown
    

    Uma alternativa para tabelas MyISAM e InnoDB é fazer um dump SQL do master em vez de uma cópia binária como acima; para isso você pode usar mysqldump --master-data em seu master e mais tarde executar o dump SQL em seu slave. No entanto, isto é mais lento que fazer a cópia binária.

    Se o master foi executado anteriormente sem o --log-bin habilitado, os valores do nome do log e da posição mostrados por SHOW MASTER STATUS ou mysqldump estarão vazios. Neste caso, grave a string vazia ('') para o nome do log e 4 para o offset.

  4. Assegure-se que a seção [mysqld] do arquivo my.cnf no master inclui a opção log-bin. Esta seção também deve conter a opção server-id=unique number, onde master_id deve ser um valor inteiro entre 1 e 2^32 - 1. Por exemplo:

    [mysqld]
    log-bin
    server-id=1
    

    Se estas opções não estão presentes, adicione-as e reinicie o servidor.

  5. Pare o servidor que será usado como slave e adicione o seguinte ao arquivo my.cnf:

    [mysqld]
    server-id=slave_id
    

    O valor slave_id, como o valor master_id, deve ser um valor inteiro de 1 to 2^32 - 1. Adicionalmente, é muito importante que o ID do slave seja diferente do ID do master. Por exemplo:

    [mysqld]
    server-id=2
    

    Se você estiver usando vários servidores, cada um deve ter um valor server-id que seja diferente daquele do master e de cada um dos slaves. Pense nos valores de server-id como algo similar ao endereço IP: Estes IDs identificam de forma única cada instância de servidor na comunidade dos parceiros de replicação.

    Se você não quiser especificar um server-id, ele será configurado com 1 se você não tiver definido master-host, senão ele será definido com 2. Note que no caso de omissão do server-id, um master irá recusar conexões de todos os slaves e um slave irá recusar se conectar a um master. Assim, omitir server-id só é bom para backups com um log binário.

  6. Se você fizer um backup biário dos dados do servidor master, copie-o para o diretório de dados do servidor slave antes de iniciá-lo. Certifique-se que os privilégios nos arquivos e diretórios estão corretos. O utilizador com o qual o MySQL executa precisa estar apto a lê-los e alterá-los, assim como no master.

    Se você fizer um backup usando mysqldump, inicie o slave primeiro (veja o próximo passo).

  7. Inicie o servidor slave. Se ele tiver sido replicado previamente, inicie o servidor slave com a opção --skip-slave-start. Você também pode querer iniciar o servidor slave com a opção --log-warnings. Deste modo você irá obter mais mensagens sobre problemas (por exemplo, problemas de rede, ou conexão).

  8. Se você fez um backup dos dados do servidor master usando mysqldump, carregue o arquivo de dump no servidor slave:

    shell> mysql -u root -p < dump_file.sql
    
  9. Execute os seguintes comandos no slave, substutitua os valores dentro de <> com o os valores atuais relevantes ao ser sistema:

    mysql> CHANGE MASTER TO
    -> MASTER_HOST='<master host name>',
    -> MASTER_USER='<replication user name>',
    -> MASTER_PASSWORD='<replication password>',
    -> MASTER_LOG_FILE='<recorded log file name>',
    -> MASTER_LOG_POS=<recorded log offset>;
    

    A tabela a seguir lista o tamanho máximo da string para as variáveis:

    MASTER_HOST60
    MASTER_USER16
    MASTER_PASSWORD32
    MASTER_LOG_FILE255
  10. Inicie a thread slave:

    mysql> START SLAVE;
    

Depois de realizado este procedimento, o slave deve se conectar ao master e pegar todas as atualizações que ocorreram desde que o backup foi restaurado.

Se você esqueceu de configurar o server-id no master, os slaves não poderão se conectar a eles:

Se você esqueceu de configurar o server-id no slave, você irá obter o seguinte erro no arquivo de log:

Warning: one should set server_id to a non-0 value if master_host is set.
The server will not act as a slave.

Você também encontrará mensagens de erro no log de erro do slave se ele não puder replicar por qualquer motivo.

Uma vez que um slave está replicando, você encontrará um arquivo chamado master.info e um chamado relay-log.info no diretório de dados. Estes dois arquivos são usados pelo slave para manter o registro de quanto foi processado do log binário do master. Não remova ou edite o arquivo, a menos que você realmente saiba o que está fazendo e entenda as implicações. Mesmo neste caso, é mais aconselhável usar o comando CHANGE MASTER TO.

NOTA: o conteúdo de master.info sobrepõe algumas opções especificadas na lina de comando ou no my.cnf veja Seção 4.11.6, “Opções de Inicialização da Replicação” para mais detalhes.

Agora que você tem uma cópia instantânea, você pode usá-la para configurar outros slaves. Para isso siga a porção referente ao slave descrita acima. Você não precisa ter outra cópia do master.

4.11.5. Recursos de Replicação e Problemas Conhecidos

Abaixo uma explicação do que é e o que não é suportado:

  • A Replicação será feita corretamente com valores AUTO_INCREMENT, LAST_INSERT_ID e TIMESTAMP.

  • As funções USER() e LOAD_FILE() são replicadas sem alterações e não funcionarão de forma confiável no slave. Isto também é verdade para CONNECTION_ID() em versões de servidor slaves mais antigas que 4.1.1. A nova função PASSWORD() no MySQL 4.1, é bem replicada desde os masters 4.1.1; o seu slave deve ser 4.1.0 ou acima para replicá-la. Se você tem slaves mais antigos e precisa replicar PASSWORD() do seu master 4.1.x, você deve iniciar o master com a opção --old-password.

  • As variávies SQL_MODE, UNIQUE_CHECKS, SQL_SELECT_LIMIT, SQL_AUTO_IS_NULL e TABLE_TYPE não são replicados ainda. FOREIGN_KEY_CHECKS é replicado desde a versão 4.0.14.

  • Você deve uilizar o mesmo conjunto de caracteres (--default-character-set) no master e slave. Senão, você pode conseguir erros de chaves duplicadas no slave, pois uma chave que é considrada como única no conjunto de caracteres no master pode não ser único no conjunto de caracteres do slave.

  • Se você estiver usando tabelas transacionais no master e não transacionais (para as mesmas tabelas) no slave, você terá prblemas se o slave for parado no meio de um bloco BEGIN/COMMIT, já que o slave irá, mais tarde, iniciar a partir do início do bloco BEGIN. Este assunto está em nosso TODO e será corrigido em um futuro próximo.

  • Consultas de atualização que usam variáveis de utilizadores são mal replicadas nas versões 3.23 e 4.0. Isto é corrigido no MySQL 4.1. Note que nomes de variáveis de utilizadores são caso insensitivo a partir da versão 5.0, assim você deve levar isto em conta quando configurar uma replicação entre um servidor com versão 5.0 e outro com uma versão anterior.

  • O slave pode se conectar ao master usando SSL, se o master e o slave forem ambos 4.1.1 ou mais novos.

  • Embora nunca tenhamos tido casos de ocorrênciar reais, é teoricamente possível de que o dado no master e no slave podem estar diferentes se uma consulta é projetada de modo que a modificação do dado seja não determinística, p.ex. deixar a vontade do otimizados de consultas (o que geralmente não é uma boa prática, mesmo fora da replicação!). Para uma explicação detalhada Seção 1.8.6.2, “Open Bugs / Deficiências de Projeto no MySQL”.

  • Antes do MySQL 4.1.1, os comandos FLUSH, ANALYZE, OPTIMIZE e REPAIR não são armazenados no log binário e por isto não são replicados para o slave. Isto normalmente não é um problema já que estes comandos não alteram nada. Isto significa, no entanto, que se você atualizar a tabela de privilégio do MySQL diretamente sem usar a instrução GRANT e replicar o banco de dados de privilégios mysql, você deve fazer um FLUSH PRIVILEGES em seu slave para que os novos privilégios tenham efeito. Também, se você utilizar FLUSH TABLES ao renomear uma tabela MyISAM envolvida em uma tabela MERGE, você terá uqe executar FLUSH TABLES manualmente no servidor. Desde o MySQL 4.1.1, estes comandos são escritos no log binário (exceto FLUSH LOGS, FLUSH MASTER, FLUSH SLAVE, FLUSH TABLES WITH READ LOCK) a menos que você especifique NO_WRITE_TO_BINLOG (ou seu alias LOCAL). Para um exemplo da sintaxe Seção 4.6.4, “Sintaxe de FLUSH.

  • O MySQL suporta somente um master e vários slaves. Posteriormente adicionaremos um algorítimo de votação para trocar automaticamente o master se alguma coisa estiver errada com o master atual. Iremos também introduzir processos agentes para ajudar a fazer o balanceamento de carga enviando consultas SELECT para diferentes slaves.

  • Tabelas temporárias são replicadas, exceto no caso em que você desliga o servidor slave (e não apenas a thread slave), e você tem alguns tabelas temporárias replicadas e são usadas em instruções UPDATES que ainda não foram executadas no slave. (Se você desligar o slave, as tabelas temporárias necessárias por estas atualizações não estarão mais disponíveis quando o slave iniciar novamente.) Para evitar este problema, não desligue o servidor enquanto ele tiver tabelas temporárias abertas. Em vez disto, use este procedimento:

    1. Envie uma instrução STOP SLAVE.

    2. Use SHOW STATUS para verificar o valor da variável Slave_open_temp_tables.

    3. Se o valor é 0, envie um comando mysqladmin shutdown para desligar o slave.

    4. Se o valor é diferente de 0, reinicie as threads slaves com START SLAVE.

    5. Repita o procedimento anterior para ver se você terá melhor sorte na próxima vez.

    Planejamoc corrigir este problema em um futuro próximo.

  • É seguro conectar servidores em um relacionamento master/slave circular com log-slave-updates habilitado. Note, entretanto, que várias consultas não irão funcionar corretamente neste tipo de configuração a menos que o código do cliente seja escrito para tomar cuidado dos potenciais problemas que podem ocorrer em diferentes sequências em servidores diferentes.

    Isto significa que você pode fazer uma configuração parecida com o seguinte:

    A -> B -> C -> A
    

    As IDs do servidor são codificadas nos eventos do log binário. A saberá quando o evento que ele lê é foi originalmente criado por A, assim A não o executará não haverá loop infinito. Mas esta configuração circular só funcionará se você realizar atualizações não conflitantes entre as tabelas. Em outras palavras, se você insere dados em A e C, você nunca deve inserir um registro em A que pode ter uma chave confiltante com um registro em C. Você também não deve atualizar os mesmos registros em dois servidores se a ordem que a atualização é aplicada importa.

  • Se houver um erro em uma consulta no slave, a thread slave irá terminar e uma mensagem irá aparecer no log de erro do slave. Você deve então conectar a um slave manualmente, corrigir a causa do erro (por exemplo, tabela não existente), e então executar o comando sql SLAVE START.

  • Se a conexão para o master for perdida, o slave irá tentar se reconectar imediatamente. Se ele falhar, o slave irá tenatr a cada master-connect-retry segundos (padrão 60). Por causa disto, é seguro desligar o master, e então reiniciá-lo depois de um tempo. O slave também está apto para lidar com interrupções de rede. No entanto o slave notificará a a perda da rede apenas após não ter recebido dados do master por slave_net_timeout segundos. Assim se sua perda for pequena, você pode querer diminuir slave_net_timeout. Veja mais informações sobre isto na Seção 4.6.8.4, “SHOW VARIABLES.

  • Desligar o slave (corretamente) também é seguro, pois mantém sinais de onde parou. Desligamentos incorretos podem produzir problemas, especialmente se o cache de disco não foi sincronizado antes do sistema morrer. Seu sistema de tolerância a falhas será melhorado se você possuir um bom No-Break ou UPS.

  • Devido a natureza não trabnsacional das tabelas MyISAM, é possível ter uma consulta que atulizará apenas parcialmente uma taela e retornará um código de erro. Isto pode acontecer, por exemplo, em uma inserção multi-registro que tem uma violação da restrição da chave o use uma consulta de atualização é finalizada após atualizar alguns dos registros. Se isto acontecer no master, a thread slave sairá e irá esperar o DBA decidir o que fazer com isto a menos que seja autenticado e a execução da consulta resulte no mesmo código de erro. Se este comportamento da validação do código de erro não for desejável, algum (ou todos) os erros podem ser ignorados com a opção --slave-skip-errors. Ela está disponível a partir da versão 3.23.47.

  • Se você atualiza tabelas transacionais a partir de tabelas não-transacioanis dentro de um segmento BEGIN/COMMIT, a atualização no log binário pode estar fora de sincronia se algumas threads alterarem a tabela não transacional antes do commit da transação. Isto é porque a transação é escrita no log binário apenas quando é feito o commit.

  • Antes da versão 4.0.15, qualquer atualização de uma tabela não transacional é gravada no log binário imeditamente quando a atualização é feita enquanto atualizações transacionais são gravadas no COMMIT ou não gravadas se você utilizar um ROLLBACK. Você deve levar isto em conta quando atualizar tabelas transacionais e não transacionais na mesma transação e você estiver usando o log binário para backup ou replicação. Na versão 4.0.15 nós alteramos o comportamento do registro de transações que misturam atualizações de tabelas transacionais e não transacionais, que soluciona o problema (ordem das consultas boas no log binário, e todas as consultas necessárias são gravadas no log binário mesmo no caso de um ROLLBACK). O problema que permanece é quando uma segunda conexão atualiza uma tabela não transacional enquanto a primeira transação da conexão ainda não está finalizada (ordenação errada ainda pode ocorrer, porque a atualização da segunda conexão será gravada imediatamente depois de ela ter sido feita).

A seguinte tabela lista problemas na versão 3.23 que estão corrigidas na versão 4.0:

  • LOAD DATA INFILE é tratado apropriadamente desde que o arquivo ainda esteja no servidor master no momento da propagação da atualização.

  • LOAD LOCAL DATA INFILE será ignorado.

  • Na versão 3.23 RAND() em atualizações não é replicado apropriadamente. Use RAND(alguma_expr_nao_rand) se você estiver replicando atualizções com RAND(). Você pode, por exemplo, utilizar UNIX_TIMESTAMP() para o argumento de RAND(). Isto é corrigido na versão 4.0.

4.11.6. Opções de Inicialização da Replicação

Você deve utilizar a opção server-id no master e no slave para estabelecer uma ID de conexão única em cada servidor. Você deve escolher um valor único no intervalo de 1 a 2^32-1 para cada master e slave. Example: server-id=3

As opções que você pode utilizar no servidor master para controle do log binário estão todas descritas em Seção 4.10.4, “O Log Binário”.

A seguinte tabela descreve as opções que você pode utilizar nos servidores slaves. Você pode especificá-las na lina de comando ou no arquivo de opção.

NOTA: A replicação trata das seguintes opções de um modo especial:

  • --master-host

  • --master-user

  • --master-password

  • --master-port

  • --master-connect-retry

Se não existir nenhum arquivo master.info quando o servidor slave inicia, ele usa valores específicados no arquivo de opções ou na linha de comando. Isto irá ocorrer quando você iniciar o servidor como um slave de replicação pela primeira vez, ou você executar RESET SLAVE e desliga e reiniciar o servidor slave.

No entanto, se o arquivo master.info existe quando o servidor slave iniciar, ele usa o valor no arquivo e IGNORA qualquer valor especificado para aquelas opções no arquivo de opção ou na linha de comando.

Suponha que você especifique esta opção em seu arquivo my.cnf:

[mysqld]
master-host=this_host

A primeira vez que você iniciar o servidor como um slave de replicação, ele irá ler e usar a opção do arquivo my.cnf. O servidor gravará então aquele valor no arquivo master.info. A próxima vez que você iniciar o servidor, ele irá ler o valor da máquina master a partir do arquivo master.info. Se você modificar o arquivo my.cnf para especificar uma máquina master diferente, ele não terá efeito. Você deve usar CHANGE MASTER TO.

A partir do MySQL 4.1.1, as seguintes opções também é tratada de forma especial:

  • --master-ssl

  • --master-ssl-ca

  • --master-ssl-capath

  • --master-ssl-cert

  • --master-ssl-cipher

  • --master-ssl-key

O arquivo master.info inclui os valores correspondentes a essas opções. Adicionalmente, o formato do arquivo na versão 4.1.1 inclui na sua primeira linha o número de linhas no arquivo. Se você atualizar um servidor mais antigo para a versão 4.1.1, o master.info será atualizado para o novo formato automaticamente quando o novo servidor iniciar. (Se você substituir um MySQL 4.1.1 ou mais novo por uma versão mais antiga que a 4.1.1, você deve remover a primeira linha manualmente antes de iniciar o servidor mais antigo pela primeira vez.)

Como o servidor da precedência a uma arquivo master.info existente sobre as opções de inicialização acima descrito, você pode preferir usar as opções de inicialização para estes valores, e especifique-os usando a instrução CHANGE MASTER TO. Veja mais informações sobre isto na Seção 4.11.8.1, “CHANGE MASTER TO.

Este exemplo mostra um uso mais extensivo das opções de inicialização para configurar um servidor slave:

[mysqld]
server-id=2
master-host=db-master.mycompany.com
master-port=3306
master-user=pertinax
master-password=freitag
master-connect-retry=60
report-host=db-slave.mycompany.com

The following list describes startup options for controlling replication:

  • --log-slave-updates

    Diz ao slave para registrar as atualizações feitas pela thread da SQL do slave no log binário do slave. É desligado por padrão. É claro que ele exige que ele exige que o slave seja iniciado com o log binário habilitado (opção --log-bin). --log-slave-updates é usado quando você deseja colocar diversos servidores em cadeia. Por exemplo, você pode querer uma configuração como esta:

    A -> B -> C
    

    Isto é, A é o servidor master do slave B, e B é o servidor master do slave C. Para isto funcionar, onde B é tanto uma master quanto um slave, você deve iniciar B com a opção --log-slave-updates. A e B devem ser iniciados com o log binário habilitado.

  • --log-warnings

    Fazer slave exibir mais mensagens sobre o que está sendo feito. Por exemplo, ele avisará que ele obteve sucesso em reconectar depois de uma falha de conexão/rede, o avisrá sobre cada thread slave iniciada.

    Esta opção não está limitada apenas ao uso da replicação. Ela produz avisos através de um espectro de servidores ativos.

  • --master-host=host

    Especifica o nome de máquina ou endereço de IP do master para replicação. Se esta opção não for dada, a thread slave não será iniciada. O valor em master.info tem precedência se ele puder ser lido. Provavelmemte um nome nelhor para está opção seria algo do tipo --bootstrap-master-host, mas é muito tarde para alterá-la agora.

  • --master-user=nome_utilizador

    O utilizador da conta que a thread slave usará para autenticar ao conectar ao master. A conrta deve ter o privilégio REPLICATION SLAVE (Em versões anteriores a 4.0.2 ele devia ter o privilégio FILE). Se o utilizador do master não for configurado, assume-se o utilizador teste. O valor em master.info toma precedência se puder ser lida.

  • --master-password=password

    A senha da conta com a qual a thread slave autenticará quando conectar ao master. Se não definida, um senha vazia é considerada. O valor em master.info toma precedência se puder ser lido.

  • --master-port=portnumber

    A porta que o master está escutando. Se não definifa, a configuração de compilação do MYSQL_PORT é consierada. Se você não alterou as opções do configure, ela deve ser 3306. O valor em master.info toma precedência se ele puder ser lido.

  • --master-connect-retry=seconds

    O número de segundos que a thread slave espera antes de tentar se conectar ao master no caso do master ter caído ou a conexão for perdida. O padrão é 60. O valor em master.info toma precedência se puder ser lido.

  • --master-info-file=filename

    Especifica o nome a ser usado no arquivo que o slave grava a informação sobre o master. O nome padrão é master.info no diretório de dados.

  • --master-ssl, --master-ssl-ca=file_name, --master-ssl-capath=directory_name, --master-ssl-cert=file_name, --master-ssl-cipher=cipher_list, --master-ssl-key=filename

    Estas opções são usadas para configurar um conexão de replicação segura para o servidor master usando SSL. Os seus significados são os mesmos das opções correspondentes --ssl, --ssl-ca, --ssl-capath, --ssl-cert, --ssl-cipher, --ssl-key descritas em Seção 4.4.10.5, “Opções SSL de Linha de Comando”.

    Estas opções estão operacionais a partir do MySQL 4.1.1.

  • --max-relay-log-size=#

    Para rotacionar o relay log automaticamente. Veja mais informações sobre isto na Seção 4.6.8.4, “SHOW VARIABLES.

  • --relay-log=filename

    Para especificar a localização e nome que deve ser usado os relay logs. Você pode usá-lo para ter nomes de relay logs independentes do nome de máquina, ou se o seu relay log tend a ser grande (e você não que diminuir max_relay_log_size) e você precisa colocá-los em alguma área diferente do diretório de dados, ou se você quiser aumentar a velocidade balanceando as cargas entre os discos.

  • --relay-log-index=filename

    Para especificar a localização e nome que deve ser usado para arquivo de índice dos relay logs.

  • --relay-log-info-file=filename

    Para dar outro nome a relay-log.info e/ou colocá-lo em outro diretório, diferente do diretório de dados.

  • --relay-log-purge=0|1

    Disabilita/habilita a remoção automática dos relay logs assim que ele não são mais necessários. Esta é uma variável global que ode ser alterada dinâmicamente com SET GLOBAL RELAY_LOG_PURGE=0|1. o valor padrão é 1.

    Esta opção está disponível a partir do MySQL 4.1.1.

  • --relay-log-space-limit=#

    Para colocar um limite superior no tamanho total de todos os relay logs no slave (Um valor 0 significa ``ilimitado''). Isto é útil se você tiver um disco rígido pequeno em. sua máquina slave. Quando o limite é alcançado, a thread de E/S fica em pausa (não lê o log binário do master) até que a thread de SQL tenha buscado e deletado alguns dos relay logs não utilizados. Note que este limite não é absoluto: existem casos onde a thread SQL precisa de mais eventos para poder deletar, neste caso a thread de E/S irá superar o limite até que a deleção seja possível. Se isto não for feito ela entra em deadlock (o que acontecia antes do MySQL 4.0.13). Os utilizadores não devem configurar --relay-log-space-limit para menos que duas vezes o valor de --max-binlog-size (ou --max-binlog-size se --max-relay-log-size for 0) porque neste caso há a chance de que quando a thread de E/S espera por espaço livre porque --relay-log-space-limit é excedido, a thread de SQL não tem relay log para apagar e assim não pode satisfazer a thread de E/S, forçando-a a ignorar temporariamente --relay-log-space-limit.

  • --replicate-do-table=db_name.nome_tabela

    Diz para thread slave restrigir a replicação a uma tabela específica. Para especificar mais de uma tabela, use a diretiva múltiplas vezes, uma para cada tabela. Isto funcionará para atualizações através de bancos de dados, em contraste com --replicate-do-db. Por favor, leia as notas que seguem esta lista de opções

  • --replicate-ignore-table=db_name.nome_tabela

    Diz a thread slave para não replicar qualquer comando que atualiza a tabela especificada (mesmo se qualquer outra tabela puder ser atualizada pelo mesmo comando). Para especificar mais de uma tabela a ser ignorada, use a diretiva várias vezes, para cada tabela. Isto funcionará para atualizações através de bancos de dados, em contraste com --replicate-ignore-db. Por favor, leia as notas que seguem esta lista de opções

  • --replicate-wild-do-table=db_name.nome_tabela

    Diz a thread slave para restringir a replicação a consultas onde qualquer das tabelas atualizadas correspondam a padrão de meta caracteres especificado. Para especificar mais de uma tabela, use a diretiva vária vezes, uma para cada tabela, Isto funciona para atualizações através de banco de dados. Por favor, leia as notas que seguem esta lista de opções

    Exemplo: --replicate-wild-do-table=foo%.bar% replicará apenas atualizações que usam uma tabela em qualquer banco de dadis que comece com foo e cujos nomes de tabelas comecem com bar.

    Note que se você fizer --replicate-wild-do-table=foo%.% então a regra será propagada para CREATE DATABASE e DROP DATABASE, ex.: estas duas instruções serão replicadas se o nome de banco de dados corresponder ao padrão do banco de dados ('foo%' aqui) (testa mágica é possível por '%' ser o padrão da tabela).

    Caracteres curingas _ e % escapados: se você quiser replicar, por exemplo, todas as tableas do banco de dados my_own%db (este é o nome exato do banco de dados), e não replicar tabelas do banco de dados my1ownAABCdb, você deve escapar o _ e %: você deve usar algo como isto: replicate-wild-do-table=my\_own\%db. E se você estiver especificando esta opção para a linha de comando, dependendo do seu sistema, você precisará escapar o \ (por exemplo, com uma shell bash, você precisaria digitar --replicate-wild-do-table=my\\_own\\%db).

  • --replicate-wild-ignore-table=db_name.nome_tabela

    Diz a thread slave pra não replicar um consulta onde qualquer tabela corresponda ao padrão de meta caracteres dado. Para especificar mais de uma tabela, use a diretiva várias vezes, uma vez para cada tabela. Isto funcionará para atualizações através de banco de dados. Por favor, leia as notas que seguem esta lista de opções

    Exemplo: --replicate-wild-ignore-table=foo%.bar% não atualizará tabelas no banco de dados que iniciar com foo e cujo os nomes de tabela iniciem com bar.

    Note que se você fizer --replicate-wild-ignore-table=foo%.% então a regra será propagada para CREATE DATABASE e DROP DATABASE, ex. estas duas instruções não serão replciadas se o nome do banco de dados não corresponder ao padrão ('foo%' aqui) (esta mágica ocorre devido ao '%' como padrão da tabela).

    Caracteres curingas _ e % escapados: veja as anotações na descrição de replicate-wild-do-table logo acima.

  • --replicate-do-db=nome_bd

    Diz ao slave para restringir a replicação a comandos onde o banco de dados atual (p.ex., aquele selecionado por USE) é nome_bd. Para especificar mais de uym banco de dadosm use a diretiva várias vezes, uma vez por tabela. Note que isto não replicará consultas entre bancos de dados tais como UPDATE algum_bd.alguma_tabela SET foo='bar' se for selecionado outro banco de dados ou nenhum banco de dados. Se você precisa que atualizações entre bancos de dados funcionem, certifique-se de que você tem o MySQL 3.23.28 ou posterior, e use --replicate-wild-do-table=db_name.%. Por favor, leia as notas que seguem esta lista de opções

    Exemplo do que não funciona como você espera: se o slave é iniciado com --replicate-do-db=sales, e você faz USE prices; UPDATE sales.january SET amount=amount+1000;, esta consulta não será replicada.

    Se você precisar que atualizações entre bancos de dados funcionem, use --replicate-wild-do-table=db_name.%.

    A principal razão para este comportamento de apenas verificar o banco de dados atual é que é difícil para um comando sozinho saber se deve ser replicado ou não; por exemplo se você está usando comandos delete ou update multi-tabelas que continuam entre múltiplos bancos de dados. Também é muito mais rápido verificar apenas o banco de dados atual.

  • --replicate-ignore-db=nome_bd

    Diz ao slave para não replicar qualquer comando onde o banco de dados atual (p.ex. o selecionado por USE) é nome_bd. Para especificar mais bancos de daods use a diretiva diversas vezes, uma para cada banco de dados. Você não deve utilizar esta diretiva se você está usando atualização através de tabelas e você não quer que estas atualizações sejam replicadas. Por favor, leia as notas que seguem esta lista de opções

    Exemplo do que não funcionaria como esperado: se o slave é iniciado com --replicate-ignore-db=sales, e você faz USE prices; UPDATE sales.january SET amount=amount+1000;, esta consulta será replicada.

    Se você precisar de atualizações entre banco de dados funcione, use --replicate-wild-ignore-table=db_name.%.

  • --replicate-rewrite-db=de_nome->para_nome

    Diz ao slave para traduzir o banco de dados atual (p.ex. aquele selecionado por USE) para para_nome se ele era de_nome no master. Apenas instruções envolvendo a tabela podem ser afetadas (CREATE DATABASE, DROP DATABASE não poderão), e apenas se de_nome era o banco de dados atual no master. Isto não funcionará para atualizações entre banco de dados. Note que a translação é feita antes das regras de --replicate-* serem testadas.

    Exemplo: replicate-rewrite-db=master_db_name->slave_db_name

  • --report-host=host

    O Nome de máquina ou número IP do slave a ser relatado ao master durante o registro do slave. Aparecerá na saída de SHOW SLAVE HOSTS. Deixe indefinido se você não quiser que o slave se registre no master. Note que ele não é suficiente para o master simplesmente ler o número IP do slave fora dos sockets uma vez que o slave se conecte. Devido ao NAT e outros assuntos de roteamento,a quele IP pode não ser válido para se conectar ao slave a partir do master ou outras máquinas.

    Esta opção está disponível a partir do MySQL 4.0.0.

  • --report-port=portnumber

    Porta para conexão do slave relatado ao master durante o registro do slave. Defina-o apenas se o slave está escutando por uma porta diferente da padrão ou se você tiver um tunel especial do master ou outros clientes para o slave. Se não tiver certeza, deixe esta opção indefinida.

    Esta opção está disponível a partir do MySQL 4.0.0.

  • --skip-slave-start

    Diz ao servidor slave para não iniciar a thread slave na iicialização do servidor. O utilizador pode iniciá-las mais tarde com START SLAVE.

  • --slave_compressed_protocol=#

    Se 1, usa compactação no protocolo cliente/servidor se tanto o slave quanto o mester suportá-la.

  • --slave-load-tmpdir=filename

    Esta opção é igual ao valor da variável tmpdir por padrão. Quando a thread SQL do slave replica um comando LOAD DATA INFILE, ele extrai os arquivos a serem carregados do relay logs em arquivos temporários, e então os carrega dentro da tabela. Se o arquivo carregado no master era enorme, os arquivos temporários no slave também serão enormes; embora você possa desejar que o slave coloque o arquivo temporário em algum disco grande diferente de tmpdir, usando esta opção. Nestes caso, você também pode usar a opção --relay-log, já que os relay logs serão grandes também. --slave-load-tmpdir deve apontar para o sistema de arquivo baseado em disco; não em um baseado em memória. Como o slave precisa de arquivos temporários usados para replicar LOAD DATA INFILE) para sobreviver a uma reinicialização da máquina.

  • --slave-net-timeout=#

    Número de segundos a esperer por mais dados do master antes de abortar a leitura, considerando o quebra de conexão e as tentativas de reconectar. A primeira vez ocorre imediatamente depois do tempo limite. O intervalo entre tentativas é controlado pela opção --master-connect-retry.

  • --slave-skip-errors= [err_code1,err_code2,... | all]

    Diz ao a thread SQL do slave para continuar a replicação quando uma consulta retornar um erro de uma lista fornecida. Normalmente, a replicação irá parar ao encontrar um erro, dando ao utilizador a chance de resolver a inconsistêncian nos dados manualmente. Não use esta opção a menos que você saiba exetamente o motivo dos erros. Se não houver erros em sua configuração da replicação e programas clientes, e não houver erros no MySQL, você nunca deve ter uma replicação abortada com erro. O uso indiscriminado desta opção resultará em slaves fora de sincronia com o master e você não terá idéia de como o problema aconteceu.

    Para códigos de erros, você deve usar o número fornecido pela mensagem de erron no seu log de erros do slave e na saída de SHOW SLAVE STATUS. Uma lista completa de mensagens de erro podem ser encontradas na distribuição fonte em Docs/mysqld_error.txt. Os códigos de erros do servidor também são listados em Seção 13.1, “Erros Retornados”.

    Você também pode (mas não deve) usar um valor não recomendado de all o que irá ignorar todas as mensagens de erro e continua em frente indiferentemente. Não é preciso dizer, que se você usar isto, não podemos garantir a integridade dos seus dados. Por favor, não reclame se seus dados no slave não estiver nem próximo daqueles em seu master neste caso --- você foi avisado.

    Exemplos:

    --slave-skip-errors=1062,1053
    --slave-skip-errors=all
    

Algumas destas opções, como todas as opções --replicate-*, só podem ser definidas na inicialização do servidor slave, e não com ele ligado. Planejamos corrigir isto.

Aqui está a ordem de avaliação das regras --replicate-*, para decidir se a consulta será executada pelo slave ou ignorada por ele:

  1. Existe alguma regra --replicate-do-db ou --replicate-ignore-db?

    • Sim: teste-as como para --binlog-do-db e --binlog-ignore-db (see Seção 4.10.4, “O Log Binário”). Qual é o resultado do teste?

      • ignore a consulta: ignore-a e saia.

      • execute a consulta: não execute-a imediatamente, adie a decisão, vá para o passo abaixo.

    • Não: vá para o passo abaixo.

  2. Existe alguma regra --replicate-*-table?

    • Não: execute a consulta e saia.

    • Sim: vá para o passo abaixo. Apenas tabela que serão atualizadas serão comparadas às regras (INSERT INTO sales SELECT * from prices: apenas sales será comparada às regras). Se várias tabelas forem ser atualizadas (instruções multi-tabelas) a primeira a corresponder a regra (com ``do'' ou ``ignore'') vence (isto é, a primeira tabela é comparada a regra. se nenhuma decisão pode ser tomada a segunda tabela é compara às regras, etc).

  3. Existe alguma regra --replicate-do-table?

    • Sim: o tabela encaixa em alguma delas?

      • Sim: execute a consulta e saia.

      • Não: vá para o passo abaixo.

    • Não: vá para o passo abaixo.

  4. Existe alguma regra --replicate-ignore-table?

    • Sim: a tabela encaixa em alguma delas?

      • Sim: ignore a consulta e saia.

      • Não: vá para o passo abaixo.

    • Não: vá para o passo abaixo.

  5. Existe alguma regra --replicate-wild-do-table?

    • Sim: a tabela se encaixa em qualquer uma delas?

      • Sim: execute a consulta e saia.

      • Não: vá para o passo abaixo.

    • Não: vá para o passo abaixo.

  6. Existe alguma regra --replicate-wild-ignore-table?

    • Sim: a tabela se encaixa em qualquer uma delas?

      • Sim: ignore a consulta e saia.

      • Não: vá para o passo abaixo.

    • Não: vá para o passo abaixo.

  7. Nenhuma regra --replicate-*-table foi correspondida. Existe outra tabela para se testar com estas regras?

    • Sim: loop.

    • Não: testamos todas as tabelas a serem atualizadas, nenhuma regra foi obedecida. Existem regras --replicate-do-table ou --replicate-wild-do-table?

      • Sim: ignore a consulta e saia.

      • Não: execute a consulta e saia.

4.11.7. Instruções SQL para Controle do Servidor Master

0 replicação pode ser controlada por meio da interface SQL. Esta seção discute instruções para gerenciamento dos servidores masters de replicação. Seção 4.11.8, “Instruções SQL para Controle do Servidor Slave” discute instruções para gerenciamento dos servidores slaves.

4.11.7.1. PURGE MASTER LOGS

PURGE {MASTER|BINARY} LOGS TO 'log_name'
PURGE {MASTER|BINARY} LOGS BEFORE 'date'

Deleta todos os logs binários que estão listados no índice de log anteriores ao log ou data especificado. O log também remove da lista gravada no índice de log, e assim o log dado se torna o primeiro.

Exemplo:

PURGE MASTER LOGS TO 'mysql-bin.010';
PURGE MASTER LOGS BEFORE '2003-04-02 22:46:26';

A variante BEFORE está disponível no MySQL 4.1; este argumento de data pode estar no formato 'YYYY-MM-DD hh:mm:ss'. MASTER e BINARY são sinônimos, embora BINARY possa ser usado apenas a partir do MySQL 4.1.1.

Se você tiver um slave ativo que está atualmente lendo um dos logs que você stá tentando deletar, este comando não faz nada e falha com um erro. No entanto, se você tiver um slave ativo e apagar um dos logs que ele quiser ler, o slave não poderá replicar uma vez que ele esteja ativo. O comando é seguro para de se executar enquanto os sslaves estiverem replicando. Você não precisa de pará-los.

Você deve primeiro verificar todos os slaves com SHOW SLAVE STATUS para ver qual log eles estão lendo, e então você deve fazer uma lista dos logs no master com SHOW MASTER LOGS, encontrar o log mais novo entre todos os slaves (se todos os slaves estão atualizados, ele será o último log da lista), tirar backup de todos os logs que você está prestes a deletar (opcional) e deletar até o log alvo.

4.11.7.2. RESET MASTER

RESET MASTER

Deleta todos os logs binários listado no arquivo de índice, zerando o arquivo de índice do log binário.

Esta instrução rea chamada FLUSH MASTER antes do MySQL 3.23.26.

4.11.7.3. SET SQL_LOG_BIN

SET SQL_LOG_BIN = {0|1}

Disabilita ou habilita o log binário para a conexão do utilizador (SQL_LOG_BIN é uma variável de sessão) se o cliente conecta usando uma conta que tem o privilégio SUPER. A instrução é ignorada se o cliente não possui este privilégio.

4.11.7.4. SHOW BINLOG EVENTS

SHOW BINLOG EVENTS [ IN 'log_name' ] [ FROM pos ] [ LIMIT [offset,] row_count ]

Mostra o evento no log binário. Se você não especificar 'log_name', o primeiro log binário será exibido.

Esta instrução está disponível a partir do MySQL 4.0.

4.11.7.5. SHOW MASTER STATUS

SHOW MASTER STATUS

Fornece a informação de status no log binário do master.

4.11.7.6. SHOW MASTER LOGS

SHOW MASTER LOGS

Lista o log binário no master. Você deve usar este comando antes de PURGE MASTER LOGS para descobrir até onde você deve ir.

4.11.7.7. SHOW SLAVE HOSTS

SHOW SLAVE HOSTS

Mostra uma lista de slaves atualmente registrados com o master. Note que slaves não iniciados com a opção --report-host=slave_name não estarão visíveis nesta lista.

4.11.8. Instruções SQL para Controle do Servidor Slave

A replicação pode ser controlada por meio da interface SQL. Esta seção discute instruções para gerenciamento dos servidores slaves de replicação. Seção 4.11.7, “Instruções SQL para Controle do Servidor Master” discute instruções para gerenciamento dos servidores master.

4.11.8.1. CHANGE MASTER TO

CHANGE MASTER TO master_def [, master_def] ...
master_def =
MASTER_HOST = 'host_name'
| MASTER_USER = 'user_name'
| MASTER_PASSWORD = 'password'
| MASTER_PORT = port_num
| MASTER_CONNECT_RETRY = count
| MASTER_LOG_FILE = 'master_log_name'
| MASTER_LOG_POS = master_log_pos
| RELAY_LOG_FILE = 'relay_log_name'
| RELAY_LOG_POS = relay_log_pos
| MASTER_SSL = {0|1}
| MASTER_SSL_CA = 'ca_file_name'
| MASTER_SSL_CAPATH = 'ca_directory_name'
| MASTER_SSL_CERT = 'cert_file_name'
| MASTER_SSL_KEY = 'key_file_name'
| MASTER_SSL_CIPHER = 'cipher_list'

Altera os parâmetros que o servidor slave usa para conectar e comunicar com o servidor master. Os valores possíveis para o valor master_def estão mostrados acima.

As opções do relay log (RELAY_LOG_FILE e RELAY_LOG_POS) estão disponíveis a partir do MySQL 4.0.

As opções SSL (MASTER_SSL, MASTER_SSL_CA, MASTER_SSL_CAPATH, MASTER_SSL_CERT, MASTER_SSL_KEY, e MASTER_SSL_CIPHER) estão disponíveis a partir do MySQL 4.1.1. Você pode alterar estas opções mesmo nos slaves que são compilados sem suporte a SSL. Eles serão salvos no arquivo master.info mas ignorados até que você use um servidor que tenha suporte a SSL habilitado.

Por exemplo:

mysql> CHANGE MASTER TO
-> MASTER_HOST='master2.mycompany.com',
-> MASTER_USER='replication',
-> MASTER_PASSWORD='bigs3cret',
-> MASTER_PORT=3306,
-> MASTER_LOG_FILE='master2-bin.001',
-> MASTER_LOG_POS=4,
-> MASTER_CONNECT_RETRY=10;
mysql> CHANGE MASTER TO
-> RELAY_LOG_FILE='slave-relay-bin.006',
-> RELAY_LOG_POS=4025;

MASTER_USER, MASTER_PASSWORD, MASTER_SSL, MASTER_SSL_CA, MASTER_SSL_CAPATH, MASTER_SSL_CERT, MASTER_SSL_KEY, and MASTER_SSL_CIPHER are information for the slave to be able to connect to its master. If you don't specify some of these informations, the non-specified informations will keep their old value. For example, if the password to connect to your MySQL master has changed, you just need to issue

mysql> STOP SLAVE; -- if replication was running
mysql> CHANGE MASTER TO MASTER_PASSWORD='new3cret';
mysql> START SLAVE; -- if you want to restart replication

to tell the slave about the new password; no need to specify the information which did not change (host, port, user etc).

MASTER_HOST, MASTER_PORT are the hostname or IP adress of the master host, and its TCP port. Note that if MASTER_HOST is equal to localhost, then, like in other parts of MySQL, the port may be ignored (if Unix sockets can be used for example).

Se você especificar MASTER_HOST ou MASTER_PORT, o slave assumirá que o mestre é diferente do anterior (mesmo se você especificar um valor de nost ou porta iguais ao do valor atual.) Neste caso Assim, os valores antigos do nome e posição do log binário do mestre não são mais aplicáveis, assim se você não especificar MASTER_LOG_FILE e MASTER_LOG_POS no comando, MASTER_LOG_FILE='' e MASTER_LOG_POS=4 são silenciosamente adicionados a ele.

MASTER_LOG_FILE e MASTER_LOG_POS são as coordenadas das quais a thread de E/S do slave começara a ler do master na próxima vez em que ele for iniciado. If you specify any of them, you can't specify RELAY_LOG_FILE or RELAY_LOG_POS. If none of MASTER_LOG_FILE and MASTER_LOG_POS was specified, then the last coordinates of the slave SQL thread before CHANGE MASTER was issued, are used. This ensures that replication has no discontinuity, even if the slave SQL thread was late compared to the slave I/O thread, when you just want to change, say, the password to use. This safe behaviour was introduced starting from MySQL 4.0.17 and 4.1.1. (Before these versions, the used coordinates were the last coordinates of the slave I/O thread before CHANGE MASTER was issued, which caused the SQL thread to sometimes lose some events from the master, thus breaking replication.)

CHANGE MASTER TO deleta todos os relay logs (e inicia um novo), a menos que você especifique RELAY_LOG_FILE ou RELAY_LOG_POS (neste caso os relay logs serão mantidos; desde o MySQL 4.1.1 a variável global RELAY_LOG_PURGE será definida com zero sem aviso prévio). CHANGE MASTER TO atualiza master.info e relay-log.info.

CHANGE MASTER é util para configurar um slave quando você tem a cópia do master e gravou o registro e offset no master que corresponde a cópia tirada. Você pode executar CHANGE MASTER TO MASTER_LOG_FILE='log_name_on_master', MASTER_LOG_POS=log_offset_on_master no slave depois de restaurar a cópia.

O primeiro exemplo acima (CHANGE MASTER TO MASTER_HOST='master2.mycompany.com' etc) altera as coordenadas do master e do seu log binário. Isto é quando você deseja que o slave replique o master. O segundo exemplo, usado com menos frequência, é quando o slave possui relay logs que, por alguma razão, você deseja que o slave execute novamente; para fazer isto o master não precisa estar alcançavel, você só precisa fazer CHANGE MASTER TO e iniciar a thread de SQL (START SLAVE SQL_THREAD). Você pode usar isto mesmo fora da consiguração de replicação, em um servidor standalone, slave-de-ninguém, para recuperação depois de uma falha.

Suponha que o seu servidor tenha falhado e você tenha restaurado um backup. Você deseja reexecutar o próprio log binário do servidor (não os relay logs, mas logs binários regulares), supostamente chamado myhost-bin.*. Primeiro faça uma cópia destes logs binários em alguns lugares seguros, no caso de você não seguir exatamente o procedimento abaixo e acidentalmente apagar os logs binários de servidor. Se você estiver usando o MySQL 4.1.1 ou mais novos, defina SET GLOBAL RELAY_LOG_PURGE=0 para segurança adicional. Então inicie o servidor sem log-bin, com um novo ID do servidor (diferente do anterior), com relay-log=myhost-bin (para fazer o servidor acreditar que estes logs binários regulares são relay logs) e skip-slave-start, então execute estas instruções:

mysql> CHANGE MASTER TO
-> RELAY_LOG_FILE='myhost-bin.153',
-> RELAY_LOG_POS=410,
-> MASTER_HOST='some_dummy_string';
mysql> START SLAVE SQL_THREAD;

Então o servidor irá ler e executar seus próprios logs binários, e assim conseguindo a recuperação de falhas. Uma vez que a recuperação está finalizada, execute STOP SLAVE, desligue o servidor, delete master.info e relay-log.info, e reinicie o servidor com suas opções originais. No momento, especificar MASTER_HOST (mesmo com um valor modelo) é compulsório para fazer o servidor pensar que ele é um slave, e dar ao servidor um novo ID, diferente do anterior é compulsório senão o servidor verá os eventos com seus IDs e pensará que ele está em uma configuração de replicação circular e ignora os eventos, o que é indesejado. No futuro planejamos adicionar opções para lidar com estas pequenas restrições.

4.11.8.2. LOAD DATA FROM MASTER

LOAD DATA FROM MASTER

Tira uma cópia do master para o slave. Atualiza os valores de MASTER_LOG_FILE e MASTER_LOG_POS assim o slave será iniciado replicando da posição correta. Respeitará a regras de exclusão de tabelas e bancos de dados especificadas com as opções replicate-*.

O uso desta instrução está sujeito ao seguinte:

  • Funciona apenas com tabelas MyISAM.

  • Ele adquire um lock de leitura global no master enquanto tira um instantâneo, que evita atualizações no master durante esta operação.

No futuro está planejado fazê-lo funcionar com tabelas InnoDB e remover a necessidade de lock deleitura global usando o recurso de backup online sem bloqueio.

Se você estiver carregando tabelas grandes, você pode aumentar os valores de net_read_timeout e net_write_timeout no mestre e no slave. Veja Seção 4.6.8.4, “SHOW VARIABLES.

Note que LOAD DATA FROM MASTER NÂO copia nenhuma tabela do banco de dados mysql. Isto é para tornar facil de se ter diferentes utilizadores e privilégios no master e no slave.

Esta instrução exige que o utilizador de replicação usado para se conectar ao master tenha privilégios RELOAD e SUPER no master, privilégios SELECT em todas as tabelas do master que você queira carregar. Todas as tabelas do master nas quais os utilizadores não tenham privilégio SELETC serão ignoradas pelo LOAD DATA FROM MASTER; isto ocorre porque o master irá esconde-los do utilizador: LOAD DATA FROM MASTER chama SHOW DATABASES para saber qual banco de dados do master carregar, mas SHOW DATABASES retorna apenas o banco de dados nos quais o utilizador tem algum privilégio. Veja Seção 4.6.8.1, “Recuperando Informações sobre Bancos de Dados, Tabelas, Colunas e Índices”. No lado do slave, o utilizador que executa LOAD DATA FROM MASTER deve ter permissão para apagar e criar o banco de dados e tabelas envolvidos.

4.11.8.3. LOAD TABLE tbl_name FROM MASTER

LOAD TABLE tbl_name FROM MASTER

Faz o download de uma cópia da tabela do master para o slave. Esta instrução é implementada principalmente para depuração de LOAD DATA FROM MASTER. Exige que o utilizador de replicação que é usado para conectar ao master tenha privilégios RELOAD e SUPER no master, e SELECT na tabela do master que será carregada. No lado do slave, o utilizador que envia LOAD TABLE FROM MASTER deve ter permissão para apagar e criar a tabela. Leia as anotações sobre tempo limite nadescrição de LOAD DATA FROM MASTER abaixo, elas se aplicam aqui também. Por favor, leia também as limitações de LOAD DATA FROM MASTER acima, elas também se aplicam (por exemplo, LOAD TABLE FROM MASTER só funciona com tabelas MyISAM).

4.11.8.4. MASTER_POS_WAIT()

SELECT MASTER_POS_WAIT('master_log_file', master_log_pos)

Esta é uma função, não um comando. É usada para assegurar que o slave tenha alcançado (lido e executado) uma dada posição no log binário do master. Veja Seção 6.3.6.2, “Funções Diversas” para uma descrição completa.

4.11.8.5. RESET SLAVE

RESET SLAVE

Faz o slave esquecer a sua posição de replicação no log binário do master. Esta instrução é usada para uma inicialização limpa: ela deleta os arquivos master.info e relay-log.info, todos os relay logs e inicia um novo relay log. Nota: Todos os relay logs são deletados, mesmo se não forem totalmente executados pela threads SQL do slave. (Esta é uma condição que deveria existir em um slave de replicação altamente carregado, ou se você enviasse uma instrução STOP SLAVE.) As informações de conexão armazenadas no arquivo master.info são imediatamente recarregadas com os valores especificados nas opções de inicializacão, se forem especificadas. Estas informações incluem valores como máquina master, porta do master, utilizador do master e senha do master. Se a thread SQL do slave estava no meio de uma replicação de tabelas temposrárias quando ela foi parada, e RESET SLAVE é excutado, estas tabelas temporárias replicadas são deletadas no slave.

Esta instrução era chamada FLUSH SLAVE antes do MySQL 3.23.26.

4.11.8.6. SET GLOBAL SQL_SLAVE_SKIP_COUNTER

SET GLOBAL SQL_SLAVE_SKIP_COUNTER = n

Salta os próximos n eventos do master. Útil para recuperação de paradas da replicação causada por um erro.

Esta instrução só é válida quando a thread slave não está em execução, em caso contrário, retorna um erro.

Antes do MySQL 4.0, omite a palavra chave GLOBAL da instrução.

4.11.8.7. SHOW SLAVE STATUS

SHOW SLAVE STATUS

Fornece a informação de status nos parâmetros essenciais da thread do slave. Se você utilizar esta instrução usando no cliente mysql, você pode usar o terminador \G em vez de um ponto e vírgula no fim, para conseguir um layout vertical mais legível:

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: localhost
Master_User: root
Master_Port: 3306
Connect_Retry: 3
Master_Log_File: gbichot-bin.005
Read_Master_Log_Pos: 79
Relay_Log_File: gbichot-relay-bin.005
Relay_Log_Pos: 548
Relay_Master_Log_File: gbichot-bin.005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 79
Relay_Log_Space: 552
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: 8

Dependendp da sua versão do MySQL, você pode não ver todos os campos como aqui mostrado. Alguns campos estão presentes apenas a partir do MySQL 4.1.1.

Os campos mostrados por SHOW SLAVE STATUS tem o seguinte significado:

  • Slave_IO_State

    Uma cópia da coluna State da saída de SHOW PROCESSLIST para a thread de E/S do slave; lhe dirá se está thread está tentando se conectar ao master, esperando por eventos do master, reconectando ao master, etc. Os estados possíveis estão listados em Seção 4.11.2, “Visão Geral da Implementação da Replicação”. Olhar está coluna é necessário porque, por exemplo, a thread pode estar em execução mas não tem sucesso ao tentar se conectar ao master: apenas esta coluna lhe deixará ciente do problema de conexão. Por outro lado, o estado da thread SQL não é copiada, porque as coisas são mais simples para esta thread: se ela estiver em execução, não haverá problema; se não, você encontrará o erro na coluna Last_Error (descrita abaixo).

    Este campo está presente a partir do MySQL 4.1.1.

  • Master_Host

    A máquina master atual.

  • Master_User

    O utilizador usado para conectar ao master.

  • Master_Port

    A porta atual do master.

  • Connect_Retry

    O valor atual de master-connect-retry.

  • Master_Log_File

    O nome do arquivo de log binário do master no qual a thread de E/S está lendo atualmente.

  • Read_Master_Log_Pos

    A posição até a qual a thread de E/S leu no log binário do master.

  • Relay_Log_File

    O nome do arquivo de relay log na qual a thread SQL está lendo e executando atualmente.

  • Relay_Log_Pos

    A posição até a qual a thread de SQL leu e executou neste relay log.

  • Relay_Master_Log_File

    O nome do arquivo de log binário do master no qual contém o último evento executado pela thread de SQL.

  • Slave_IO_Running

    Diz se a thread de E/S foi iniciada ou não.

  • Slave_SQL_Running

    Diz se a thread de SQL está iniciada ou não.

  • Replicate_Do_DB, Replicate_Ignore_DB

    A lista de banco de dados que foi especificado com as opções --replicate-do-db e --replicate-ignore-db.

  • Replicate_Do_Table, Replicate_Ignore_Table, Replicate_Wild_Do_Table, Replicate_Wild_Ignore_Table

    As tabelas que foram especificadas com as opções --replicate-do-table, --replicate-ignore-table, --replicate-wild-do-table, e --replicate-wild-ignore_table.

    Estes campos estão presentes a partir do MySQL 4.1.1.

  • Last_Errno

    O número de erro retornado pela consulta executada mais recentemente. Um valor 0 significa ``sem erro''.

  • Last_Error

    A mensagem de erro retonada pela consulta executada mais recentemente. Por exemplo:

    Last_Errno: 1051
    Last_Error: error 'Unknown table 'z'' on query 'drop table z'
    

    A mensagem indica que a tabela z existia no mestre e foi apagada lá, mas ela não existe no slave, assim DROP TABLE falhou no servidor. (Isto pode ocorrer se o utilizador esqueceu de copiá-la no slave ao configurá-lo).

    A string vazia significa ``sem erro''. Se o valor Last_Error não for vazio, ele também apareceria como uma mensagem no log de erro do slave. Por exemplo:

  • Skip_Counter

    O último valor usado por SQL_SLAVE_SKIP_COUNTER.

  • Exec_Master_Log_Pos

    A posição no log binário do master (Relay_Master_Log_File) do último evento executado pela thread de SQL. ((Relay_Master_Log_File,Exec_Master_Log_Pos) no log binário do master corresponde a (Relay_Log_File, Relay_Log_Pos) no relay log).

  • Relay_Log_Space

    O tamanho total de todos os relay logs existentes.

  • Until_Condition, Until_Log_File, Until_Log_pos

    O valor especificado na cláusula UNTIL da instrução START SLAVE.

    Until_Condition possui estes valores estes valorer:

    • None se nenhuma cláusula UNTIL foi especificada

    • Master se o slave estiver lendo até uma dada posição no log binário do master.

    • Relay se o slave estiver lendo até uma dada posição em seus relay logs

    Until_Log_File e Until_Log_Pos indicam o nome do arquivo de log e e posição que define o ponto no qual a thread SQL irá parar a execução.

    Estes campos estão presentes a partir do MySQL 4.1.1.

  • Master_SSL_Allowed, Master_SSL_CA_File, Master_SSL_CA_Path, Master_SSL_Cert, Master_SSL_Cipher, Master_SSL_Key

    Estes campos mostram os parâmetros SSL usado pelo slave para se conectar os master, se existirem.

    Master_SSL_Allowed possui estes valores:

    • Yes se uma conexão SSL ao master é permitida

    • No se uma conexão SSL ao master não é permitida

    • Ignored se uma conexão SSL permitida pelo servidor slave não tem suporte a SSL habilitado.

    Os valores dos outros campos correspodem ao valor das opções --master-ca, --master-capath, --master-cert, --master-cipher, e --master-key.

    Estes campos estão presentes a partir do MySQL 4.1.1.

  • Seconds_Behind_Master

    O número de segundos passados desde o último evento do master executado pela thread salve SQL. Será NULL quando nenhum evento foi executado ainda, ou depois de CHANGE MASTER e RESET SLAVE. Esta coluna pode ser usada para saber "quão atrasado está o seu slave". Funcionará mesmo se o seu master e slave não tiverem clocks idênticos.

    Estes campos estão presentes a partir do MySQL 4.1.1.

4.11.8.8. START SLAVE

START SLAVE [thread_name [, thread_name] ... ]
START SLAVE [SQL_THREAD] UNTIL
MASTER_LOG_FILE = 'log_name', MASTER_LOG_POS = log_pos
START SLAVE [SQL_THREAD] UNTIL
RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos
thread_name = IO_THREAD | SQL_THREAD

START SLAVE sem nenhuma opção inicia ambas as threads slaves. A thread de E/S lêem as consultas do servidor master e as armazena no relay logs. A thread de SQL le o relay log e executa a consulta. Note que se START SLAVE obter sucesso no inicialização da thread slave ela retornará sem qualquer erro. Mas mesmo neste caso pode ser que a thread slave iniciou e parou mais tarde (por que elas não conseguiram se conectar ao master ou leram o seu log binário ou qualquer outro problema). START SLAVE não lhe avisará sobre insto. Você deverá verifica seu arquivo log de erro do slave por mensagens de erro gerada pela thread slave, ou verificar que eles estão rodando bem com SHOW SLAVE STATUS.

A partir do MySQL 4.0.2, você pode adicionar as opções IO_THREAD ou SQL_THREAD à instrução a ser chamada quando a thread iniciar.

A partir do MySQL 4.1.1, uma cáusula UNTIL pode ser adicionada para especificar que o slave deve iniciar até que a thread de SQL alcance um determinado ponto no log binário dp master ou no relay log do slave. Quando a thread SQL alcança este ponto, ela para. Se a opção SQL_THREAD é especificada na instrução, ela inicia apenas a thread de SQL. Senão, ela inicia ambas as threads slaves. Se a thread SQL já estiver em execução, a claúsula UNTIL é ignorada e um aviso é enviado.

Com uma cláusula UNTIL, você deve especificar tanto uma nome de arquivo de log quanto uma posição. Não misture opções do master e do relay logs.

Qualquer condição UNTIL é restaurada por uma instrução STOP SLAVE subsequente, ou uma instrução START SLAVE que não incluir a cláusula UNTIL, ou um servidor reinicie.

A cláusula UNTIL pode ser útil para depurar a replicação, ou para fazer com que a replicação proceda até um pouco antes do ponto que você deseja evitar que o slave replique uma instrução. Por exemplo, se uma instrução DROP TABLE foi executada no master, você pode usar UNTIL para dizer ao slave para executar até aquele ponto, mas não depois. Para encontrar qual é o evento, use mysqlbinlog com o log do master ou o relay logs, ou usando uma instrução SHOW BINLOG EVENTS.

Se você estiver usando UNTIL para ter o processo slave replicando consultas nas seções, é recomendado que você inicie o slave com a opção --skip-slave-start para evitar que a thread de SQL execute quando o slave iniciar. É provavelmente melhor usar esta opção em um arquivo de opção em vez de usá-la na linha de comando, assim uma reinicialização inesperada do servidor não faz com que isso seja esquecido.

A instrução SHOW SLAVE STATUS inclui campos na saída que mostram o valor atual da condição UNTIL.

Este comando é chamado SLAVE START antes do MySQL 4.0.5. No momento, SLAVE START ainda é aceito para compatibilidade com versões anteriores, mas está obsoleto.

4.11.8.9. STOP SLAVE

STOP SLAVE [thread_name [, thread_name] ... ]
thread_name = IO_THREAD | SQL_THREAD

Para a thread slave. Como o START SLAVE, esta instrução pode ser usada com as opções IO_THREAD e SQL_THREAD para chamar a thread ou threads que irão parar.

Este comando é chamado SLAVE STOP antes do MySQL 4.0.5. No momento, SLAVE STOP ainda é aceito para compatibilidade com versões anteriores, mas está obsoleto.

4.11.9. FAQ da Replicação

P: Como eu configuro um slave se o master já estiver em execução e eu não quiser pará-lo?

R: Existem diversas opções. Se você tirou um backup do master em alguns pontos e gravou o nome e offset do log binário (da saída do SHOW MASTER STATUS) correspondente à cópia, faça o seguinte:

  1. Esteja certo de que o slave possuí um ID server único.

  2. Execute as seguintes instruções no slave, preenchendo os valores apropriados para cada parâmetro:

    mysql> CHANGE MASTER TO
    -> MASTER_HOST='master_host-name',
    -> MASTER_USER='master_user_name',
    -> MASTER_PASSWORD='master_pass',
    -> MASTER_LOG_FILE='recorded_log_name',
    -> MASTER_LOG_POS=recorded_log_pos;
    
  3. Execute START SLAVE no slave.

Se você já não tiver um backup do master, aqui está um modo rápido de fazê-lo de forma consistente:

  1. FLUSH TABLES WITH READ LOCK

  2. gtar zcf /tmp/backup.tar.gz /var/lib/mysql ( ou uma variação disto)

  3. SHOW MASTER STATUS - esteja certo de gravar a saída - você precisará dela mais tarde

  4. UNLOCK TABLES

Uma alternativa é tirar um dump do SQL do master em vez de uma cópia binária como acima; para isto você podee usar mysqldump --master-data em seu master e posteriormente executar este dump SQL em seu slave. Isto é, no entanto, mais lento que fazer uma cópia binária.

Não importa qual dos dois métodos você usa, mais tarde siga as instruções para o caso em que você tem uma cópia e gravou o nome e offset dos logs Você pode usar a mesma cópia para configurar diversos slaves. Uma vez que os logs binários do master estão intáctos, você pode esperar por dias ou meses para configurar um slave uma vez que você possui a cópia do master. Em teoria a lacuna de espera pode ser infinita. As duas limitações práticas é o espaço em disco do master sendo preenchido com logs antigos e a quantidade de tempo que o slave gastará para buscá-los.

Você também pode usar LOAD DATA FROM MASTER. Este é um comando conveniente que tira uma cópia, a restaurá no slave e ajustar o nome e offset do log no slave, todos de uma vez. No futuro, LOAD DATA FROM MASTER será o modo recomendado de configurar um slave. Esteja avisado, no entanto, que o lock de leitura pode ser mantido por um longo tempo se você usar este comando. Ele ainda não está implementado de forma tão eficiente quanto gostariamos. Se você tiver tabelas grandes, o método preferível neste momento ainda é com uma cópia tar local depois de executar FLUSH TABLES WITH READ LOCK.

P: O slave precisa estar conectado ao master o tempo todo?

R: Não, ele não precisa. O slave pode ser desligado ou permanecer desconectado por horas ou mesmo dias, então reconecta e busca as atualizações. Por exemplo, você pode usar uma relação master/slave sobre uma conexão dial-up que está ligada esporádicamente apenas por um curto período de tempo. A implicação disto é que a uma hora dada qualquer não temos garantias de que o slave está sincronizado com o master a menos que você tire algumas medidas especiais. No futuro, teremos a opção de bloquear o master até que pelo menos um slave esteja sincronizado.

P: Como posso saber se um slave está atrasado comparado ao master? Em outra palavras, como eu sei que o dado da última consulta replicada pelo escravo?

R: Se o slave for 4.1.1 ou mais novo, leia a coluna Seconds_Behind_Master de SHOW SLAVE STATUS. Para versão mais antigas o seguinte se aplica. Isto só é possível se a thread salve de SQL existir (p.ex. se ele for exibida em SHOW PROCESSLIST, see Seção 4.11.3, “Detalhes de Implementação da Replicação”) (no MySQL 3.23: se a thread slave existir, p.ex. e mostrada em SHOW PROCESSLIST), e se ela executou pelo menos um evento do master. Realmente, quando a thread slave de SQL executa um evento lido do master, esta thread modifica seu próprio tempo do timestamp do evento (é por isto que TIMESTAMP é bem replicado). Assim é indicado na coluna Time na saída de SHOW PROCESSLIST, o número de segundos entre o timestamp do último evento replicado e o tempo real da máquina slave. Vopcê podee usar isto para determinar a data do último evento replicado. Note que se o seu slave foi desconectado do master por uma hora e então reconectado, você poderá ver uma vlaor de 3600 na coluna Time para a thread slave de SQL em SHOW PROCESSLIST... Isto ocorreria porque o slave está executando consultas de uma hora atrás.

P: Como eu forço o master a bloquear as atualizações até que o slave as busque?

R: Use o seguinte procedimento:

  1. No master, execute estes comandos:

    mysql> FLUSH TABLES WITH READ LOCK;
    mysql> SHOW MASTER STATUS;
    

    Grave o nome do log e o offset da saída da instução SHOW.

  2. No slave, execute este comando, onde as coordenadas da replicação que são os argumentos da função MASTER_POS_WAIT() são os valores gravados nos passos anteriores:

    mysql> SELECT MASTER_POS_WAIT('log_name', log_offset);
    

    A instrução SELECT será bloqueada até que o slave alcance o arquivo de log e offset especificados. Neste ponto, o slave estará em sincronia com o master e a instrução irá retornar.

  3. No master, execute a seguinte instrução para permitir que o master comece a processar atualizações novamente:

    mysql> UNLOCK TABLES;
    

P: Sobre quais assuntos eu devo estar ciente ao configurar uma replicação de duas vias?

R: Atualmente a replicação do MySQL não suporta nenhum protocolo de locking entre master e slave para garantir a atomicidade de uma atualização distribuída (entre servidores). Em outras palavras, é possível para um cliente A fazer uma atualização para um co-master 1, e neste tempo, antes de propagar para o co-master 2, o cliente B pode fazer uma atualização para o co-master 2 que fará a atualização do cliente A funcionar diferentemente da que ele fez no co-master 1. Assim, quando a atualização do cliente A fizer a atualização para o co-master, ele produzirá tabelas que são diferentes daquelas que você tem no co-master 1, mesmo depois de todas as atualizações do co-master2 também terem sido propagadas. Por isso você não deve co-encadear dois servidores em uma replicação de duas vias, a menos que você possa assegurar que suas atualizações possem seguramente ocorrer em qualquer ordem, ou que de alguma forma você cuide de alguma forma a atualização fora de ordem no código do cliente.

Você também deve perceber que replicação de duas vias não melhorar em muito o desempenho, já que temos atualizações envolvidas. Ambos os servidores precisam fazer a mesma quantidade de atualizações cada, como se tivesse um servidor. A única diferença é que haverá uma pouco menos de contenção de lock, porque as atualizações originando em outro servidor serão serializadas em uma thread slave. mesmo assim, este benefício pode ser por atrasos de rede.

P: Como eu posso usar replicação para melhorar a performance do meu sistema?

R: Você devev configurar um servidor como master e direcionar todas as escritas para ele. Então configure tantos slaves quantos você pode comprar e instalar, e distribua as leituras entre o master e os slaves. Você também pode iniciar os slaves com --skip-bdb, --low-priority-updates e --delay-key-write=ALL para conseguir aumento de velocidade para o slave. Neste caso o slave usará tabelas MyISAM não transacionais em vez de tabelas BDB para conseguir mais velocidade.

Q: O que eu devo fazer para preparar o código do cliente em minhas próprias aplicações para usar replicação para melhora de performance?

A: Se a parte do seu código que for responsável pela acesso ao banco de dados tiver sido abstaído/modularizado apropriadamente, converte-lo para executar com uma configuração de replicação deve ser bem fácil. Apenas altere a implementação de seu acesso a banco de dados para enviar todas as escritas para o master e todas as leituras para o master e o slave. Se o seu código não tiver este nível de abstração, configurar um sistema de replicação lhe dará a oportunidade e motivação de limpá-lo. Você deve iniciar criando uma biblioteca ou módulo wrapper com as seguites funções:

  • safe_writer_connect()

  • safe_reader_connect()

  • safe_reader_query()

  • safe_writer_query()

safe_ no nome de cada função significa que a função cuidará do tratamento de todas as condições de erro.

Você pode, é claro, usar diferentes nomes para as funções. O importante é ter uma interface unificada para conexão para leitura, conexão para escrita, fazer uma leitura e fazer uma escrita.

Você deve então converter o código do seu cliente para usar a biblioteca wrapper. Este pode ser um processo doloroso e assustador a princípio, mas será gratificante a longo prazo. Todas as aplicações que usam a abordagem descrita poderão tirar vantagem de uma configuração master/slave, mesmo envolvendo vários slaves. O código será muito mais fácil de manter, e adicionar opções para soluções de problemas será trivial. Você só precisará modificar uma ou duas funções, por exemplo, para registrar quanto tempo uma consulta gastou ou qual consulta, entre todas elas, retornou um erro.

Se você já tiver escrito muito código, você pode querer automatizar a conversão de tarefas usando o utilitário replace, que vem com a distribuição padrão do MySQL, ou simplesmente escrever seu próprio script Perl. Provavelmente, o seu código segue algum padrão de reconhecimento. Se não, então talvez sejá melhor reescrevê-lo ou pelo menos colocá-lo dentro de um padrão.

Q: Quando e em quanto a replicação do MySQL pode aumentar a performance do meu sistema?

A: A replicação do MySQL é mais benéfica para um sistema com leituras frequentes e escritas infrequentes. Em teoria, usando uma configuração um mastre/vários slaves você pode escalar o sistema adicionando mais slaves até que você fique sem largura de banda na rede, ou a sua carga de atualizações cresça ao ponto que o master não possa tratá-la.

Para determinar quantos slaves você pode ter antes dos benefícios adicionados começarem a estabilzar e quanto você pode melhorar o desempenho do seu site, você precisa saber o padrão de suas consultas e determinar empiricamente (pelo benchmark) a ralação entre a taxa nas leituras (leituras por segundo, ou max_reads) e nas escritas (max_writes) em um master e um slave comum. O exemplo aqui lhe mostrará um calculo simplificado do que você pode obter com replicação para o nosso sistema hipotético.

Vamos dizer que o sistema de cargas consiste de 10% de escrita e 90% de leitura, e determinamos max_reads para ser 1200 - 2 * max_writes. Em outras palavras, nosso sistema pode fazer 1200 leituras por segundo sem nenhuma escrita, a escrita média é duas vezes mais lenta que a leitura média e a realação é linear. Vamos supor que o master e cada slave possuem a mesma capacidade, e temos 1 master e N slaves. Então temos para cada servidor (master ou slave):

leituras = 1200 - 2 * escritas (a partir do benchmark)

leituras = 9* escritas / (N + 1) (as leituras são separadas, mas a escrita deve ir para todos os servidores)

9*escritas/(N+1) + 2 * escritas = 1200

escritas = 1200/(2 + 9/(N+1)

Esta análise leva as seguintes conclusões:

  • Se N = 0 (que significa que não temos replicação) nosso sistema pode tratar 1200/11, cerca de 109, escritas por segundos (o que significa que teremos 9 vezes mais leituras devidos a natureza de nossa aplicação)

  • Se N = 1, podemos aumentar para 184 escritas por segundos.

  • Se N = 8, conseguimos 400.

  • Se N = 17, 480 escritas.

  • Eventualmente, a medida que N se aproxima de infinito (e seu orçamento de menos infinito), podemos chegar próximo a 600 escritas por segundo, aumentando o throughput do sistema em cerca de 5,5 vezes. No entanto, com apenas 8 servidores, já o aumentamos em quase 4 vezes.

Note que nossos calculos assumem uma largura de banda de rede infinita, e negligencia vários outros fatores que podiam se tornar significante em seu sistema. Em muitos casos, você pode não conseguir fazer um cálculo similar ao acima que irá predizer exatamente o que acontecerá em seus sistema se você adicionar N slaves de replicação. No entanto, responder as seguintes questões deve ajudá-lo a decidir quando e quanto a replicação aumentará a performance do seu sistema:

  • Qual a razão da leitura/escrita no seu sistema?

  • Quanto mais de carga de escrita um servidor pode tratar se você reduzir a leitura?

  • Para quantos slaves você tem largura de banda disponíovel em sua rede?

P: Como eu posso usar replicação para fornecer redundância/alta disponibilidade?

R: Com os recursos disponíveis atualmente, você teria que configurar um master e um slave (ou diversos slaves) e escrever um script que monitoraria o master para ver se ele está no ar e instruir as suas aplicações e os slaves do master a alterar no caso de falha. Sugestões:

  • Para dizer para um slave para alterar o master, use o comando CHANGE MASTER TO.

  • Um bom modo de manter sua aplicação informadas sobre a localização do master é tendo uma entrada DNS dinâmica para o master. Com bind você pode usar nsupdate para atualizar dinamicamente o seu DNS.

  • Você deve executar seus escravos com a opção --log-bin e sem --log-slave-updates. Deste modo o slave estará pronto para se tornar um master assim que você executar STOP SLAVE; RESET MASTER, e CHANGE MASTER TO em outros slaves.

    Por exemplo, considere que voceê tenha a seguinte configuração (``M'' representa o master, ``S'' o slave, ``WC'' o cliente que faz a leitura e escrita do banco de dados; clientes que fazem apenas a leitura do banco de dados bão são representadas já que elas não precisam trocar):

     WC
    \
    v
    WC----> M
    / | \
    / | \
    v v v
    S1 S2 S3
    

    S1 (como S2 e S3) é um slave executando com --log-bin e sem --log-slave-updates. Como as únicas escritas executada em S1 são aquelas replicadas de M, o log binário em S1 é empty (lembre-se, que S1 é executado sem --log-slave-updates). Então, por alguma razão, M se torna indisponível, e você quer que o S1 se torne o novo master (isto é, direciona todos os WC para S1 e faça S2 e S3 replicar em S1).

    Certifique-se que todos os slaves processaram aqulquer consulta em seus relay log. Em cada slave, execute STOP SLAVE IO_THREAD, então verifique a saída de SHOW PROCESSLIST até você ver Has read all relay log. Quando isto ocorrer para todos os slaves, eles podem ser reconfigurados para a nova configuração. Envie STOP SLAVE para todos os slaves, RESET MASTER no slave sendo promovido para master, e CHANGE MASTER nos outros slaves.

    Nenhum WC acessa M. Instru todos os WCs a direcionar as suas consultas para S1. De agora em diante, todas as consultas enviadas por WC para S1 são escritas no log binário de S1. O log binário de S1 contém exatamente todas as consultas de escrita enviada para S1 desde que M foi finalizado. Em S2 (e S3) faça STOP SLAVE, CHANGE MASTER TO MASTER_HOST='S1' (onde 'S1' é substituido pelo nome de máquina real de S1). Para CHANGE MASTER, adicione todas as informações sobre como conectar a S1 de S2 ou S3 (utilizador, senha, porta). Em CHANGE MASTER, não é necessário especificar o nome do log binário de S1 ou a sua posição: nós sabemos que ele é o primeiro log binário, na posição 4, e estes são os padrões de CHANGE MASTER. Finalmente faça START SLAVE em S2 e S3, e agora você terá isto:

     WC
    /
    |
    WC | M(indisponível)
    \ |
    \ |
    v v
    S1<--S2 S3
    ^ |
    +-------+
    

    Quando M estiver ativo novamente, você só precisa enviar a ele o mesmo CHANGE MASTER enviado a S2 e S3, assim que M se tornar um slave de S1 e pegar tudo que WC gravou enquando ele estava desativado. Agora para tornarmos M como master novamente (por exemplo, porque ela é a melhor máquina), siga os procedimentos como se S1 estivesse indisponível e M fosse o novo master; então durante o procedimento não esqueça d executar RESET MASTER em M antes de tornar S1, S2, S3 como slaves de M ou eles podem buscar escritas antigas de WC, antes da indisponibilidade de M.

Atualmente estamos trabalhando na integração de um sistema de eleição de master autmotico dentro do MySQL, mas até que ele esteja pronto, você terá que criar suas próprias ferramentas de monitoramento.

4.11.10. Problemas com Replicação

Se você tiver seguido as instruções e suia configuração de replicação não está funcionando, primeiro verifique o seguinte:

  • Verifique as mensagens no log de erros. Muitos utilizadores perderam tempo por não fazer isto cedo o suficiente.

  • O master está logando ao log binário? Verifique com SHOW MASTER STATUS. Se estiver, Position será diferente de zero. Se não, verifique que deu a opção log-bin do master e definiu o server-id.

  • O slave está executando? Faça SHOW SLAVE STATUS e verifique se os valores Slave_IO_Running e Slave_SQL_Running são ambos Yes. Se não, verifique a opção do slave.

  • Se o slave estiver rodando, ele estabeleceu uma conexão com o master? Faça SHOW PROCESSLIST, encontre as threads de E/S e SQL (see Seção 4.11.3, “Detalhes de Implementação da Replicação” para ver como é exibido), e verifique a sua coluna State. Se ela disser Connecting to master, verifique os privilégios do utilizador de replicação no master, nome de máquina do master, sua configuração de DNS, se o master está atualmente em execução e se ele está a alcance do slave.

  • Se o slave estava em execução antes mas agora parou, a razão é que normalmente algumas consultas que obtem sucesso no master falham no slave. Into nunca deve acontecer se você tiver tirado a cópia apropriada do master e nunca modificou os dados no slave fora da thread slave. Se isto ocorrer, você encontrou um erro; leia abaixo como relatá-lo.

  • Se uma consulta bem sucedida no master se recusou a executar no slave, e não parece prático fazer um nova sincronização completa do banco de dados (p.ex.: deletar o banco de dados slave e fazer uma nova cópia do master), tente o seguinte:

    • Primeiro veja se a tabela do slave estava diferente da do master. Entenda como isto aconteceu (pode ser um erro: leia o registro de alterações no manual online do MySQL como http://www.mysql.com/documentation para verificar se este é um erro conhecido e se ele já está corrigido). Então faça a tabela do slave idêntica a do master e execute START SLAVE.

    • Se o acima não funcionar ou não se aplica, tente entender se ele estaria seguro para fazer uma atualização manualmente (se necessário) e então ignorar a próxima consulta do master.

    • Se você decidiu que você pode saltar a próxima consulta, execute as seguintes instruções:

      mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = n;
      mysql> START SLAVE;
      

      O valor de n deve ser 1 se a consulta não usa AUTO_INCREMENT ou LAST_INSERT_ID(). Senão, o valor de ser 2. A razão para usarem um valor de 2 para consultas que usam AUTO_INCREMENT ou LAST_INSERT_ID() é que elas gastam dois eventos no log binário do master.

    • Tenha certeza de que você não está tendo problemas com um erro antigo atualizando para a versão mais recente.

    • Se você tem certeza que o slave iniciou perfeitamente em sincronia com o master, e que as tabelas envolvidas não foram atualizadas fora da thread slave, relate o erro.

4.11.11. Relatando Problemas de Replicação

Quando você tiver determinado que não há erro de utilizador envolvido, e a replicação ainda não funciona perfeitamente ou está instável, é hora de começar a fazer num relatório de erros. Nós precisamos do máximo de informações que você puder fornecer para conseguirmos rastrear o bug. Por favor gaste algum tempo e esforço preparando um bom relato de erro.

Se você tiver uma forma repetitível de demonstrar o problema, por favor inclua-o em nosso banco de dados de bugs http://bugs.mysql.com. Se você tem um problema de fantasma (um problema que não pode ser duplicado a sua vontade), use o seguinte procedimento:

  1. Verifique se nenhum erro de utilizador está envolvido. Por exemplo, se você atualiza o slave fora da thread slave, os dados podem ficar fora de sincronia e podem ocorrer violações de chave única nas atualizações. Neste caso a thread slave irá terminar e esperar que você limpe as tabelas manualmente para entrar em sincronia. Este não é um problema de replicação; é um problema de interferência externa que faz com que a replicação falhe.

  2. Execute o slave com as opções log-slave-updates e log-bin. Elas farão com que o registre todas as atualizações que ele receber no seu próprio log binário.

  3. Salve todas as evidências antes de restaurar o estado da replicação. Se não tivermos nenhuma informação ou apenas algum esboço, será um pouco mais difícil para rastrearmos o problema. As evidências que você deve coletar são:

    • Todos os logs binários no master

    • Todos os logs binários no slave

    • A saída de SHOW MASTER STATUS no master na hora que você descobriu o problema.

    • A saída de SHOW SLAVE STATUS no master na hora que você descobriu o problema.

    • Logs de erro no master e no slave

  4. Utilize mysqlbinlog para examinar os logs binários. A informação a seguir pode ser útil para encontrar a consulta problemática, por exemplo:

    mysqlbinlog -j pos_from_slave_status /caminho/para/log_do_slave | head
    

Uma vez que você coletou as evidências do problema fantasma, tente isolá-lo em um caso de testes separados inicialmente. Então relate o problema para http://bugs.mysql.com/ com a maior quantidade possíveis de informações.