Nas duas postagens anteriores do blog, abordamos a implantação dos quatro tipos de clustering/replicação (MySQL/Galera, MySQL Replication, MongoDB e PostgreSQL) e o gerenciamento/monitoramento de seus bancos de dados e clusters existentes. Então, depois de ler essas duas primeiras postagens do blog, você conseguiu adicionar suas 20 configurações de replicação existentes ao ClusterControl, expandi-las e, adicionalmente, implantou dois novos clusters Galera enquanto fazia muitas outras coisas. Ou talvez você tenha implantado sistemas MongoDB e/ou PostgreSQL. Então agora, como mantê-los saudáveis?
É exatamente sobre isso que trata este post de blog:como aproveitar o monitoramento de desempenho do ClusterControl e a funcionalidade de conselheiros para manter seus bancos de dados e clusters MySQL, MongoDB e/ou PostgreSQL íntegros. Então, como isso é feito no ClusterControl?
Lista de clusters de banco de dados
As informações mais importantes já podem ser encontradas na lista de clusters:desde que não haja alarmes e nenhum host esteja inativo, tudo está funcionando bem. Um alarme é acionado se uma determinada condição for atendida, por exemplo. host está trocando e chama sua atenção para o problema que você deve investigar. Isso significa que os alarmes não são apenas acionados durante uma interrupção, mas também permitem que você gerencie proativamente seus bancos de dados.
Suponha que você faça login no ClusterControl e veja uma lista de clusters como esta, você definitivamente terá algo para investigar:um nó está inativo no cluster Galera, por exemplo, e cada cluster possui vários alarmes:
Ao clicar em um dos alarmes, você irá para uma página detalhada de todos os alarmes do cluster. Os detalhes do alarme explicarão o problema e, na maioria dos casos, também aconselharão a ação para resolver o problema.
Você pode configurar seus próprios alarmes criando expressões personalizadas, mas isso foi preterido em favor do nosso novo Developer Studio, que permite escrever Javascripts personalizados e executá-los como Advisors. Voltaremos a esse assunto mais adiante neste post.
Visão geral do cluster - Painéis
Ao abrir a visão geral do cluster, podemos ver imediatamente as métricas de desempenho mais importantes para o cluster nas guias. Essa visão geral pode diferir por tipo de cluster, pois, por exemplo, Galera tem métricas de desempenho diferentes a serem observadas do MySQL, PostgreSQL ou MongoDB tradicionais.
Tanto a visão geral padrão quanto as guias pré-selecionadas são personalizáveis. Ao clicar em Visão geral -> Configurações do Dash você recebe um diálogo que permite definir o painel:
Ao pressionar o sinal de mais, você pode adicionar e definir suas próprias métricas para representar graficamente o painel. No nosso caso, definiremos um novo painel com a média da fila de envio e recebimento específica do Galera:
Esse novo painel deve nos dar uma boa visão do comprimento médio da fila do nosso cluster Galera.
Depois de pressionar salvar, o novo painel ficará disponível para este cluster:
Da mesma forma, você também pode fazer isso para o PostgreSQL, por exemplo, podemos monitorar os blocos compartilhados atingidos versus os blocos lidos:
Então, como você pode ver, é relativamente fácil personalizar seu próprio painel (padrão).
Visão geral do cluster - Monitor de consultas
A guia Query Monitor está disponível para configurações baseadas em MySQL e PostgreSQL e consiste em três painéis:Top Queries, Running Queries e Query Outliers.
No painel Consultas em execução, você encontrará todas as consultas atuais em execução. Isso é basicamente o equivalente da instrução SHOW FULL PROCESSLIST no banco de dados MySQL.
As consultas principais e os valores atípicos de consulta dependem da entrada do log de consulta lenta ou do esquema de desempenho. O uso do Performance Schema é sempre recomendado e será usado automaticamente se ativado. Caso contrário, o ClusterControl usará o log de consultas lentas do MySQL para capturar as consultas em execução. Para evitar que o ClusterControl seja muito intrusivo e o log de consulta lenta fique muito grande, o ClusterControl fará uma amostra do log de consulta lenta ativando-o e desativando-o. Este loop é definido por padrão para captura de 1 segundo e o long_query_time está definido para 0,5 segundos. Se você deseja alterar essas configurações para seu cluster, pode alterar isso em Configurações -> Monitor de consultas .
As principais consultas, como o nome diz, mostrarão as principais consultas que foram amostradas. Você pode classificá-los em várias colunas:por exemplo, a frequência, o tempo médio de execução, o tempo total de execução ou o tempo de desvio padrão:
Você pode obter mais detalhes sobre a consulta selecionando-a e isso apresentará o plano de execução da consulta (se disponível) e dicas/avisos de otimização. O Query Outliers é semelhante ao Top Queries, mas permite filtrar as consultas por host e compará-las a tempo.
Visão geral do cluster - Operações
Semelhante aos sistemas PostgreSQL e MySQL, os clusters MongoDB têm a visão geral de operações e são semelhantes às consultas em execução do MySQL. Essa visão geral é semelhante à emissão do comando db.currentOp() no MongoDB.
Visão geral do cluster - Desempenho
MySQL/Galera
A guia de desempenho é provavelmente o melhor lugar para encontrar o desempenho geral e a integridade de seus clusters. Para MySQL e Galera consiste em uma página de visão geral, os conselheiros, visões gerais de status/variáveis, o analisador de esquema e o log de transações.
A página Visão geral fornecerá uma visão geral do gráfico das métricas mais importantes em seu cluster. Isso é, obviamente, diferente por tipo de cluster. Oito métricas foram definidas por padrão, mas você pode definir facilmente as suas próprias - até 20 gráficos, se necessário:
Os Advisors são um dos principais recursos do ClusterControl:os Advisors são verificações com script que podem ser executadas sob demanda. Os conselheiros podem avaliar praticamente qualquer fato conhecido sobre o host e/ou cluster e dar sua opinião sobre a saúde do host e/ou cluster e até mesmo podem dar conselhos sobre como resolver problemas ou melhorar seus hosts!
A melhor parte ainda está por vir:você pode criar suas próprias verificações no Developer Studio (ClusterControl -> Manage -> Developer Studio ), execute-os em intervalos regulares e use-os novamente na seção Advisors. Fizemos um blog sobre esse novo recurso no início deste ano.
Iremos pular a visão geral de status/variáveis do MySQL e Galera, pois isso é útil para referência, mas não para esta postagem no blog:é bom o suficiente que você saiba que está aqui.
Agora suponha que seu banco de dados esteja crescendo, mas você queira saber o quão rápido ele cresceu na semana passada. Na verdade, você pode acompanhar o crescimento dos tamanhos de dados e índices diretamente no ClusterControl:
E ao lado do crescimento total no disco, ele também pode relatar os 25 maiores esquemas.
Outro recurso importante é o Schema Analyzer dentro do ClusterControl:
O ClusterControl analisará seus esquemas e procurará índices redundantes, tabelas MyISAM e tabelas sem chave primária. É claro que depende inteiramente de você manter uma tabela sem uma chave primária porque algum aplicativo pode tê-la criado dessa maneira, mas pelo menos é ótimo obter o conselho aqui gratuitamente. O Schema Analyzer ainda recomenda a instrução ALTER necessária para corrigir o problema.
PostgreSQL
Para PostgreSQL, os Advisors, DB Status e DB Variables podem ser encontrados aqui:
MongoDB
Para o MongoDB, as estatísticas do Mongo e a visão geral de desempenho podem ser encontradas na guia Desempenho. O Mongo Stats é uma visão geral da saída do mongostat e a visão geral do desempenho fornece uma boa visão gráfica dos contadores do MongoDB:
Considerações finais
Mostramos a você como ficar de olho nos recursos mais importantes de monitoramento e verificação de integridade do ClusterControl. Obviamente, este é apenas o começo da jornada, pois em breve iniciaremos outra série de blogs sobre os recursos do Developer Studio e como você pode fazer a maioria de suas próprias verificações. Lembre-se também de que nosso suporte para MongoDB e PostgreSQL não é tão extenso quanto nosso conjunto de ferramentas MySQL, mas estamos melhorando continuamente nisso.
Você pode se perguntar por que ignoramos o monitoramento de desempenho e as verificações de integridade do HAProxy, ProxySQL e MaxScale. Fizemos isso deliberadamente, pois a série de blogs cobria apenas implantações de clusters até agora e não a implantação de componentes de alta disponibilidade. Então esse é o assunto que abordaremos na próxima vez.
