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 Secçã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.

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.

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

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:

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 Secçã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:

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:

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.