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


A replicação no MariaDB 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 "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 MariaDB.

Master Master Master Master
e posterior 4.0.0 4.0.1 e posterior
Slave e posterior sim não não não
Slave 4.0.0 não sim não não
Slave 4.0.1 sim não sim não
Slave e posterior sim não não sim

Como regra geral, sempre é recomendado usar versões MariaDB 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 MariaDB 3.23 para o MariaDB (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 MariaDB no master e atualize o master para o MariaDB 4.0.
  4. Reinicie o MariaDB 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 MariaDB 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.

Retornar