índice
Prefácio
O seguinte conteúdo é baseado em documentos oficiais MySQL5.7
Replicação Mysql
Você pode copiar dados de um servidor de banco de dados MySQL (origem) para um ou mais servidores de banco de dados MySQL (réplicas). Por padrão, a replicação é assíncrona e tem melhor desempenho; a réplica não precisa estar permanentemente conectada para receber atualizações da origem. Dependendo da configuração, você pode copiar todos os bancos de dados no banco de dados, bancos de dados selecionados e até mesmo tabelas selecionadas.
As vantagens da replicação no MySQL incluem:
- Solução de dimensionamento horizontal - distribua a carga entre várias cópias para melhorar o desempenho. Nesse ambiente, todas as gravações e atualizações devem ser realizadas no servidor de origem de replicação (servidor primário). No entanto, a leitura pode ocorrer em uma ou mais réplicas (servidores escravos). Este modelo pode melhorar o desempenho de gravação (porque a fonte é dedicada a atualizações), enquanto pode aumentar significativamente as velocidades de leitura em mais e mais réplicas.
- Segurança de dados - como os dados foram copiados para a cópia e a cópia pode suspender o processo de cópia, os serviços de backup podem ser executados na cópia sem destruir os dados de origem correspondentes.
- Dados de análise em tempo real podem ser criados na fonte e a análise de informações pode ser realizada na cópia sem afetar o desempenho da fonte.
- Distribuição remota de dados - você pode usar a replicação para criar cópias locais de dados para uso por sites remotos sem ter que acessar permanentemente a fonte.
O MySQL 5.7 oferece suporte a diferentes métodos de replicação. Os métodos tradicionais são baseados na cópia de eventos no log binário de origem e exigem que os arquivos de log e seus locais sejam sincronizados entre a origem e a cópia. Baseado no Global Transaction Identifier (GTID) é um método mais novo, é transacional, portanto, não há necessidade de lidar com arquivos de log ou locais nesses arquivos, o que simplifica muito muitas tarefas comuns de replicação. Usar o GTID para replicação pode garantir a consistência entre a origem e a réplica, desde que todas as transações confirmadas na origem também tenham sido aplicadas à réplica.
A replicação no MySQL oferece suporte a diferentes tipos de sincronização. O tipo original de sincronização é a replicação assíncrona unidirecional, na qual um servidor atua como a origem e um ou mais servidores atuam como réplicas. Isso é contrário ao recurso de replicação síncrona do NDB Cluster. No MySQL 5.7, além da replicação assíncrona integrada, ele também oferece suporte à replicação semissíncrona. Para replicação semissíncrona, antes de retornar à sessão que realizou a transação, a confirmação é realizada no bloco de origem até que pelo menos uma réplica confirme que recebeu e registrou o evento de transação; o MySQL 5.7 também suporta replicação atrasada para que a réplica seja após o tempo especificado pela fonte Faça uma cópia. Para cenários que requerem replicação síncrona, use o NDB Cluster
Existem dois tipos principais de formatos de replicação: replicação baseada em instrução (SBR), que replica toda a instrução SQL, e replicação baseada em linha (RBR), que replica apenas as linhas alteradas. Você também pode usar o terceiro tipo de replicação híbrida híbrida (MBR).
Você pode usar a replicação para resolver muitos problemas diferentes, incluindo desempenho, suporte a backups de bancos de dados diferentes e como parte de uma solução maior para mitigar falhas do sistema.
Replicação baseada na localização do arquivo de log binário
Esta seção apresenta a replicação entre servidores MySQL com base no método de localização do arquivo de log binário. Nesse método de replicação, a instância de origem do MySQL (as alterações do banco de dados originam-se desta instância) gravam atualizações e alterações como "eventos" no log binário. As informações no log binário são armazenadas em diferentes formatos de registro de log de acordo com as mudanças registradas no banco de dados. Configure a réplica para ler o log binário da origem e executar eventos no log binário no banco de dados local da réplica.
Cada cópia recebe uma cópia de todo o conteúdo do log binário. A cópia é responsável por determinar quais instruções no log binário devem ser executadas. A menos que você especifique de outra forma, todos os eventos no log binário de origem são executados na cópia. Se necessário, a réplica pode ser configurada para processar apenas eventos que se aplicam a um banco de dados ou tabela específica.
Cada cópia registra as coordenadas do log binário: o nome do arquivo lido e processado a partir da origem e a localização do arquivo no arquivo. Isso significa que várias cópias podem ser conectadas à origem e executar diferentes partes do mesmo log binário. Como a réplica controla esse processo, é possível conectar e desconectar uma única réplica do servidor sem afetar a operação da fonte. Da mesma forma, como cada cópia registra a posição atual no log binário, a cópia pode ser desconectada, reconectada e, em seguida, retomar o processamento.
Um ID exclusivo deve ser configurado para a origem e cada réplica (usando a variável de sistema server_id). Além disso, as informações sobre o nome do host de origem, nome do arquivo de log e localização no arquivo devem ser configuradas para cada cópia. Você pode usar a instrução CHANGE MASTER TO na cópia para controlar esses detalhes na sessão MySQL.
Nota: A fonte da cópia representa o banco de dados mestre (mestre), e a cópia representa o banco de dados escravo (escravo)
Copiar configuração relacionada
A seguir apresentamos a configuração básica baseada na replicação do arquivo de log binário. Depois de lê-la, você pode saber e configurar claramente.
Defina a configuração da fonte de replicação
Para configurar a origem para usar replicação com base na localização do arquivo de log binário, você deve garantir que o log binário esteja ativado e estabelecer um ID de servidor exclusivo.
Cada servidor na topologia de replicação deve ser configurado com um ID de servidor exclusivo, que você pode especificar usando a variável de sistema server_id. Este ID de servidor é usado para identificar cada servidor na topologia de replicação e deve ser um número inteiro positivo entre 1 e (2 32) -1. Você pode alterar dinamicamente o valor de server_id emitindo a seguinte instrução:
SET GLOBAL server_id = 2;
Quando o ID do servidor padrão é 0, a origem recusa qualquer conexão da réplica e a réplica se recusa a se conectar à origem, portanto, esse valor não pode ser usado na topologia de replicação. Além disso, você pode escolher como organizar e selecionar IDs de servidor, desde que cada ID de servidor seja diferente de todos os outros IDs de servidor usados por qualquer outro servidor na topologia de replicação. Observe que se você definiu anteriormente um valor de 0 para o ID do servidor, deve reiniciar o servidor para inicializar a origem com o novo ID do servidor diferente de zero. Caso contrário, não há necessidade de reiniciar o servidor, a menos que seja necessário habilitar o log binário ou fazer outras alterações na configuração que exijam a reinicialização.
O log binário deve ser habilitado na origem porque o log binário é a base para copiar as alterações da origem para sua cópia. Se o log binário não estiver ativado na origem usando a opção log-bin, a replicação não poderá ocorrer. Para habilitar o log binário em um servidor que não foi habilitado para log binário, você deve reiniciar o servidor. Neste caso, desligue o servidor MySQL e edite o arquivo my.cnf ou my.ini. Na seção do arquivo de configuração [mysqld], adicione as opções log-bin e server-id. Se essas opções já existem, mas foram comentadas, descomente essas opções e faça as alterações necessárias. Por exemplo, para usar o prefixo do nome do arquivo de log para habilitar o registro binário mysql-bin e configurar o ID do servidor para 1, use as seguintes linhas:
[mysqld]
log-bin=mysql-bin
server-id=1
Depois de fazer as alterações, reinicie o servidor.
Nota As
seguintes opções afetam este processo:
Para obter o máximo de durabilidade e consistência nas configurações de replicação onde o InnoDB é usado com transações, ele deve ser usado no arquivo de origem
innodb_flush_log_at_trx_commit=1
和
sync_binlog=1
Certifique-se de que a variável de sistema skip_networking não esteja habilitada em sua fonte. Se esta variável estiver habilitada, a conexão de rede será desabilitada, a cópia não poderá se comunicar com a fonte e a cópia falhará.
Criar um usuário para replicação
Cada réplica precisa usar um nome de usuário e senha MySQL para se conectar à origem, portanto, deve haver uma conta de usuário na origem e a réplica pode ser usada para se conectar. Ao configurar uma cópia, o nome do usuário é especificado pela opção CHANGE MASTER TO no comando MASTER_USER. Desde que a conta tenha privilégios REPLICATION SLAVE, qualquer conta pode ser usada para esta operação. Você pode escolher criar uma conta diferente para cada cópia ou usar a mesma conta para cada cópia para se conectar à fonte.
Embora não seja necessário criar uma conta especificamente para replicação, deve-se observar que o nome de usuário e a senha de replicação são armazenados em texto simples no repositório de metadados de replicação. Portanto, você pode desejar criar uma conta separada que tenha apenas privilégios para o processo de cópia para minimizar a possibilidade de danos a outras contas.
Para criar uma nova conta, use o comando CREATE USER. Para conceder à conta os privilégios necessários para replicação, use a seguinte instrução GRANT. Se a conta for criada apenas para fins de replicação, ela precisará apenas do privilégio REPLICATION SLAVE. Por exemplo, para configurar um novo usuário, replique que o usuário pode replicar conexões de qualquer host no domínio example.com, emita a seguinte instrução na fonte:
mysql> CREATE USER 'repl'@'%.example.com' IDENTIFIED BY 'password';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%.example.com';
Obtenha as coordenadas do log binário da fonte da cópia
Para configurar a cópia para iniciar o processo de cópia no ponto correto, você precisa anotar as coordenadas atuais da fonte em seu log binário.
Se você planeja desligar a fonte para criar um instantâneo de dados, pode optar por ignorar esse processo e, em vez disso, armazenar uma cópia do arquivo de índice de log binário com o instantâneo de dados. Nesse caso, a origem criará um novo arquivo de log binário na reinicialização. Portanto, as coordenadas do log binário da origem onde a cópia deve começar a ser copiada é o início do novo arquivo, que é o próximo arquivo de log binário na origem, após o arquivo listado no arquivo de índice de log binário copiado.
Para obter as coordenadas do log binário da fonte, siga estas etapas:
1. Conecte-se à fonte usando o cliente de linha de comando para iniciar uma sessão na fonte e libere todas as tabelas e evite instruções de gravação executando a seguinte instrução FLUSH TABLES WITH READ LOCK:
mysql> FLUSH TABLES WITH READ LOCK;
Nota: FLUSH TABLES WITH READ LOCK impedirá a operação COMMIT da tabela, ou seja, impedirá o envio de operações de escrita
2. Em outra sessão na fonte, use a instrução SHOW MASTER STATUS para determinar o nome e a localização do arquivo de log binário atual:
mysql > SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 | 73 | test | manual,mysql |
+------------------+----------+--------------+------------------+
A coluna Arquivo mostra o nome do arquivo de log e a coluna Posição mostra a posição no arquivo. Neste exemplo, o arquivo de log binário é mysql-bin.000003 e a localização é 73. Registre esses valores. Você precisará deles mais tarde, ao configurar a cópia. Eles representam coordenadas copiadas das quais a cópia deve processar novas atualizações na fonte.
Se a fonte já estava rodando antes e o log binário não está habilitado, o nome do arquivo de log e valor de localização mostrado por SHOW MASTER STATUS ou mysqldump --master-data está vazio. Nesse caso, o valor que precisa ser usado ao especificar o arquivo de log de origem e a localização posteriormente é uma string vazia ('')
Agora você tem as informações para fazer a cópia começar a ler e copiar do log binário no local correto.
#Copy settings
As seções a seguir descrevem como configurar uma cópia.
1. Cada cópia deve ter um ID de servidor exclusivo especificado pela variável de sistema server_id. Se você deseja configurar várias réplicas, cada réplica deve ter um valor server_id exclusivo, que deve ser diferente da réplica de origem e de quaisquer outras réplicas. Se o ID do servidor do servidor de réplica não tiver sido definido ou se o valor atual estiver em conflito com o valor selecionado para o servidor de origem ou outros servidores de réplica, você deverá alterá-lo. O valor server_id padrão é 0, o que significa que a réplica se recusa a se conectar à origem.
Você pode alterar dinamicamente o valor de server_id emitindo a seguinte instrução:
SET GLOBAL server_id = 21;
Se server_id tiver definido anteriormente o valor padrão como 0, o servidor deve ser reiniciado para inicializar a réplica com o novo ID de servidor diferente de zero. Caso contrário, não será necessário reiniciar o servidor ao alterar o ID do servidor, a menos que faça outras alterações na configuração que o requeiram. Por exemplo, se o log binário estiver desabilitado no servidor e você quiser habilitar o log binário na cópia, será necessário reiniciar o servidor para habilitar esse recurso.
Se você deseja desligar o servidor de réplica, você pode editar a seção [mysqld] do arquivo de configuração para especificar um ID de servidor único. Por exemplo:
[mysqld]
server-id=21
A cópia pode ser replicada sem habilitar o log binário. No entanto, os registros binários da cópia podem ser usados para backup de dados e recuperação de falhas. As réplicas com registro binário ativado também podem ser usadas como parte de topologias de replicação mais complexas. Se você deseja habilitar o log binário na réplica, configure a opção log-bin na seção [mysqld] do arquivo de configuração. O servidor precisa ser reiniciado para iniciar o log binário em um servidor que não tenha sido usado antes.
2. Defina a configuração de origem no servidor de réplica
Para configurar a réplica para se comunicar com a fonte de replicação, configure as informações de conexão necessárias para a réplica. Para fazer isso, execute a seguinte instrução na cópia, substituindo o valor da opção pelo valor real relacionado ao sistema:
mysql> CHANGE MASTER TO
-> MASTER_HOST='source_host_name',
-> MASTER_USER='replication_user_name',
-> MASTER_PASSWORD='replication_password',
-> MASTER_LOG_FILE='recorded_log_file_name',
-> MASTER_LOG_POS=recorded_log_position;
3. Inicie o thread de replicação:
mysql> START SLAVE;
Depois de executar esse processo, o servidor de réplica se conectará à origem e copiará o instantâneo obtido por si mesmo em todas as atualizações que ocorreram na origem.