O MySQL suporta replicação unidirecional e assíncrona. servidor atua como servidor mestre Um ou mais outros servidores atuam como servidores escravos. O servidor mestre grava atualizações em arquivos de log binários e mantém um índice dos arquivos de log para rastrear a rotação do log. Quando um escravo se conecta ao mestre, ele notifica o mestre sobre a localização da última atualização bem-sucedida que o escravo leu no log. O servidor escravo recebe todas as atualizações que ocorreram desde então, bloqueia e aguarda o servidor mestre notificar a próxima atualização.
Por que usar a replicação mestre-escravo?
1. A configuração do servidor mestre/servidor escravo aumenta a robustez. Quando algo dá errado com o servidor mestre, você pode mudar para o servidor escravo como backup.
2. Ao dividir a carga de processamento das consultas dos clientes entre o servidor mestre e o servidor escravo, você pode obter um melhor tempo de resposta do cliente. Mas não atualize nos servidores mestre e escravo ao mesmo tempo, pois isso pode causar conflitos.
3. Outro benefício de usar a replicação é que você pode usar um servidor escravo para realizar backups sem perturbar o servidor mestre. O servidor mestre pode continuar processando atualizações durante o processo de backup.
O MySQL usa 3 threads para executar funções de replicação (1 no servidor mestre e dois no servidor escravo. Quando um START SLAVE é emitido, o servidor escravo cria um thread de E/S para se conectar ao servidor mestre e deixar o servidor mestre enviar binário log O servidor mestre cria um thread para enviar o conteúdo do log binário para o servidor escravo. O thread de E/S do servidor escravo lê o conteúdo enviado pelo thread Binlog Dump do servidor mestre e copia os dados para um arquivo local no escravo. diretório de dados do servidor, ou seja, o log de retransmissão O terceiro thread é o thread SQL O servidor escravo usa esse thread para ler o log de retransmissão e executar as atualizações contidas no log para consultar a replicação que ocorreu no servidor mestre. o servidor escravo Informações
O log de retransmissão padrão usa um nome de arquivo no formato host_name-relay-bin.nnnnnn, onde host_name é o nome do host do servidor escravo e nnnnnn é o número de sequência. com 000001. Rastreie o arquivo de índice de log de retransmissão para identificar o log de retransmissão atualmente em uso. O arquivo de índice de log de retransmissão padrão é denominado host_name-relay-bin.index. tem o mesmo formato do log binário e pode ser lido com mysqlbinlog Quando o thread SQL tiver executado todos os eventos no log de retransmissão, o log de retransmissão será automaticamente excluído
do servidor e dois arquivos de status adicionais serão criados no diretório de dados.
.--master.info e relay-log.info são salvos no disco rígido e não são perdidos quando o servidor escravo é desligado. Na próxima vez que o servidor escravo for iniciado, esses arquivos serão lidos para determinar quantos binários. ele leu os logs do servidor mestre e até que ponto eles lidam com seus próprios logs de retransmissão.
Para configurar a replicação mestre-escravo:
1. Certifique-se de que a versão do MySQL instalada no servidor mestre e no servidor escravo seja a mesma. e de preferência a versão estável mais recente do MySQL
no servidor mestre. A replicação configura uma conta de conexão. Esta conta deve receber a permissão REPLICATION SLAVE. Se a conta for usada apenas para replicação (recomendado), nenhuma outra permissão precisará ser concedida
ao mysql>. GRANT REPLICATION SLAVE ON *.*
-> TO 'replication
' @'%.yourdomain.com' IDENTIFIED BY 'slavepass'
; TABLES WITH READ LOCK;
evita que o programa cliente mysql saia. Um terminal tira um instantâneo do diretório de dados do servidor principal.
shell> cd /usr/local/mysql/
shell> tar -cvf /tmp/mysql-snapshot.tar ./data
Se a conta de usuário do servidor escravo for diferente daquela do servidor mestre, você pode não querer copiar o banco de dados mysql. Neste caso, a base de dados deve ser excluída do arquivo. Você também não precisa incluir nenhum arquivo de log ou arquivos master.info ou relay-log.info no arquivo.
Quando o bloqueio de leitura definido por FLUSH TABLES WITH READ LOCK for válido (ou seja, o programa cliente mysql não sai), leia o nome do log binário atual e o valor de deslocamento no servidor principal:
mysql > SHOW MASTER STATUS
+---; --- ---------+----------+--------------+----------- --- ----+
| Arquivo | Binlog_Do_DB | Binlog_Ignore_DB
| --- --+------------------+
|
mysql-bin.003 |
--- -------+----------+--------------+------------- --- --+
A coluna Arquivo exibe o nome do log e a Posição exibe o deslocamento. Neste exemplo, o valor do log binário é mysql-bin.003 no deslocamento 73. Registre esse valor. Esses valores serão necessários posteriormente ao configurar o servidor escravo. Representam as coordenadas de replicação a partir das quais o escravo deve iniciar novas atualizações do mestre.
Se --logs-bin não estiver habilitado quando o servidor mestre estiver em execução, o nome do log e os valores de localização exibidos por SHOW MASTER STATUS estarão vazios. Neste caso, os valores que precisam ser usados ao especificar o arquivo de log e a localização do servidor escravo no futuro são strings vazias ('') e 4.
Depois de tirar o instantâneo e registrar o nome e o deslocamento do log, retorne para o meio anterior e reinicie Habilite a atividade de gravação:
mysql> UNLOCK TABLES
4. Certifique-se de que a seção [mysqld] do arquivo my.cnf no host do servidor mestre inclui uma opção log-bin. Esta seção também deve ter uma opção server-id=Master_id, onde master_id deve ser um valor inteiro positivo entre 1 e 232–1. Por exemplo:
[mysqld]
log-bin
server-id=1
Se essas opções não forem fornecidas, você deverá adicioná-las e reiniciar o servidor.
5. Pare o serviço mysqld no servidor escravo e adicione a seguinte linha ao seu arquivo my.cnf:
[mysqld]
server-id=2
O valor slave_id é igual ao valor Master_id e deve ser um número inteiro positivo entre 1 e 232 –1 valor. Além disso, o ID do servidor escravo deve ser diferente do ID do servidor mestre.
6. Salve os dados no diretório de backup. Certifique-se de que as permissões nesses arquivos e diretórios estejam corretas. O usuário sob o qual o servidor MySQL está sendo executado deve ser capaz de ler e gravar arquivos, assim como no servidor principal.
Shell> chown -R mysql:mysql /usr/local/mysql/data
7. Inicie o servidor escravo. Execute a seguinte instrução no servidor escravo, substituindo os valores das opções pelos valores reais do seu 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_position
8. Inicie a thread do servidor escravo:
mysql
> START SLAVE;
atualizações que ocorreram desde o instantâneo.
9. Caso ocorra um erro de replicação, uma mensagem de erro também aparecerá no log de erros (HOSTNAME.err) do servidor escravo.
10. Ao copiar do servidor, os arquivos master.info e HOSTNAME-relay-log.info serão encontrados em seu diretório de dados. O escravo usa esses dois arquivos para controlar quanto do log binário do mestre foi processado. Não remova ou edite esses arquivos a menos que saiba exatamente o que está fazendo e compreenda totalmente seu significado. Mesmo assim, é melhor usar a instrução CHANGE MASTER TO.