Em nosso blog anterior sobre painéis SCUMM, analisamos o painel de visão geral do MySQL. A nova versão do ClusterControl (ver. 1.7) oferece vários gráficos de alta resolução de métricas úteis, e analisamos o significado de cada uma das métricas e como elas ajudam a solucionar problemas em seu banco de dados. Neste blog, veremos o painel de Replicação do MySQL. Vamos prosseguir com os detalhes deste painel sobre o que tem a oferecer.
Painel de Replicação do MySQL
O MySQL Replication Dashboard oferece um conjunto de gráficos muito simples que facilita o monitoramento de seu MySQL mestre e réplica(s). Começando de cima, mostra as variáveis e informações mais importantes para determinar a saúde da(s) réplica(s) ou mesmo do mestre. Este painel oferece uma parte muito útil ao inspecionar a saúde dos escravos ou de um mestre na configuração mestre-mestre. Pode-se também verificar neste painel a criação do log binário do mestre e determinar a dimensão geral, em termos do tamanho gerado, em um determinado período de tempo.
A primeira coisa neste painel é apresentar as informações mais importantes que você pode precisar com a integridade de sua réplica. Veja o gráfico abaixo:
Basicamente, ele mostrará o IO_Thread do thread escravo, SQL_Thread, erro de replicação e se a variável read_only está habilitada. Na captura de tela de amostra acima, todas as informações mostram que meu escravo 192.168.70.20 está íntegro e funcionando normalmente.
Além disso, o ClusterControl também tem informações para coletar se você for para Cluster -> Visão geral. Role para baixo e você pode ver o gráfico abaixo:
Outro local para visualizar a configuração de replicação é a visualização de topologia da configuração de replicação, acessível em Cluster -> Topology. Ele fornece, rapidamente, uma visão dos diferentes nós na configuração, suas funções, atraso de replicação, GTID recuperado e muito mais. Veja o gráfico abaixo:
Além disso, a Visualização de Topologia também mostra todos os diferentes nós que fazem parte de seu cluster de banco de dados, sejam nós de banco de dados, balanceadores de carga (ProxySQL/MaxScale/HaProxy) ou arbitradores (garbd), bem como as conexões entre eles. Os nós, conexões e seus status são descobertos pelo ClusterControl. Como o ClusterControl monitora continuamente os nós e mantém as informações de estado, quaisquer alterações na topologia são refletidas na interface da web. Em caso de falha de nós são relatados, você pode usar esta visualização junto com os Dashboards SCUMM e ver qual impacto isso pode causar.
A Visualização de Topologia tem alguma semelhança com o Orchestrator no qual você pode gerenciar os nós, alterar os mestres arrastando e soltando o objeto no mestre desejado, reiniciar os nós e sincronizar os dados. Para saber mais sobre nossa Visualização de Topologia, sugerimos que você leia nosso blog anterior - “Visualizando sua Topologia de Cluster no ClusterControl”.
Vamos agora prosseguir com os gráficos.
-
Atraso de replicação do MySQL
Este gráfico é muito familiar para qualquer um que gerencia o MySQL, especialmente aqueles que trabalham diariamente em sua configuração mestre-escravo. Este gráfico tem as tendências de todos os atrasos registrados para um intervalo de tempo específico especificado neste painel. Sempre que quisermos verificar o tempo de queda periódico que nossa réplica possui, esse gráfico é bom de se olhar. Há certas ocasiões em que uma réplica pode atrasar por motivos estranhos, como seu RAID tem um BBU degradado e precisa de uma substituição, uma tabela não tem chave exclusiva, mas não no mestre, uma verificação indesejada de tabela completa ou verificação completa de índice ou uma consulta incorreta foi deixado em execução por um desenvolvedor. Este também é um bom indicador para determinar se o atraso do escravo é um problema importante, então você pode aproveitar a replicação paralela.
-
Tamanho do Binlog
Esses gráficos estão relacionados entre si. O gráfico Binlog Size mostra como seu nó gera o log binário e ajuda a determinar sua dimensão com base no período de tempo que você está verificando.
-
Binlog Data Written Hourly
O Binlog Data Written Hourly é um gráfico baseado no dia atual e no dia anterior registrado. Isso pode ser útil sempre que você quiser identificar o tamanho do nó que está aceitando gravações, que podem ser usadas posteriormente para planejamento de capacidade.
-
Contagem de Binlogs
Digamos que você espera um alto tráfego para uma determinada semana. Você deseja comparar quão grandes gravações estão passando por seu mestre e escravos com a semana anterior. Este gráfico é muito útil para este tipo de situação - Para determinar a altura dos logs binários gerados no próprio mestre ou mesmo nos escravos se a variável log_slave_updates estiver habilitada. Você também pode usar este indicador para determinar seus dados de log binários master vs slaves gerados, especialmente se você estiver filtrando algumas tabelas ou esquemas (replicate_ignore_db, replicate_ignore_table, replicate_wild_do_table) em seus slaves que foram gerados enquanto log_slave_updates está habilitado.
-
Binlogs criados por hora
Este gráfico é uma visão geral rápida para comparar sua criação de binlogs de hora em hora de ontem e de hoje.
-
Espaço de log de retransmissão
Este gráfico serve como base dos logs de retransmissão gerados de sua réplica. Quando usado junto com o gráfico MySQL Replication Delay, ele ajuda a determinar quão grande é o número de logs de retransmissão gerados, que o administrador deve considerar em termos de disponibilidade de disco da réplica atual. Pode causar problemas quando seu escravo está com um atraso rigoroso e está gerando um grande número de logs de retransmissão. Isso pode consumir seu espaço em disco rapidamente. Existem certas situações em que, devido a um grande número de gravações do mestre, o escravo/réplica ficará com um atraso enorme, portanto, gerar uma grande quantidade de logs pode causar alguns problemas sérios nessa réplica. Isso pode ajudar a equipe de operações ao conversar com seu gerenciamento sobre planejamento de capacidade.
-
Relay Log Escrito por Hora
Igual ao Relay Log Space, mas adiciona uma visão geral rápida para comparar seus logs de retransmissão escritos de ontem e de hoje.
Conclusão
Você aprendeu que usar o SCUMM para monitorar sua replicação MySQL adiciona mais produtividade e eficiência à equipe de operações. Usar os recursos que temos das versões anteriores combinados com os gráficos fornecidos com o SCUMM é como ir à academia e ver grandes melhorias em sua produtividade. Isso é o que o SCUMM pode oferecer:monitoramento com esteróides! (agora, não estamos defendendo que você deva tomar esteróides quando for à academia!)
Na Parte 3 deste blog, discutirei as Métricas do InnoDB e os Painéis de Esquema de Desempenho do MySQL.
