Primeiramente é necessário conhecer a diferença básica entre downtime planejado e downtime não-planejado.

Normalmente o downtime planejado acontece ao realizar-mos atualizações críticas de sistema (ie. Kernel) e alguns tipos de manutenção relacionada ao funcionamento base do sistema operacional. Este tipo de downtime deve ser sempre notificado com antecedência aos clientes que dependem do serviço e deve ser feito no menor tempo possível, apesar de não ser uma prática muito correta algumas empresas costumam não contabilizar o downtime planejado em seus relatórios de disponibilidade.

Já o downtime não-planejado normalmente acontece devido a problemas físicos no ambiente computacional, tendo entre suas principais ocorrências problemas elétricos, falhas de hardware, excesso de temperatura no ambiente, problemas de rede / telecomunicações, problemas de segurança, falhas em aplicações e no próprio sistema operacional.

Agora podemos ir ao nosso cálculo de disponibilidade (%), que nada mais é do que a disponibilidade total do serviço dentro do período de um ano, e a partir do valor obtido pode-se ter o nível real de disponibilidade para obtenção de estatísticas e SLA (marketing normalmente adora esses números!).

Os valores mais comuns de disponibilidade relacionados com downtime são:

• 98%    – 7.30 dias por ano / 14.4 horas por mês
• 99%    – 3.65 dias por ano / 7.2 horas por mês
• 99,5% – 1.83 dias por ano / 3.60 horas por mês
• 99,8% – 17.52 horas por ano / 86.23 minutos por mês
• 99.9% – 8.76 horas por ano / 43.2 minutos por mês
• 99.95% – 4.38 horas por ano / 21.56 minutos por mês
• 99.99% – 52.6 minutos por ano / 4.32 minutos por mês
• 99.999% – 5.26 minutos por ano ou 25.9 segundos por mês
• 99.9999% – 31.5 segundos por ano ou 2.59 segundos por mês

Lembrando sempre que uptime é totalmente diferente de disponibilidade!

Primeiramente realize a instalação do MySQL em ambas as máquinas, lembrando que é altamente recomendável manter a mesma versão em todos os servidores participantes do cluster, e ative o acesso a conexões TCP (vem como padrão na maior parte das distribuições). Para prosseguir com o exemplo, consideraremos que o servidor master tem o IP 192.168.0.1 com hostname Naru e o slave tem o IP 192.168.0.2 com hostname Motoko.

Adicione os seguintes parâmetros na sessão [mysqld] do/etc/my.cnf no master:

log-bin=naru-bin
log-slave-updates
server-id=1

Agora, adicione os seguintes paramêtros no [mysqld] do /etc/my.cnf no slave:

relay-log=motoko-relay-bin
master-host=192.168.0.1
master-user=replication
master-password=mypassword
server-id=2

Inicie o serviço MySQL no servidor master e adicione um usuário com permissão de replication (em nosso caso o usuário é replication e a senha é mypassword), lembrando que esse usuário será utilizado para qualquer conexão entre os servidores :

GRANT REPLICATION SLAVE ON *.* TO ‘replication’@192.168.0.2 \
IDENTIFIED BY ‘mypassword’;

Reinicie o serviço MySQL no servidor master para fixar as alterações.

Após realizar as configurações no servidor master, inicie o serviço MySQL no servidor slave e inicie o serviço de replicação com:

START SLAVE;

Para verificar o status da replicação, utilize a seguinte sintaxe no servidor slave:

SHOW SLAVE STATUS\G;

A linha related_log_files deve indicar o arquivo correspondente, e as linhas Slave_IO_Running e Slave_SQL_Running devem estar setadas para Yes. Desta forma a replicação está sendo feita normalmente.

Lembrando que as bases devem estar em sincronia para o correto funcionamento, desta forma, os dados do servidor slave não podem ser alterados diretamente. Caso tenha algum erro ao iniciar a replicação consulte o log default do MySQL, pois os dados obtidos são bem completos e de fácil entendimento.

Normalmente o principal problema que acontece em servidores que já estão sendo utilizados em produção é a falta de sincronia entre as bases, que pode ser resolvida fazendo um dump da base master e replicando para a slave sem que haja alteração dos dados durante o processo.

Caso seja necessário realizar a alteração do servidor master enquanto a máquina slave está em produção, pode-se utilizar as seguintes sintaxes:

SLAVE STOP;
CHANGE MASTER TO master_host=”<IP do servidor master>”, \ maste_log_pos=0;
SLAVE START;

* Tendo em vista que a nova máquina master já está configurada corretamente.

A replicação pode ser realizada de várias outras formas, de acordo com as necessidades de cada ambiente, porém este tutorial indica sua utilização mais simples, normalmente utilizado em sistemas de consulta onde a carga é muito alta e deve ser distribuída.