A maioria dos DBAs realiza verificações de integridade em seus bancos de dados de vez em quando. Normalmente, isso aconteceria em uma base diária ou semanal. Discutimos anteriormente por que essas verificações são importantes e o que elas devem incluir.
Para garantir que seus sistemas estejam em boa forma, você precisa passar por muitas informações - estatísticas de host, estatísticas do MySQL, estatísticas de carga de trabalho, estado de backups, pacotes de banco de dados, logs e assim por diante. Esses dados devem estar disponíveis em todos os ambientes monitorados adequadamente, embora às vezes estejam espalhados em vários locais - você pode ter uma ferramenta para monitorar o estado do MySQL, outra ferramenta para coletar estatísticas do sistema, talvez um conjunto de scripts, por exemplo, para verificar o estado do seus backups. Isso torna as verificações de integridade muito mais demoradas do que deveriam - o DBA precisa reunir as diferentes peças para entender o estado do sistema.
Ferramentas integradas como ClusterControl têm a vantagem de que todos os bits estão localizados no mesmo local (ou no mesmo aplicativo). Isso ainda não significa que eles estão localizados um ao lado do outro - eles podem estar localizados em diferentes seções da interface do usuário e um DBA pode ter que gastar algum tempo clicando na interface do usuário para acessar todos os dados interessantes.
A ideia por trás da criação de Relatórios Operacionais é colocar todos os dados mais importantes em um único documento, que pode ser revisado rapidamente para entender o estado dos bancos de dados.
Os Relatórios Operacionais estão disponíveis no menu Menu Lateral -> Relatórios Operacionais:
Uma vez lá, você verá uma lista de relatórios criados manualmente ou automaticamente, com base em um cronograma predefinido:
Se você quiser criar um novo relatório manualmente, use a opção 'Criar'. Escolha o tipo de relatório, nome do cluster (para relatório por cluster), destinatários de e-mail (opcional - se você quiser que o relatório seja entregue a você) e pronto:
Os relatórios também podem ser programados para serem criados regularmente:
Neste momento, estão disponíveis 5 tipos de relatórios:
- Relatório de disponibilidade - Todos os clusters.
- Relatório de backup - Todos os clusters.
- Relatório de alteração de esquema - somente cluster baseado em MySQL/MariaDB.
- Relatório diário do sistema - Por cluster.
- Relatório de upgrade de pacote - por cluster.
Relatório de disponibilidade
Os relatórios de disponibilidade se concentram na disponibilidade. Inclui três seções. Primeiro, resumo de disponibilidade:
Você pode ver informações sobre estatísticas de disponibilidade de seus bancos de dados, o tipo de cluster, tempo total de atividade e inatividade, estado atual do cluster e quando esse estado foi alterado pela última vez.
Outra seção fornece mais detalhes sobre a disponibilidade de cada cluster. A captura de tela abaixo mostra apenas um dos clusters de banco de dados:
Podemos ver quando um nó mudou de estado e qual foi a transição. É um bom lugar para verificar se houve algum problema recente com o cluster. Dados semelhantes são mostrados na terceira seção deste relatório, onde você pode percorrer o histórico de alterações no estado do cluster.
Relatório de backup
O segundo tipo de relatório é aquele que cobre backups de todos os clusters. Ele contém duas seções - resumo do backup e detalhes do backup, onde o primeiro basicamente fornece um breve resumo de quando o último backup foi criado, se foi concluído com sucesso ou falhou, status de verificação de backup, taxa de sucesso e período de retenção:
O ClusterControl também fornece exemplos de política de backup se encontrar qualquer cluster de banco de dados monitorado em execução sem nenhum backup agendado ou escravo atrasado configurado. A seguir estão os detalhes do backup:
Você também pode verificar a lista de backups executados no cluster com seu estado, tipo e tamanho dentro do intervalo especificado. Isso é o mais próximo que você pode ter para ter certeza de que os backups funcionam corretamente sem executar um teste de recuperação completo. Definitivamente, recomendamos que esses testes sejam realizados de vez em quando. A boa notícia é que o ClusterControl suporta restauração e verificação baseada em MySQL em um host autônomo em Backup -> Restore Backup.
Relatório diário do sistema
Esse tipo de relatório contém informações detalhadas sobre um cluster específico. Ele começa com um resumo de diferentes alertas relacionados ao cluster:
A próxima seção é sobre o estado dos nós que fazem parte do cluster:
Você tem uma lista dos nós no cluster, seu tipo, função (mestre ou escravo), status do nó, tempo de atividade e sistema operacional.
Outra seção do relatório é o resumo de backup, o mesmo que discutimos acima. O próximo apresenta um resumo das principais consultas no cluster:
Por fim, vemos uma "Visão geral do status do nó" na qual você verá gráficos relacionados às métricas do SO e do MySQL para cada nó.
Como você pode ver, temos aqui gráficos que cobrem todos os aspectos da carga no host - CPU, memória, rede, disco, carga da CPU e disco livre. Isso é suficiente para ter uma ideia se algo estranho aconteceu recentemente ou não. Você também pode ver alguns detalhes sobre a carga de trabalho do MySQL - quantas consultas foram executadas, qual tipo de consulta, como os dados foram acessados (por meio de qual manipulador)? Isso, por outro lado, deve ser suficiente para escolher a maioria dos problemas no lado do MySQL. O que você quer ver são todos os picos e quedas que você não viu no passado. Talvez uma nova consulta tenha sido adicionada ao mix e, como resultado, handler_read_rnd_next disparou? Talvez tenha havido um aumento de carga de CPU e um número alto de conexões possa apontar para um aumento de carga no MySQL, mas também para algum tipo de contenção. Um padrão inesperado pode ser bom para investigar, para que você saiba o que está acontecendo.
Relatório de atualização de pacote
Este relatório fornece um resumo dos pacotes disponíveis para atualização pelo gerenciador de repositório nos hosts monitorados. Para um relatório preciso, certifique-se de sempre usar repositórios estáveis e confiáveis em cada host. Em algumas ocasiões indesejáveis, os hosts monitorados podem ser configurados com um repositório desatualizado após uma atualização (por exemplo, cada versão principal do MariaDB usa um repositório diferente), repositório interno incompleto (por exemplo, espelhado parcial do upstream) ou repositório de ponta (comumente para repositório instável pacotes de compilação noturna).
A primeira seção é o resumo da atualização:
Ele resume o número total de pacotes disponíveis para atualização, bem como o serviço gerenciado relacionado ao cluster, como balanceador de carga, endereço IP virtual e árbitro. Em seguida, o ClusterControl fornece uma lista detalhada de pacotes, agrupados por tipo de pacote para cada host:
Este relatório fornece a versão disponível e pode nos ajudar muito a planejar nossa janela de manutenção com eficiência. Para atualizações críticas, como pacotes de segurança e banco de dados, poderíamos priorizá-las em relação a atualizações não críticas, que poderiam ser consolidadas com outras janelas de manutenção menos prioritárias.
Relatório de alteração de esquema
Este relatório compara as alterações selecionadas do banco de dados MySQL/MariaDB na estrutura da tabela que ocorreram entre dois relatórios gerados diferentes. Nas versões mais antigas do MySQL/MariaDB, a operação DDL é uma operação não atômica (pré 8.0) e requer cópia completa da tabela (pré 5.6 para a maioria das operações) - bloqueando outras transações até que seja concluída. As alterações de esquema podem se tornar um grande problema quando suas tabelas obtêm uma quantidade significativa de dados e devem ser cuidadosamente planejadas, especialmente em uma configuração em cluster. Em um ambiente de desenvolvimento de várias camadas, vimos muitos casos em que os desenvolvedores modificam silenciosamente a estrutura da tabela, resultando em um impacto significativo no desempenho da consulta.
Para que o ClusterControl produza um relatório preciso, opções especiais devem ser configuradas dentro do arquivo de configuração CMON para o respectivo cluster:
- schema_change_detection_address - As verificações serão executadas usando SHOW TABLES/SHOW CREATE TABLE para determinar se o esquema foi alterado. As verificações são executadas no endereço especificado e tem o formato HOSTNAME:PORT. Os schema_change_detection_databases também deve ser definido. Um diferencial de uma tabela alterada é criado (usando diff).
- schema_change_detection_databases - Lista separada por vírgulas de bancos de dados para monitorar alterações de esquema. Se estiver vazio, nenhuma verificação será feita.
Neste exemplo, gostaríamos de monitorar as alterações de esquema para o banco de dados "myapp" e "sbtest" em nosso cluster MariaDB com ID de cluster 27. Escolha um dos nós do banco de dados como o valor de schema_change_detection_address . Para a replicação do MySQL, este deve ser o host mestre ou qualquer host escravo que contenha os bancos de dados (caso a replicação parcial esteja ativa). Em seguida, dentro de /etc/cmon.d/cmon_27.cnf, adicione as duas linhas a seguir:
schema_change_detection_address=10.0.0.30:3306
schema_change_detection_databases=myapp,sbtestReinicie o serviço CMON para carregar a mudança:
$ systemctl restart cmonPara o primeiro e principal relatório, o ClusterControl retorna apenas o resultado da coleta de metadados, semelhante ao abaixo:
Com o primeiro relatório como linha de base, os relatórios subsequentes retornarão a saída que esperamos:
Observe que apenas novas tabelas ou tabelas alteradas são impressas no relatório. O primeiro relatório é apenas para coleta de metadados para comparação nas rodadas subsequentes, portanto, temos que executá-lo pelo menos duas vezes para ver a diferença.
Com este relatório, agora você pode reunir as pegadas da estrutura do banco de dados e entender como seu banco de dados evoluiu ao longo do tempo.
Considerações finais
O relatório operacional é uma maneira abrangente de entender o estado de sua infraestrutura de banco de dados. Ele foi desenvolvido para a equipe operacional ou gerencial e pode ser muito útil na análise de suas operações de banco de dados. Os relatórios podem ser gerados no local ou podem ser entregues a você por e-mail, o que torna as coisas convenientemente fáceis se você tiver um silo de relatórios.
Adoraríamos ouvir seus comentários sobre qualquer outra coisa que você gostaria de incluir no relatório, o que está faltando e o que não é necessário.
