Idéias de ajuste de atraso mestre-escravo
1. O que é atraso mestre-escravo?
A essência é que a reprodução da biblioteca escrava não consegue acompanhar a biblioteca mestre e o estágio de reprodução é atrasado.
2. Quais são as causas comuns do atraso mestre-escravo?
1. Para transações grandes, o tempo de reprodução da biblioteca escrava é longo, resultando em atraso mestre-escravo.
2. A biblioteca principal grava com muita frequência e a biblioteca escrava não consegue acompanhar a reprodução.
3. Configuração de parâmetros irracional
4. Diferenças no hardware mestre-escravo
5. Atraso de rede
6. A tabela não possui uma chave primária ou o índice é atualizado com frequência e frequência.
7. Algumas arquiteturas que separam a leitura e a escrita exercem maior pressão sobre a biblioteca escrava.
3. Quais são os métodos para resolver o atraso mestre-escravo?
1. Para grandes transações, divida-as em pequenas transações
2. Habilite a replicação paralela
3. Atualize o hardware escravo
4. Tente ter chaves primárias
4. O que é replicação paralela e quais são os seus parâmetros?
Revise a jornada da replicação paralela do MySQL
MySQL5.6 é baseado em replicação paralela em nível de banco de dados
slave-parallel-type=DATABASE (transações em bibliotecas diferentes, sem conflitos de bloqueio)
Replicação paralela MySQL5.7 baseada em commit de grupo
slave-parallel-type=LOGICAL_CLOCK : Commit-Parent-Based模式(同一组的事务[last-commit相同]Não há conflito de bloqueio No mesmo grupo, não deve haver conflito, caso contrário não há como se tornar o mesmo grupo)
O acima é a configuração da biblioteca escrava. A replicação paralela depende do envio do grupo da biblioteca mestre (observe a distinção entre replicação de grupo).
greatsql> show variables like '%group%delay%';
+-----------------------------------------+-------+
| Variable_name | Value |
+-----------------------------------------+-------+
| binlog_group_commit_sync_delay | 0 |
| binlog_group_commit_sync_no_delay_count | 0 |
+-----------------------------------------+-------+
2 rows in set (0.01 sec)
-
binlog_group_commit_sync_delay: Quanto tempo esperar antes de enviar o grupo -
binlog_group_commit_sync_no_delay_count: Quantas transações esperar antes de confirmar o grupo
Todos os parâmetros acima dependem da situação de ocupação do banco de dados principal. Se o negócio não for frequente, será muito constrangedor.
binlog_group_commit_sync_no_delay_count: Este parâmetro é definido como 2
Por exemplo, se apenas um thread executa uma transação e a segunda transação é executada 24 horas depois, essa transação precisa esperar 24 horas antes de ser enviada, o que é muito frustrante.
binlog_group_commit_sync_delay
Se estiver definido como 200ms e apenas um thread executar uma transação, ela poderá ser enviada em 10ms, mas deverá aguardar 200ms.
Geralmente, ambos são configurados online. Por exemplo, é como um pequeno barco transportando pessoas através de um rio.
Suponha que nossos parâmetros estejam definidos assim:
binlog_group_commit_sync_delay=200;
binlog_group_commit_sync_no_delay_count=2
Você pode ir diretamente se precisar de 200 ms ou pode ir diretamente se precisar de 2 pessoas. Isso é muito mais fácil de usar, mas ainda é embaraçoso quando o negócio não está ocupado.
Replicação paralela MySQL8.0 baseada em conjunto de gravação
Detecção de conflitos com base na chave primária (binlog_transaction_depandency_tracking = COMMIT_ORDERE|WRITESET|WRITESET_SESSION, se não houver conflito na chave primária ou na chave única não vazia da linha modificada, ela pode ser paralelizada)
Algoritmo de detecção de transação:transaction_write_set_extraction = XXHASH64
O MySQL terá uma variável para armazenar o valor HASH da transação enviada. Após o hash, os valores da chave primária (ou chave única) modificada por todas as transações enviadas serão comparados com o conjunto dessa variável para determinar se a mudança. de conflitos de linha com ele e para determinar dependências
As variáveis mencionadas aqui podem ser definidas em tamanho através disto:binlog_transaction_dependency_history_size
Esse tipo de granularidade atingiu o nível de linha, ou seja, a granularidade paralela é mais refinada neste momento, e a velocidade paralela será mais rápida. Em alguns casos, não é exagero dizer que o paralelismo do escravo ultrapassa o. mestre ( o mestre é uma gravação de thread único, o escravo também pode reproduzir em paralelo )
Simplificando, é uma reprodução paralela baseada em linhas. Linhas diferentes no nível rc não terão conflitos de bloqueio.
Desempenho de envio de grupo:
Verifique se o valor last_commit do log binário da biblioteca principal é consistente. Se consistente, ele pode ser reproduzido em paralelo. Se for inconsistente, ele só poderá ser reproduzido em série.
5. Análise prática
5.1 Verifique o atraso mestre-escravo online
Seconds_Behind_Master: 48828
Percebe-se que o atraso é muito alto, próximo a 14 horas. Nesse horário, a biblioteca principal também está gravando dados constantemente, cerca de 6 minutos para um binlog e outro para 500M.
5.2 Ver configuração de replicação atual
Veja a configuração da biblioteca escrava:
greatsql> show variables like '%slave%para%';
+------------------------+---------------+
| Variable_name | Value |
+------------------------+---------------+
| slave_parallel_type | LOGICAL_CLOCK |
| slave_parallel_workers | 128 |
+------------------------+---------------+
2 rows in set (0.02 sec)
Fenômeno de atraso:
A biblioteca escrava vem perseguindo, indicando que não é uma grande transação, mas Seconds_Behind_Mastero atraso vem aumentando.
Retrieved_Gtid_Set: 00000000-0000-0024-0046-41a8003b4b99:242966351-253068975,
00000000-0000-0040-0095-5fff003b4b99:91056629-110569633,
00000000-0000-005c-0ced-7bae003b4b99:150292055-160253193,
31f4399f-ade5-11ed-a544-00163ebdeb51:1-12,
Executed_Gtid_Set: 00000000-0000-0024-0046-41a8003b4b99:1-252250235,
00000000-0000-0040-0095-5fff003b4b99:1-109120315,
00000000-0000-005c-0ced-7bae003b4b99:1-159504296,
31f4399f-ade5-11ed-a544-00163ebdeb51:1-12,
Auto_Position: 1
Neste momento, suspeita-se que não haja replicação paralela e que a biblioteca principal pode não ter configurado o envio de grupo (apenas um palpite)
5.3 Para verificação adicional, verifique o binlog da biblioteca principal
Verifique a configuração dos parâmetros da biblioteca principal: ainda as regras enviadas para o grupo
greatsql> show variables like '%binlog_transac%';
+--------------------------------------------+----------+
| Variable_name | Value |
+--------------------------------------------+----------+
| binlog_transaction_compression | OFF |
| binlog_transaction_compression_level_zstd | 3 |
| binlog_transaction_dependency_history_size | 25000 |
| binlog_transaction_dependency_tracking | WRITESET |
+--------------------------------------------+----------+
4 rows in set (0.02 sec)
Veja a configuração de envio de grupo: significa que não há envio de grupo.
greatsql> show variables like '%group%delay%';
+-----------------------------------------+-------+
| Variable_name | Value |
+-----------------------------------------+-------+
| binlog_group_commit_sync_delay | 0 |
| binlog_group_commit_sync_no_delay_count | 0 |
+-----------------------------------------+-------+
2 rows in set (0.01 sec)
Após uma verificação mais aprofundada, olhando o binlog, descobrimos que last_committed é realmente diferente, indicando que o paralelismo não é possível.
5.4 Definir parâmetros para a biblioteca principal e analisar seu log binário novamente
será binlog_transaction_dependency_trackingalterado para WRITESETo modo
greatsql> show variables like '%transaction%';
+----------------------------------------------------------+-----------------+
| Variable_name | Value |
+----------------------------------------------------------+-----------------+
| binlog_direct_non_transactional_updates | OFF |
| binlog_transaction_compression | OFF |
| binlog_transaction_compression_level_zstd | 3 |
| binlog_transaction_dependency_history_size | 25000 |
| binlog_transaction_dependency_tracking | WRITESET |
| kill_idle_transaction | 300 |
| performance_schema_events_transactions_history_long_size | 10000 |
| performance_schema_events_transactions_history_size | 10 |
| replica_transaction_retries | 10 |
| session_track_transaction_info | OFF |
| slave_transaction_retries | 10 |
| transaction_alloc_block_size | 8192 |
| transaction_allow_batching | OFF |
| transaction_isolation | REPEATABLE-READ |
| transaction_prealloc_size | 4096 |
| transaction_read_only | OFF |
| transaction_write_set_extraction | XXHASH64 |
+----------------------------------------------------------+-----------------+
17 rows in set (0.00 sec)
Verifique seu binlog novamente e veja que muitos deles podem ser reproduzidos em paralelo.
5.5 Otimização concluída
Embora a biblioteca principal esteja gravando em grandes lotes, o atraso está diminuindo lentamente. É apenas uma questão de tempo até que chegue a 0.
Aproveite o GreatSQL :)
Sobre GreatSQL
GreatSQL é um banco de dados doméstico independente de código aberto adequado para aplicativos de nível financeiro. Possui muitos recursos básicos, como alto desempenho, alta confiabilidade, alta facilidade de uso e alta segurança. e é utilizado em ambientes de produção online, totalmente gratuito e compatível com MySQL ou Percona Server.
Links relacionados: Guia da comunidade GreatSQL GitHub Bilibili
Comunidade GreatSQL:
Sugestões e feedback de recompensas da comunidade: https://greatsql.cn/thread-54-1-1.html
Detalhes do envio do prêmio do blog da comunidade: https://greatsql.cn/thread-100-1-1.html
(Se você tiver alguma dúvida sobre o artigo ou tiver ideias exclusivas, você pode acessar o site oficial da comunidade para perguntar ou compartilhá-las ~)
Grupo de intercâmbio técnico:
Grupo WeChat e QQ:
Grupo QQ: 533341697
Grupo WeChat: Adicione o GreatSQL Community Assistant (WeChat ID:) wanlidbccomo amigo e espere que o assistente da comunidade adicione você ao grupo.