O MySQL não limita o número de escravos que você pode conectar ao servidor mestre em uma topologia de replicação. No entanto, à medida que o número de escravos aumenta, eles terão um pedágio nos recursos do mestre porque os logs binários precisarão ser servidos a diferentes escravos trabalhando em diferentes velocidades. Se a rotatividade de dados no mestre for alta, apenas o serviço de logs binários pode saturar a interface de rede do mestre.
Uma solução clássica para esse problema é implantar um servidor de log binário – um servidor proxy intermediário que fica entre o mestre e seus escravos. O servidor binlog é configurado como escravo do mestre e, por sua vez, atua como mestre do conjunto original de escravos. Ele recebe eventos de log binários do mestre, não aplica esses eventos, mas os atende a todos os outros escravos. Dessa forma, a carga no mestre é tremendamente reduzida e, ao mesmo tempo, o servidor de log binário atende os logs binários de forma mais eficiente aos escravos, pois não precisa fazer nenhum outro processamento do servidor de banco de dados.
Ripple é um servidor de log binário de código aberto desenvolvido por Pavel Ivanov. Uma postagem no blog da Percona, intitulada MySQL Ripple:The First Impression of a MySQL Binlog Server, fornece uma introdução muito boa à implantação e uso do Ripple. Tive a oportunidade de explorar o Ripple com mais detalhes e queria compartilhar minhas observações através deste post.
1. Suporte para replicação baseada em GTID
O Ripple suporta apenas o modo GTID, e não a replicação baseada em arquivo e posição. Se o seu mestre estiver sendo executado no modo não GTID, você receberá este erro do Ripple:
Falha ao ler o pacote:Ocorreu um erro ao ler o pacote do servidor:A thread do remetente de replicação não pode iniciar no modo AUTO_POSITION:este servidor tem GTID_MODE =OFF em vez de ON.
Você pode especificar Server_id e UUID para o servidor ripple usando as opções de linha cmd: -ripple_server_id e -ripple_server_uuid
Ambos são parâmetros opcionais e, se não forem especificados, o Ripple usará o server_id=112211 padrão e o uuid será gerado automaticamente.
2. Conectando-se ao mestre usando usuário e senha de replicação
Ao se conectar ao mestre, você pode especificar o usuário e a senha de replicação usando as opções de linha de comando:
-ripple_master_user e -ripple_master_password
3. Ponto de extremidade de conexão para o servidor Ripple
Você pode usar as opções de linha de comando -ripple_server_ports e -ripple_server_address para especificar os pontos finais de conexão para o servidor Ripple. Certifique-se de especificar o nome de host ou endereço IP acessível à rede do seu servidor Ripple como -rippple_server_address. Caso contrário, por padrão, o Ripple será vinculado ao localhost e, portanto, você não poderá se conectar a ele remotamente.
4. Configurando escravos para o servidor Ripple
Você pode usar o comando CHANGE MASTER TO para conectar seus escravos para replicar a partir do servidor Ripple.
Para garantir que o Ripple possa autenticar a senha que você usa para se conectar a ele, você precisa iniciar o Ripple especificando a opção -ripple_server_password_hash
Por exemplo, se você iniciar o servidor ripple com o comando: você pode usar o seguinte comando CHANGE MASTER TO para conectar a partir do escravo: Observe que o hash de senha especificado para o servidor Ripple corresponde à senha de texto usada no comando CHANGE MASTER TO. Atualmente, o Ripple não autentica com base nos nomes de usuário e aceita qualquer nome de usuário não vazio, desde que a senha corresponda. É possível monitorar e gerenciar o servidor Ripple usando o protocolo MySQL a partir de qualquer cliente MySQL padrão. Há um conjunto limitado de comandos suportados que você pode ver diretamente no código-fonte na página mysql-ripple do GitHub. Alguns dos comandos úteis são: Como resultado disso, o servidor Ripple não poderá se conectar a um mestre que exija conexões criptografadas. A tentativa de conectar resultará no erro: Iniciei o servidor Ripple usando a opção -ripple_semi_sync_slave_enabled=true Ao conectá-lo, o mestre foi capaz de detectar o servidor Ripple como um escravo habilitado para semi-sincronização. No entanto, tentar executar uma transação no modo semi-sincronizado esperou por rpl_semi_sync_master_timeout que era 180000 Percebi que a semi-sincronização foi desativada no mestre: Trecho correspondente dos logs de erro do mysql: Há um problema relatado em linhas semelhantes aqui na página do MySQL Ripple no Github. Vi que o thread SQL no escravo geralmente parava com o erro: Analisar o log de retransmissão e a posição acima revelou que o 'número de sequência' da transação neste ponto foi redefinido para 1. Eu rastreei a causa de uma rotação de log binário acontecendo no mestre originário. Normalmente, para escravos diretos, há um evento de rotação devido ao qual os logs de retransmissão também giram com base na rotação do log binário mestre. Minha avaliação é que tais condições podem ser detectadas e a redefinição do número de sequência pode ser tratada por threads paralelos. Mas quando o número de sequência muda sem a rotação dos logs de retransmissão, vemos as threads paralelas falhando. Esta observação é relatada como o problema:falha de encadeamento paralelo escravo durante a sincronização do servidor de log binário #26 Tentar executar o utilitário mysqlbinlog no log binário resultou no erro: Este problema é levantado aqui:Não é possível abrir os arquivos de log binários usando o utilitário mysqlbinlog. #25 É reconhecido pelo autor como um problema conhecido. Eu sinto que seria útil oferecer suporte a esse utilitário para fins de depuração. Esse é o relatório por enquanto do meu teste rápido. Planejo atualizar esta postagem no blog à medida que encontrar mais descobertas sobre o Ripple. No geral, achei simples e direto de usar e tem potencial para se tornar um padrão para servidores de log binário em ambientes MySQL. Em uma configuração de alta disponibilidade (HA) mestre-escravo do MySQL, é importante monitorar continuamente a integridade dos servidores mestre e escravo para que você possa detectar possíveis problemas e tomar ações corretivas . Saber mais Como otimizar o processo de criação de índice MySQL de forma que sua carga de trabalho regular não seja afetada. Se você tiver um conjunto de réplicas mestre-escravo do MySQL, poderá criar o índice um nó por vez de maneira contínua.Saiba mais A disponibilidade de um sistema é a porcentagem de tempo em que seus serviços estão ativos durante um período de tempo. É geralmente expresso como uma série de 9's. Veja a disponibilidade e o tempo de inatividade correspondente medido ao longo de um ano. Saber mais
rippled -ripple_datadir=./binlog_server -ripple_master_address=
MUDAR MASTER PARA master_host='172.31.23.201', master_port=15000, master_password='XpKWeZRNH5#satCI', master_user='rep'
Explorando o MySQL Binlog Server - RippleClick To Tweet 5. Gerenciamento de servidor Ripple
SELECT @@global.gtid_executed; – Para ver o GTID SET do servidor Ripple com base em seus logs binários baixados.PARAR ESCRAVO; – Para desconectar o servidor Ripple do mestre.INICIAR ESCRAVO; – Para conectar o servidor Ripple ao mestre.Problemas conhecidos e sugestões para melhorias
1. Não vi uma opção para configurar um canal de replicação SSL de um servidor Ripple para o mestre
0322 09:01:36.555124 14942 mysql_master_session.cc:164] Falha ao conectar ao host:
2. Não consegui fazer o servidor Ripple funcionar com a opção de semi-sincronização
mysql> mostra status como 'rpl%';
--------------------------------- ----------
| Variable_name | Valor |
-------------------------------------------- ----------
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_status | ATIVADO |
| Rpl_semi_sync_slave_status | DESATIVADO |
------------------------------------------------------- ----------
mysql> cria banco de dados d12;
Consulta OK, 1 linha afetada (3 min 0,01 seg)
mysql> mostra status como 'rpl%';
+-------------------------------- ------------+-------+
| Variable_name | Valor |
+------------------------------------------- -+-------+
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_status | DESLIGADO |
| Rpl_semi_sync_slave_status | DESATIVADO |
+------------------------------------------- -+-------+
2020-03-21T10:05:56.000612Z 52 [Nota] Inicie binlog_dump para master_thread_id(52) slave_server(112211), pos(, 4)
2020-03-21T10:05:56.000627Z 52 [ Nota] Iniciar semi-sincronização binlog_dump para escravo (server_id:112211), pos(, 4)
20020-03-21T10:08:55.873990Z 2 [Warning] Timeout aguardando resposta do binlog (arquivo:mysql-bin .000010, pos:350), semi-sincronização até o arquivo , posição 4.
2020-03-21T10:08:55.874044Z 2 [Observação] A replicação semi-sincronizada está DESATIVADA.
3. Problema ao usar replicação paralela para os escravos do servidor Ripple
Last_SQL_Error:Não é possível executar o grupo de eventos atual no modo paralelo. Encontrou o evento Gtid, nome do log de retransmissão /mysql_data/relaylogs/relay-log.000005, posição 27023962 que impede a execução deste grupo de eventos em modo paralelo. Motivo:o evento mestre está logicamente com carimbo de data/hora incorreto.
4. O utilitário mysqlbinlog não funciona nos logs binários produzidos pelo servidor Ripple
ERRO:Erro em Log_event::read_log_event():'Encontrado evento inválido no log binário', data_len:43, event_type:-106
Mais dicas para você
Verificações de integridade do MySQL Server
Criações de índice móvel do MySQL
Alta disponibilidade do MySQL
