Fonte: Public Account "The Shadow Corridor of the Oracle"
Em uma estrutura de replicação assíncrona ou semissíncrona, os atrasos da biblioteca são normais.
Embora o atraso seja normal, a necessidade de atenção geralmente é avaliada pela empresa.
Por exemplo, se houver serviços de leitura que requerem maior consistência da biblioteca e o atraso deve ser menor que um determinado valor, você precisa prestar atenção.
Uma breve visão geral da lógica de replicação:
1. O banco de dados principal registra as alterações na instância do banco de dados no log bin.
2. A biblioteca principal terá um binlog dumpthread para monitorar as mudanças do binlog em tempo real e enviar esses novos eventos para a biblioteca escrava ( Master has sent all binlog to slave; waiting for more updates)
3. A biblioteca escrava IO Threadrecebe esses eventos e os grava no relaylog.
4. SQL ThreadLeia os eventos relaylog da biblioteca e aplique (ou reproduza) esses eventos à instância da biblioteca escrava.
O acima é a lógica de replicação assíncrona padrão, e a replicação semissíncrona é um pouco diferente, então não vou repetir aqui.
Além disso, julgar que há um atraso na biblioteca escrava é uma questão muito simples:
basta passar o valor de SHOW SLAVE STATUS
verificação na biblioteca escrava Seconds_Behind_Master.
Razões do atraso e soluções
〇 As principais solicitações de DML da biblioteca são frequentes (grandes tps)
Ou seja, a biblioteca principal tem muitos pedidos de gravação, um grande número de operações simultâneas de inserção, exclusão e atualização e um grande número de binlogs são gerados em um curto espaço de tempo.
[Análise da causa] A
biblioteca principal grava dados simultaneamente, enquanto a biblioteca escrava SQL Threadé um log de aplicativo de thread único, que pode facilmente causar acúmulo e atraso do relaylog.
[Solução]
Faça a fragmentação e divida as solicitações de gravação por meio de dimensionamento. Ou considere a atualização para o MySQL 5.7+ e habilite a replicação paralela com base em relógios lógicos.
〇 A biblioteca principal executa tarefas importantes
Por exemplo, um grande número de dados de importação INSERT INTO $tb1 SELECT * FROM $tb2, LOAD DATA INFILEcomo
por exemplo UPDATE, DELETEtoda a tabela e assim Exec_Master_Log_Pospermaneceu o mesmo, Slave_SQL_Running_Statepara a Reading event from the relay log
análise do binlog da biblioteca principal, observe a biblioteca principal que está executando a transação pode ser conhecida.
[Análise da causa]
Se o banco de dados mestre leva 200s para atualizar uma tabela grande, se a configuração das bibliotecas mestre e escrava é semelhante, a biblioteca escrava também precisa gastar quase o mesmo tempo para atualizar a tabela grande. Neste momento, o atraso da biblioteca escrava começa a se acumular e eventos subsequentes Não foi possível atualizar.
[Solução]
Divida grandes transações e envie-as a tempo.
〇 A biblioteca principal executa instruções DDL em tabelas grandes
Fenômeno e 主库执行大事务similares.
Verifique se Exec_Master_Log_Pos não foi movido ou pode estar executando DDL.
Analise o binlog da biblioteca principal e veja as transações atualmente executadas pela biblioteca principal.
[Razões]
1, DDL não inicia, bloqueia, faz SHOW SLAVE STATUScheck Slave_SQL_Running_State-in waiting for table metadata locke não Exec_Master_Log_Posmuda.
2. O DDL está sendo executado e SQL Threados aplicativos de thread único aumentam a latência. Slave_SQL_Running_StatePara altering table, Exec_Master_Log_Posinalterado
[Soluções]
por processlistou information_schema.innodb_trxpara encontrar as instruções DDL de consulta de bloqueio, livrar-se das consultas, de modo que DDL executado corretamente a partir da biblioteca.
O atraso causado pelo próprio DDL é difícil de evitar. Recomenda-se considerar:
① Após o período de pico de negócios ser executado
② set sql_log_bin=0, execute manualmente o DDL nas bibliotecas mestre e escrava (esta operação causará inconsistência de dados para algumas operações DDL, certifique-se de testar estritamente)
〇 A configuração da biblioteca mestre e da biblioteca escrava são inconsistentes:
[Análise da causa]
Hardware: o servidor de instância de biblioteca principal usa SSD, enquanto o servidor de instância de biblioteca escravo usa discos SAS comuns e a frequência da CPU é inconsistente.
Configurações: como estratégias de gravação de placa RAID inconsistentes, configurações de parâmetro de kernel do SO inconsistentes e estratégias de posicionamento de disco MySQL inconsistentes Esperar
[Solução]
Tentar unificar a configuração da máquina do banco de dados (incluindo hardware e parâmetros de opções).
Mesmo para alguns serviços OLAP, a configuração do hardware da instância da biblioteca escrava é superior à da biblioteca principal, etc.
〇 A tabela não possui uma chave primária ou índice exclusivo
binlog_format=rowNessas circunstâncias, se a tabela não tiver uma chave primária ou índice exclusivo, em UPDATE, o DELETEtempo pode resultar em um atraso no aumento repentino da biblioteca.
Desta vez, Slave_SQL_Running_Statesim Reading event from the relay log.
E SHOW OPEN TABLES WHERE in_use=1a mesa sempre existe. Exec_Master_Log_Posconstante.
A cpu do processo mysqld é quase 100% (quando não há serviço de leitura), a pressão de io não é grande
] [Análise de causa
ser assumido que, em casos extremos, o banco de dados mestre atualizando 500w 20w linhas na tabela, a instrução de atualização requer uma verificação completa da tabela
no próximo formato de linha, é registrado binlog 20w tempos de operação de atualização e, em seguida, SQL Threadpeso A colocação será muito lenta, cada atualização pode exigir uma verificação completa da tabela
[Idéia da solução]
Verifique a estrutura da tabela para garantir que cada tabela tenha uma chave primária explícita de incremento automático e estabeleça um índice adequado.
〇 A pressão da própria biblioteca é muito alta
[Análise da causa]
Um grande número de solicitações selecionadas são executadas da biblioteca, ou a maioria das solicitações selecionadas do negócio são roteadas para a instância da biblioteca escrava, mesmo um grande número de serviços OLAP, ou a biblioteca escrava está sendo copiada.
Neste momento, a carga da CPU pode estar muito alta e a taxa de utilização de io pode estar muito alta, resultando em um aplicativo SQL Thread muito lento.
[Solução]
Crie mais bibliotecas escravas, interrompa as solicitações de leitura e reduza a pressão sobre as instâncias existentes da biblioteca escrava.
〇 Mecanismo de armazenamento MyISAM
Neste momento da biblioteca Slave_SQL_Running_StateéWaiting for table level lock
[Análise da causa]
MyISAM só oferece suporte a bloqueios em nível de tabela, e as operações de leitura e gravação não podem ser realizadas simultaneamente.
No @@concurrent_insertcaso de definir o valor correspondente, a biblioteca principal pode executar a inserção simultaneamente durante a seleção, mas SQL Threadnão pode ser reproduzida simultaneamente da biblioteca.Se você estiver interessado, você pode ir para ver a implementação do myisam.
[Solução]
Claro, eu escolhi perdoar.Já que escolhi o MyISAM, também devo estar psicologicamente preparado. (Existem outros cenários, e MyISAM não é recomendado para ser usado na estrutura de replicação)
Mude para InnoDB.
Resumindo:
Passe SHOW SLAVE STATUSe SHOW PROCESSLISTveja o status da biblioteca escrava. (A propósito, este motivo também pode ser descartado ao fazer backup da biblioteca.)
Se Exec_Master_Log_Pospermanecer o mesmo, considere grandes transações, DDL e nenhuma chave primária, e verifique o binlog e a posição correspondente à biblioteca principal.
Se Exec_Master_Log_Posmudar, o atraso aumentará gradualmente, considere a carga da máquina da biblioteca escrava, como io, cpu, etc., e considere se a operação de gravação da biblioteca principal e a pressão da própria biblioteca escrava são muito grandes.
Se nenhum dos motivos acima, pergunte aos figurões do DBA.
Claro, não Seconds_Behind_Masteré necessariamente preciso.Em um pequeno número de cenários, embora Seconds_Behind_Masterseja 0, os dados mestre e escravo são inconsistentes.
Esta será outra postagem no blog.
O texto completo acabou.
Aproveite o MySQL :)
Digitalize o código QR para seguir a conta pública do autor no WeChat
A aula "MySQL Core Optimization" do professor Ye foi atualizada para o MySQL 8.0, leia o código para iniciar a jornada de prática do MySQL 8.0