A replicação semissíncrona do MySQL fornece integridade de dados aprimorada porque quando um commit retorna com sucesso, sabe-se que os dados existem em pelo menos dois lugares – o mestre e seu escravo. Nesta postagem do blog, revisamos algumas das configurações de hospedagem do MySQL que influenciam a integridade dos dados e os aspectos de desempenho da replicação semissíncrona. Usaremos o mecanismo de armazenamento InnoDB e a replicação baseada em GTID em um conjunto de réplicas de 3 nós (mestre e 2 escravos), o que garantirá redundância nos escravos. Isso significa que, se houver problemas com um escravo, podemos recorrer ao outro.
Configurações aplicáveis aos nós mestre e escravo
- innodb_flust_log_at_trx_commit =1
- sync_binlog =1
Essas configurações garantem alta durabilidade e configurações de consistência para os dados. Ou seja, cada transação confirmada tem a garantia de estar presente em logs binários e também os logs são liberados para o disco. Portanto, no caso de uma falha de energia ou falha do sistema operacional, a consistência dos dados do MySQL é sempre preservada.
Configurações no nó mestre.
- rpl_semi_sync_master_wait_for_slave_count:
Esta opção é usada para configurar o número de escravos que devem enviar uma confirmação antes que um mestre semissíncrono possa confirmar a transação. No conjunto de réplicas de 3 nós, recomendamos definir isso como 1, para que sempre tenhamos a garantia de que os dados estão disponíveis em pelo menos um escravo, evitando qualquer impacto no desempenho envolvido na espera pela confirmação de ambos os escravos.
- rpl_semi_sync_master_timeout:
Esta opção é usada para configurar a quantidade de tempo que um mestre semissíncrono espera pela confirmação do escravo antes de retornar ao modo assíncrono. Recomendamos definir isso como um número grande para que não haja fallback para o modo assíncrono, o que anula nosso objetivo de integridade de dados. Como estamos operando com 2 escravos e rpl_semi_sync_master_wait_for_slave_count está definido como 1, podemos supor que pelo menos um dos escravos reconhece dentro de um período de tempo razoável, minimizando assim o impacto sobre o desempenho dessa configuração.
#MySQL Tutorial:Integridade de dados e considerações de desempenho na replicação semisíncronaClique para tweet
Configurações nos nós escravos
Nos escravos, é sempre importante rastrear duas posições com muita precisão:a posição atual executada do thread SQL no log de retransmissão e a posição atual do thread de E/S que indica a distância o arquivo binário mater é lido e copiado para o slave. As consequências de não manter essas posições são bastante óbvias. Se houver uma falha e reinicialização do escravo, o thread SQL pode iniciar o processamento de transações de um deslocamento errado ou o thread de E/S pode começar a extrair dados de uma posição errada nos logs binários mestres. Ambos os casos levarão à corrupção de dados.
é importante garantir a segurança contra falhas dos escravos por meio das seguintes configurações:
- relay_log_info_repository =TABELA
- relay_log_recovery =ATIVADO
Configurar relay_log_info_repository como TABLE garantirá que a posição do thread SQL seja atualizada junto com cada confirmação de transação no escravo. No entanto, é difícil manter a posição exata do thread de E/S e nivelar o disco. Isso ocorre porque a leitura do log binário mestre e a gravação no log de retransmissão escravo não são baseadas em transações. O impacto no desempenho é muito alto se a posição do thread de E/S tiver que ser atualizada e liberada no disco após cada gravação nos logs de retransmissão do escravo. Uma solução mais elegante seria definir relay_log_recovery =ON, nesse caso, se houver uma reinicialização do MySQL, os logs de retransmissão atuais serão considerados corrompidos e serão extraídos recentemente do mestre com base na posição do thread SQL.
Por último, mas não menos importante, é importante observar que a replicação semissíncrona garante que os dados tenham acabado de 'alcançar' um dos escravos antes do mestre confirmar a transação, e não significa que as transações são confirmadas no escravo. Portanto, será bom garantir que o thread SQL funcione com bom desempenho. No caso ideal, o thread SQL se move de mãos dadas com o thread IO para que possamos ter o benefício do escravo não apenas receber as transações, mas também confirmá-las. É recomendado usar uma configuração de escravo multi-thread para que possamos obter maior desempenho de thread SQL escravo. As configurações importantes para escravos multi-thread são:
- slave_parallel_workers : Defina como> 1 para habilitar vários trabalhadores de thread SQL escravos. Com base no número de threads gravados no mestre, podemos decidir um número ideal para isso, para que o escravo não fique atrasado.
- slave-parallel-type =LOGICAL_CLOCK
- slave-preserve-commit-order =1
As configurações acima prometem paralelismo no escravo, ao mesmo tempo em que preservam a ordem das transações como visto no mestre.
Em resumo, usando as configurações acima em nosso conjunto de réplicas do MySQL, podemos manter a alta integridade dos dados e um desempenho ideal.
Como sempre, se você tiver alguma dúvida, deixe um comentário, entre em contato conosco em @scalegridio no Twitter ou envie um e-mail para suporte @scalegrid.io.
