Como Configurar a Replicação

Aqui está uma descrição rápida de como configurar uma replicação completa em seu servidor MariaDB 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 "FAQ da Replicação".

Se você deseja administrar uma configuração de replicação MySQL, sugerimos que leia todo este e experimente todos os comandos mencionados em "Instruções SQL para Controle do Servidor Master" e "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 "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 MariaDB 4.0.2, use o privilégio PROCESS.

Certifique-se que você possui uma versão recente do MariaDB 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 "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.
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 MariaDB 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 usuário 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 MariaDB 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.
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 MariaDB. 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 exibe o nome do log, enquanto Position exibe 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 MariaDB, 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.
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.
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.
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 usuário com o qual o MariaDB 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).
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).
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
```

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_HOST`	60
`MASTER_USER`	16
`MASTER_PASSWORD`	32
`MASTER_LOG_FILE`	255

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 "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.

Como Configurar a Replicação

Retornar