Monitoramento proativo do MySQL (Developer Studio/Advisors Angle)

Monitorar seu banco de dados MySQL proativamente é imperativo hoje em dia. Ele desempenha um papel crucial e significativo para gerenciar e controlar seu banco de dados, especialmente para seus clusters de nível de produção. A falta de informações específicas que seriam benéficas para melhorar seu banco de dados ou não identificar se a causa raiz dos problemas que podem ser encontrados pode produzir extrema dificuldade para corrigir ou recuperar de seus dias de glória.

O monitoramento proativo em seu banco de dados MySQL permite que sua equipe entenda o desempenho de seus serviços de banco de dados. Funciona e entrega com base na carga de trabalho que se espera que carregue? Você tem recursos suficientes para que o servidor tenha desempenho com base na carga de trabalho que ele está manipulando no momento? O monitoramento proativo aplica coisas que devem evitar desastres ou danos ao seu banco de dados, que devem notificá-lo com antecedência. Assim, permitindo que os DBAs ou administradores executem tarefas importantes para evitar problemas de funcionamento, corrupção de dados, explorações e ataques de segurança ou rejeição inesperada de tráfego em seu cluster de banco de dados. Com o atendimento imediato, o monitoramento proativo do MySQL deve ser automatizado e deve funcionar 24 horas por dia, 7 dias por semana, sem interrupção e cabe aos DBAs, Devops, administradores decidir se com base na prioridade das tarefas e quão crucial é se requer manutenção ou apenas um trabalho típico de rotina diária.

Monitoramento proativo com ClusterControl

ClusterControl oferece um estilo diversificado para monitorar seus servidores de banco de dados MySQL. Sua abordagem é comparável a outras ferramentas de monitoramento empresarial e a soluções em nuvem de nível empresarial. O ClusterControl tende a aplicar todas as melhores práticas para gerenciar e monitorar os bancos de dados, mas com a flexibilidade de configurar para obter a configuração desejada com base em seu ambiente.

Quando se trata de alarmes e notificações, o ClusterControl tem uma abordagem mista para a qual há alarmes integrados e há os Advisors, sobre os quais discutiremos mais neste blog.

Alarmes de controle de cluster para MySQL

Os alarmes indicam problemas que podem afetar ou degradar o cluster como um todo. Essa interface fornece uma explicação detalhada sobre o problema, juntamente com a ação recomendada (se disponível) para resolver o problema. Cada alarme é categorizado como:

• Agrupamento
  

• Recuperação de cluster
  

• Integridade do banco de dados
  

• Desempenho do banco de dados
  

• Anfitrião
  

• Nó
  

• Rede
  

Um alarme pode ser reconhecido marcando a opção Ignorar? caixa de seleção. Quando ignorado, nenhuma notificação será enviada por e-mail. Um alarme não pode ser excluído ou descartado, embora você possa ocultá-lo da lista clicando no botão Ocultar alarmes ignorados.

Veja a captura de tela de exemplo abaixo,

Proatividade com ClusterControl

ClusterControl suporta recuperação automática que reage sempre que ocorre uma detecção de falha. Auto Recovery com ClusterControl é uma das funcionalidades mais proativas que desempenha um papel crucial em caso de desastres.

A ativação da recuperação automática é necessária para esse monitoramento proativo que reage em várias situações, por exemplo, se o nó MySQL primário falhar.

No ClusterControl, isso será detectado imediatamente, pois ele escuta a conexão com o servidor de banco de dados ou, neste caso, o servidor primário. O ClusterControl reagirá o mais rápido possível e aplicará um failover.

O failover faz parte da recuperação de cluster habilitada. Como ambos os botões Cluster e Node estão habilitados, segue-se a recuperação do nó como você vê abaixo.

Dependendo da acessibilidade dos nós, o ClusterControl tentará continuamente por conectando através de SSH e tente alcançar o nó e tente recuperar começando usando sysvinit ou systemd. Obviamente, você pode pensar que ele aplica um failover e o ClusterControl tenta iniciar o primário com falha. Isso pode significar que dois nós de banco de dados estão disponíveis, certo? Embora seja verdade, o ClusterControl levará o primário com falha para um estado somente leitura durante a recuperação. Ver abaixo,

Embora existam certas opções que você pode definir para gerenciar o mecanismo de failover, você deve consultar nossa documentação para isso, pois não é o foco deste blog.

Usando Advisors para Proatividade com ClusterControl

No ClusterControl, os Advisors serão localizados indo para → Performance → Advisors. Os orientadores do ClusterControl são configurados para serem aplicados dependendo do cluster que está tentando monitorar. Por exemplo, uma Replicação MySQL e MySQL com Galera Cluster rodando em Percona ou MariaDB podem ter diferenças. Por exemplo, os MySQL Replication Advisors têm o seguinte,

Enquanto em um Galera Cluster, ele adiciona os conselheiros específicos do Galera conforme mostrado abaixo ,

Personalizando seus conselheiros MySQL do ClusterControl

Os conselheiros são personalizáveis ​​e podem ser modificados de acordo com suas necessidades. Na captura de tela dos Advisors acima, basta clicar em Editar e você será redirecionado para o IDE simples que incorporamos no ClusterControl.

Você também pode criar seus próprios ClusterControl Advisors. Você pode consultar a si mesmo para saber mais sobre a criação lendo Escreva seu primeiro conselheiro ou faça a série de 2 partes para criar o seu próprio usando o script de detecção Meltdown/Spectre.

Como os consultores do ClusterControl estão sendo proativos?

Tecnicamente, os orientadores do ClusterControl atuam principalmente como um notificador e literalmente seus orientadores. ClusterControl Advisors irá notificá-lo se detectar um comportamento incomum se ultrapassar os limites básicos definidos por padrão pelo ClusterControl. Normalmente, os limites aplicados são valores genéricos. Esses valores genéricos são baseados nas melhores práticas e na configuração de ambiente ou carga de trabalho mais comum e aceitável. A maioria dos padrões dos orientadores não fornece alarmes ou mecanismos de alerta na interface do usuário do ClusterControl. Ele notifica você por meio da interface do usuário (veja a captura de tela de exemplo do consultor Binlog Storage Location abaixo).

Como mencionado anteriormente, os Advisors podem ser modificados e editáveis ​​por meio de nosso editor simples ou IDE. Por exemplo, em um cluster de Replicação MySQL, o ClusterControl fornece um orientador Binlog Storage Location. Ele detecta que os logs binários estão armazenados no diretório de dados onde avisa que deve estar fora do diretório de dados.

Vamos pegar um exemplo da lista de orientadores e selecionar Conexões atualmente usadas orientador . Vamos editar isso como mostrado abaixo,

ou, alternativamente, você pode ir para → Gerenciar → Developer Studio e selecione o connections_used_pct.js conforme mostrado abaixo.

Ao torná-lo mais proativo enviando alarmes, você pode modificá-lo e adicionar as seguintes funções como abaixo,

function myAlarm(title, message, recommendation)
{
  return Alarm::alarmId(
        Node,
      true,
        title,
        message,
        recommendation
  );
}

Considerando que, definindo o limite para 20, adicione essas linhas abaixo apenas dentro da instrução de condição if, onde o limite é atingido acima do valor limite fornecido.

                 myAlarmId = myAlarm(TITLE, msg, ADVICE_WARNING);
                // Let's raise an alarm.
                host.raiseAlarm(myAlarmId, Warning);
Here's the complete script with my modifications in bold,
#include "common/mysql_helper.js"
var DESCRIPTION="This advisor calculates the percentage of threads_connected over max_connections,"
                " if the percentage is higher than 20% you will be notified,"
                " preventing your database server from becoming unstable.";
var WARNING_THRESHOLD=20;
var TITLE="Connections currently used";
var ADVICE_WARNING="You are using more than " + WARNING_THRESHOLD +
    "% of the max_connections."
    " Consider regulating load, e.g by using HAProxy. Using up all connections"
    " may render the database server unusable.";
var ADVICE_OK="The percentage of currently used connections is satisfactory." ;

function myAlarm(title, message, recommendation)
{
  return Alarm::alarmId(
        Node,
      true,
        title,
        message,
        recommendation
  );
}


function main()
{
    var hosts     = cluster::mySqlNodes();
    var advisorMap = {};
    for (idx = 0; idx < hosts.size(); ++idx)
    {
        host        = hosts[idx];
        map         = host.toMap();
        connected     = map["connected"];
        var advice = new CmonAdvice();
        print("   ");
        print(host);
        print("==========================");
        if (!connected)
        {
            print("Not connected");
            continue;
        }
        var Threads_connected = host.sqlStatusVariable("Threads_connected");
        var Max_connections   = host.sqlSystemVariable("Max_connections");
        if (Threads_connected.isError() || Max_connections.isError())
        {
            justification = "";
            msg = "Not enough data to calculate";
        }
        else
        {
            var used = round(100 * Threads_connected / Max_connections,1);
            if (used > WARNING_THRESHOLD)
            {
                advice.setSeverity(1);
                msg = ADVICE_WARNING;
                justification = used + "% of the connections is currently used,"
                " which is > " + WARNING_THRESHOLD + "% of max_connections.";
                 myAlarmId = myAlarm(TITLE, msg, ADVICE_WARNING);
                // Let's raise an alarm.
                host.raiseAlarm(myAlarmId, Warning);
            }
            else
            {
                justification = used + "% of the connections is currently used,"
                " which is < 90% of max_connections.";
                advice.setSeverity(0);
                msg = ADVICE_OK;
            }
        }
        advice.setHost(host);
        advice.setTitle(TITLE);
        advice.setJustification(justification);
        advice.setAdvice(msg);
        advisorMap[idx]= advice;
        print(advice.toString("%E"));
    }
    return advisorMap;
}

Você pode usar o sysbench para testá-lo. No meu teste, sou notificado proativamente enviando o alarme. Isso também deve ser enviado para mim por e-mail ou pode ser notificado se você tiver integrado notificações de terceiros. Veja a imagem abaixo,

Ressalvas dos Consultores do ClusterControl

Modificar ou editar um orientador existente no ClusterControl é aplicado a todos os clusters. Isso significa que você precisa verificar em seu script se ele possui uma condição específica aplicável apenas ao seu cluster existente (ou MySQL ou outros bancos de dados suportados pelo ClusterControl). Isso ocorre porque os orientadores do ClusterControl são armazenados em uma única fonte apenas por meio de nosso banco de dados cmon. Eles são puxados ou recuperados por todos os clusters que você criou no ClusterControl.

Por exemplo, você pode fazer isso em um script:

    var hosts     =cluster::mySqlNodes();

    var advisorMap ={};

    print(hosts[1].clusterId());

Este script imprimirá o ID do cluster. Depois de obter o valor, atribua-o a uma variável e use essa variável para avaliar se é verdade que esse ID de cluster específico é aceitável ou não com base na tarefa desejada a ser executada pelo seu orientador. Deixe dizer,

function main()
{
    var hosts     = cluster::mySqlNodes();
    var advisorMap = {};
    for (idx = 0; idx < hosts.size(); ++idx)
    {
        host        = hosts[idx];
        map         = host.toMap();
        connected     = map["connected"];
        var advice = new CmonAdvice();
        print("   ");
        print(host);
        print("==========================");
        if (host.clusterId() == 15)
        {
            print("Not applicable for cluster id == 15");
            continue;
        }
…
….
…..

o que significa que se for o cluster_id ==15, basta pular ou continuar para o próximo loop.

Conclusão

Criar ou modificar os ClusterControl Advisors é uma boa oportunidade para aproveitar a funcionalidade oculta que o ClusterControl pode fornecer. Pode parecer estar oculto, mas está lá - é só que o recurso é menos usado. Ele fornece um recurso simples, mas poderoso, chamado ClusterControl Domain Specific Language (CDSL), que pode ser usado para tarefas extremamente difíceis que o ClusterControl não possui. Apenas certifique-se de conhecer todas as advertências e também teste tudo antes de finalmente aplicá-lo ao seu ambiente de produção.

ClusterControl:introdução ao novo monitor de consultas

ClusterControl - Gerenciamento Avançado de Backup - mariabackup Parte III

• 

  Uma introdução à implantação do MySQL usando uma função Ansible

• 

  WAMP não pode acessar na rede local 403 Proibido

• 

  Exportando Tabela Oracle para planilha do Excel

• 

  Migrando do DB2 para o PostgreSQL - O que você deve saber