MariaDB
 sql >> Baza danych >  >> RDS >> MariaDB

Proaktywne monitorowanie MySQL (Studio Deweloperskie/Advisors Angle)

Proaktywne monitorowanie bazy danych MySQL jest obecnie niezbędne. Odgrywa kluczową i znaczącą rolę w zarządzaniu bazą danych i kontrolowaniu jej, zwłaszcza w przypadku klastrów klasy produkcyjnej. Brak określonych informacji, które byłyby korzystne dla ulepszenia bazy danych lub brak identyfikacji podstawowej przyczyny problemów, które można napotkać, może powodować ogromne trudności w naprawie lub odzyskaniu z czasów świetności.

Proaktywne monitorowanie bazy danych MySQL pozwala zespołowi zrozumieć, jak działają usługi bazy danych. Czy działa i dostarcza w oparciu o obciążenie, jakie ma ponieść? Czy masz wystarczającą ilość zasobów, aby serwer działał wydajnie w oparciu o aktualnie obsługiwane obciążenie? Proaktywne monitorowanie stosuje rzeczy, które zapobiegną katastrofie lub uszkodzeniu Twojej bazy danych, o czym powiadomią Cię z wyprzedzeniem. Dzięki temu administratorzy lub administratorzy mogą wykonywać ważne zadania, aby uniknąć awarii, uszkodzenia danych, luk w zabezpieczeniach i ataków lub nieoczekiwanego odbicia ruchu w klastrze bazy danych. Uwzględniając je natychmiast, proaktywne monitorowanie MySQL musi być zautomatyzowane i powinno działać 24 godziny na dobę, 7 dni w tygodniu bez przerwy, a to DBA, Devops, administratorzy decydują, czy na podstawie priorytetu zadań i jak ważne jest to, czy wymaga konserwacji, czy tylko typowa codzienna rutynowa praca.

Proaktywne monitorowanie za pomocą ClusterControl

ClusterControl oferuje zróżnicowany styl monitorowania serwerów baz danych MySQL. Jego podejście jest porównywalne z innymi narzędziami do monitorowania przedsiębiorstwa i rozwiązaniami chmurowymi klasy korporacyjnej. ClusterControl ma tendencję do stosowania wszystkich najlepszych praktyk w zakresie zarządzania i monitorowania baz danych, ale z elastycznością konfiguracji w celu uzyskania pożądanej konfiguracji w Twoim środowisku.

Jeśli chodzi o alarmy i powiadomienia, ClusterControl ma mieszane podejście, w którym są wbudowane alarmy, a ponadto są też Doradcy, o których więcej omówimy w tym blogu.

Alarmy ClusterControl dla MySQL

Alarmy wskazują problemy, które mogą mieć wpływ na klaster jako całość lub go zniszczyć. Ten interfejs zawiera szczegółowe wyjaśnienie problemu wraz z zalecaną czynnością (jeśli jest dostępna) w celu rozwiązania problemu. Każdy alarm jest sklasyfikowany jako:

  • Klaster

  • Odzyskiwanie klastra

  • Stan bazy danych

  • Wydajność bazy danych

  • Host

  • Węzeł

  • Sieć

Alarm można potwierdzić, zaznaczając opcję Ignoruj? pole wyboru. W przypadku zignorowania żadne powiadomienie nie zostanie wysłane e-mailem. Alarmu nie można usunąć ani odrzucić, ale można go ukryć na liście, klikając przycisk Ukryj ignorowane alarmy.

Zobacz przykładowy zrzut ekranu poniżej,

Proaktywność z ClusterControl

ClusterControl obsługuje automatyczne przywracanie, które reaguje w przypadku wykrycia awarii. Automatyczne odzyskiwanie z ClusterControl to jedna z najbardziej proaktywnych funkcji, która odgrywa kluczową rolę w przypadku katastrof.

Włączenie automatycznego odzyskiwania jest wymagane do tego proaktywnego monitorowania, które reaguje w różnych sytuacjach, na przykład, jeśli podstawowy węzeł MySQL ulegnie awarii.

W ClusterControl zostanie to wykryte od razu, gdy nasłuchuje połączenia z serwerem bazy danych lub w tym przypadku z serwerem głównym. ClusterControl zareaguje jak najszybciej i zastosuje przełączenie awaryjne.

Przełączenie awaryjne jest częścią włączonego odzyskiwania klastra. Ponieważ oba przyciski Cluster i Node są włączone, następuje odzyskiwanie węzła, jak widać poniżej.

W zależności od osiągalności węzłów, ClusterControl będzie próbował nieprzerwanie podejmować próby łączenie się przez SSH i spróbuj połączyć się z węzłem i spróbuj odzyskać, zaczynając od sysvinit lub systemd. Oczywiście możesz pomyśleć, że stosuje przełączenie awaryjne, a ClusterControl próbuje uruchomić nieudany podstawowy. To może oznaczać, że dostępne są dwa węzły bazy danych, prawda? Chociaż prawda, ClusterControl przeniesie uszkodzony element podstawowy do stanu tylko do odczytu podczas odzyskiwania. Zobacz poniżej,

Chociaż istnieją pewne opcje, które można ustawić w celu zarządzania mechanizmem przełączania awaryjnego, należy zapoznać się z naszą dokumentacją, ponieważ nie jest to tematem tego bloga.

Korzystanie z Advisors do proaktywności z ClusterControl

W ClusterControl doradcy zostaną zlokalizowani, przechodząc do → Wydajność → Doradcy. Doradcy ClusterControl są ustawiani do stosowania w zależności od klastra, który próbuje monitorować. Na przykład replikacja MySQL i MySQL z klastrem Galera działającym na Perconie lub MariaDB mogą się różnić. Na przykład Doradcy MySQL Replication mają następujące elementy:

Będąc w klastrze Galera, dodaje on konkretnych doradców Galera, jak pokazano poniżej ,

Dostosowywanie doradców ClusterControl MySQL

Doradców można dostosowywać i modyfikować zgodnie z własnymi potrzebami. Na powyższym zrzucie ekranu doradców kliknij Edytuj, a zostaniesz przekierowany do prostego IDE, które mamy wbudowane w ClusterControl.

Możesz także tworzyć własnych doradców ClusterControl. Możesz polecić sobie, aby dowiedzieć się więcej o tworzeniu, czytając Napisz swojego pierwszego doradcę lub weź udział w dwuczęściowej serii, aby stworzyć własną przy użyciu skryptu wykrywania Meltdown/Spectre.

Jak doradcy ClusterControl działają proaktywnie?

Technicznie rzecz biorąc, doradcy ClusterControl działają głównie jako powiadamiający i dosłownie doradcy. Doradcy ClusterControl powiadomią Cię, jeśli wykryją nietypowe zachowanie, jeśli przekroczą podstawowe progi ustawione domyślnie przez ClusterControl. Zazwyczaj stosowane progi są wartościami ogólnymi. Te wartości ogólne są oparte na najlepszych praktykach oraz na najczęstszym i akceptowalnym obciążeniu lub konfiguracji środowiska. Większość domyślnych funkcji doradców nie zapewnia alarmów ani mechanizmów alertów w interfejsie użytkownika ClusterControl. Powiadamia Cię za pomocą interfejsu użytkownika (patrz przykładowy zrzut ekranu doradcy Binlog Storage Location poniżej).

Jak wspomniano wcześniej, Doradcy można modyfikować i edytować za pomocą naszego prostego edytora lub IDE. Na przykład w klastrze MySQL Replication ClusterControl udostępnia doradcę Binlog Storage Location. Wykrywa, że ​​binlogi są przechowywane w katalogu danych, gdzie informuje, że muszą znajdować się poza katalogiem danych.

Weźmy przykład z listy doradców i wybierzmy aktualnie używany doradca . Edytujmy to, jak pokazano poniżej,

lub możesz przejść do → Zarządzaj → Developer Studio i wybierz connection_used_pct.js, jak pokazano poniżej.

 

Dzięki zwiększeniu aktywności poprzez wysyłanie alarmów możesz je modyfikować i dodawać następujące funkcje jak poniżej,

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

Zważywszy, że ustawienie progu na 20, a następnie dodanie tych wierszy poniżej, tuż w instrukcji warunkowej if, gdzie próg został osiągnięty powyżej podanej wartości progowej.

                 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;
}

Możesz użyć sysbench do przetestowania tego. W moim teście jestem proaktywnie powiadamiany, wysyłając alarm. Zostanie to również wysłane do mnie e-mailem lub może zostać powiadomione, jeśli masz zintegrowane powiadomienia stron trzecich. Zobacz zrzut ekranu poniżej,

Ostrzeżenia Doradców ClusterControl

Modyfikowanie lub edytowanie istniejącego doradcy w ClusterControl jest stosowane do wszystkich klastrów. Oznacza to, że musisz sprawdzić w swoim skrypcie, czy ma on określony warunek mający zastosowanie tylko do istniejącego klastra (MySQL lub inne obsługiwane bazy danych przez ClusterControl). Dzieje się tak, ponieważ doradcy ClusterControl są przechowywani w jednym źródle tylko za pośrednictwem naszej bazy danych cmon. Są one pobierane lub pobierane przez wszystkie klastry utworzone w ClusterControl.

Możesz na przykład zrobić to w skrypcie:

    zmienne hosty     =cluster::mySqlNodes();

    var doradcaMapa ={};

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

Ten skrypt wydrukuje identyfikator klastra. Po uzyskaniu wartości przypisz ją do zmiennej i użyj tej zmiennej, aby ocenić, czy to prawda, że ​​ten konkretny identyfikator klastra jest akceptowalny, czy nie, w oparciu o pożądane zadanie do wykonania przez doradcę. Powiedzmy,

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;
        }
…
….
…..

co oznacza, że ​​jeśli jest to cluster_id ==15, po prostu pomiń lub przejdź do następnej pętli.

Wnioski

Tworzenie lub modyfikowanie ClusterControl Advisors jest dobrą okazją do wykorzystania ukrytej funkcjonalności, jaką może zapewnić ClusterControl. Może wydawać się, że jest ukryta, ale jest tam - po prostu ta funkcja jest mniej używana. Zapewnia prostą, ale potężną funkcję o nazwie ClusterControl Domain Specific Language (CDSL), która może być używana do niezwykle trudnych zadań, których brakuje w ClusterControl. Upewnij się tylko, że znasz wszystkie zastrzeżenia, a także przetestuj wszystko, zanim ostatecznie zastosujesz je w swoim środowisku produkcyjnym.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Zapowiedź ClusterControl 1.7.3:ulepszona obsługa PostgreSQL i nowe opcje wdrażania w chmurze

  2. Jak LOAD_FILE() działa w MariaDB

  3. Jak wykonywać i zarządzać kopiami zapasowymi MySQL dla Oracle DBA

  4. 8 sposobów na dodawanie dni do daty w MariaDB

  5. Napraw „BŁĄD 1054 (42S22):Nieznana kolumna „…” w „klauzula” w MariaDB