Temos replicação MySQL
- Configuração Mestre/Escravo
- db01 mestre
- DB02 Escravo (somente leitura)
Estamos obtendo discrepância de carga no Escravo (db02), mas a carga do servidor Mestre (db01) está baixa. MySQL é o único processo ativo no Slave.
O iowait da CPU é aumentado.
12:00:01 AM CPU %user %nice %system %iowait %steal %idle
12:10:01 AM all 0.07 0.00 0.02 0.01 0.00 99.90
12:20:01 AM all 0.06 0.00 0.01 0.01 0.00 99.92
12:30:01 AM all 0.05 0.01 0.01 0.01 0.00 99.92
12:40:01 AM all 0.06 0.00 0.01 0.01 0.00 99.92
12:50:01 AM all 0.06 0.00 0.01 0.01 0.00 99.92
01:00:01 AM all 0.05 0.00 0.01 0.01 0.00 99.93
01:10:01 AM all 0.07 0.00 0.02 0.01 0.00 99.90
01:20:01 AM all 0.06 0.00 0.01 0.01 0.00 99.92
01:30:01 AM all 0.05 0.01 0.01 0.01 0.00 99.92
01:40:01 AM all 0.06 0.00 0.01 0.02 0.00 99.91
01:50:01 AM all 0.05 0.00 0.01 0.01 0.00 99.93
02:00:01 AM all 0.05 0.00 0.01 0.01 0.00 99.93
02:10:01 AM all 0.06 0.00 0.02 0.01 0.00 99.91
02:20:01 AM all 0.05 0.00 0.01 0.01 0.00 99.93
02:30:01 AM all 0.05 0.01 0.01 0.01 0.00 99.93
02:40:01 AM all 0.06 0.00 0.01 0.01 0.00 99.92
02:50:01 AM all 0.05 0.00 0.01 0.01 0.00 99.93
03:00:01 AM all 0.05 0.00 0.01 0.01 0.00 99.94
03:10:01 AM all 0.07 0.00 0.02 0.40 0.00 99.52
03:20:01 AM all 0.05 0.00 0.01 0.59 0.00 99.35
03:30:01 AM all 0.05 0.01 0.01 0.50 0.00 99.44
03:40:01 AM all 0.05 0.00 0.01 0.51 0.00 99.43
03:50:01 AM all 0.05 0.00 0.01 0.71 0.00 99.22
04:00:01 AM all 0.05 0.00 0.01 0.47 0.00 99.47
04:10:01 AM all 0.06 0.00 0.01 0.63 0.00 99.30
04:20:01 AM all 0.05 0.00 0.02 0.48 0.00 99.45
04:30:01 AM all 0.05 0.01 0.01 0.48 0.00 99.45
04:40:01 AM all 0.05 0.00 0.01 0.54 0.00 99.39
04:50:01 AM all 0.05 0.00 0.01 0.53 0.00 99.40
05:00:01 AM all 0.05 0.00 0.01 0.55 0.00 99.39
05:10:01 AM all 0.06 0.00 0.02 0.81 0.00 99.11
05:20:01 AM all 0.05 0.00 0.01 0.67 0.00 99.27
05:30:01 AM all 0.05 0.01 0.01 0.57 0.00 99.36
05:40:01 AM all 0.06 0.00 0.02 0.58 0.00 99.35
05:50:01 AM all 0.06 0.00 0.02 0.67 0.00 99.25
06:00:01 AM all 0.05 0.00 0.01 0.62 0.00 99.31
06:10:01 AM all 0.06 0.00 0.02 0.74 0.00 99.18
Average: all 0.06 0.00 0.01 0.30 0.00 99.63
No Master(db01), a carga é baixa e constante. No Slave(db02), a carga está aumentando.
Perguntas
- Por que isso está acontecendo, vai acontecer, não somos compreendidos
- Como podemos depurar isso ou resolvê-lo
Por favor me ajude aqui.
Você terá que olhar para isso de diferentes perspectivas
Mecanismo de dados/armazenamento
O mecanismo de armazenamento InnoDB é construído para escrever o mínimo possível. Como um mecanismo de armazenamento compatível com ACID, o InnoDB possui mecanismos para manipulação simultânea de dados. As estruturas utilizadas pela infraestrutura InnoDB são as seguintes:
Mestre
Com toda a probabilidade, existem operações simultâneas de várias conexões de banco de dados executando
no Mestre. Essas alterações e pesquisas são armazenadas em cache e gerenciadas com a infraestrutura InnoDB. A liberação de todas as alterações registradas é gerenciada em série, mas não tem efeito imediato na simultaneidade de dados. O único gargalo discernível seria o momento em que uma transação SQL decide gravar os comandos SQL em seus logs binários. O sistema operacional é responsável por liberar as alterações nos logs binários para o disco.
Escravo
Aqui é onde as coisas podem ficar interessantes. Enquanto o Mestre lida com tudo que é jogado nele, ele tem que escrever os Comandos SQL em seus Logs Binários. O Escravo tem a responsabilidade de processar o que o Mestre lhe dá.
Aqui está o paradigma de replicação do MySQL
Se você seguir cuidadosamente o fluxo de controle desta descrição do Paradigma, poderá ver facilmente que todo o SQL enviado do Mestre é serializado. Em outras palavras, os comandos SQL dos Relay Logs são executados um por vez. Isso pode se manifestar no Escravo da seguinte forma:
SHOW SLAVE STATUS\G, você vê oSeconds_Behind_MasteraumentoSHOW PROCESSLIST;, o encadeamento SQL (cujo usuário é 'usuário do sistema') está executando uma instrução SQL que está demorando muito por conta própria.Isso pode acontecer facilmente quando um mestre está lidando com centenas de comandos SQL em paralelo. É quando as instruções SQL são alinhadas em arquivo único e registradas como uma fila FIFO no Mestre, que o Escravo deve então processar cada comando primeiro a chegar, primeiro a servir sem nenhum benefício do paralelismo.
Conclusões tiradas
Das funções de Mestre e Escravo, dado um banco de dados totalmente InnoDB, um Mestre pode lidar com várias transações SQL e ser feito com todos os comandos. Por design, um Slave não tem escolha a não ser processar comandos de maneira serializada. O processamento em segundo plano executado por um mestre seria facilmente concluído e permaneceria quieto por um longo tempo, enquanto um escravo bastante ocupado processaria o SQL um por um e teria recursos para lidar com as alterações processadas de maneira semelhante.
Solução de problemas / Resolução
Uma vez que você pode ver este afunilamento do SQL do Master para o Slave, seu único recurso seria considerar algumas das seguintes opções para aplicar ao Slave e ao Master