MongoDB
 sql >> Baza danych >  >> NoSQL >> MongoDB

Zautomatyzuj kontrolę stanu bazy danych

Zapewnienie, że baza danych jest w dobrym stanie, jest jedną z najważniejszych i ważnych rzeczy, które musi zrobić administrator bazy danych. Jeśli zaniedbamy utrzymanie bazy danych, istnieje większe prawdopodobieństwo, że napotkamy problem; na przykład problem z wydajnością bazy danych spowodowany obciążeniem zmieniającym się w czasie lub błędną konfiguracją, która prowadzi do naruszenia danych.

Regularne sprawdzanie konfiguracji, wykorzystania zasobów, procedur tworzenia kopii zapasowych i przywracania, bezpieczeństwa danych, wydajności zapytań może pomóc w uniknięciu problemów z bazą danych. Musimy mieć standardową kontrolę bazy danych dla naszego środowiska bazy danych, abyśmy mogli monitorować, czy baza danych jest nadal pod kontrolą.

Co to jest kontrola stanu bazy danych

Kontrola stanu bazy danych składa się z szeregu zadań sprawdzających stan naszej bazy danych. Dlaczego musimy przeprowadzić kontrolę stanu zdrowia? Musimy zidentyfikować i naprawić wszelkie problemy lub anomalie w naszym środowisku bazy danych, niezależnie od tego, czy jest to problem z wydajnością, konfiguracją, czy coś, co może spowodować awarię.

Możemy podzielić kontrolę stanu na kilka kategorii:

  • Sprawdzenie bezpieczeństwa, aby zablokować dostęp do bazy danych i upewnić się, że ruch pochodzi z zaufanej sieci z odpowiednim przywileje.

  • Sprawdzenie konfiguracji, aby upewnić się, że spełnia ona standardowe kryteria zdefiniowane przez organizację.

  • Sprawdzenie wydajności, aby upewnić się, że baza danych korzysta z zasobów sprzętowych i reaguje na aplikacje.

  • Procedury tworzenia kopii zapasowych i przywracania, aby zapewnić możliwość przywrócenia kopii zapasowej, którą pobraliśmy z bazy danych.

Z tych kategorii możemy dokonać podziału tego, co musimy sprawdzić w bazie danych. Jest to bardzo ważne, dlatego możemy dokładnie sprawdzić każdy aspekt. Na przykład:

  • Bezpieczeństwo bazy danych

  • Porównaj użytkownika i uprawnienia w bazie danych z naszym dostępem do macierzy użytkowników

  • Sprawdź adres IP białej listy w bazie danych, czy ruch pochodzi z zaufanej sieci

  • Upewnij się, że rejestrowanie kontrolne bazy danych jest włączone

  • Sprawdzenie konfiguracji

  • Sprawdź, czy SSL jest już na miejscu

  • Upewnij się, że konfiguracja bazy danych jest poprawna (zarówno uprawnienia, jak i własność)

  • Kontrola wydajności

  • Sprawdź współczynnik trafień w pamięci podręcznej bazy danych

  • Upewnij się, że połączenie z bazą danych jest wystarczające do obsługi ruchu

  • Procedura tworzenia kopii zapasowej i przywracania

  • Właściwy harmonogram tworzenia kopii zapasowych, który zapewnia uzgodnione RPO

  • Upewnij się, że testujemy kopie zapasowe, abyśmy wiedzieli, że dane można przywrócić

Na podstawie powyższej listy możemy stworzyć skrypt sprawdzający te elementy w każdym typie bazy danych (np. MySQL, PostgreSQL, MongoDB). Każdy typ bazy danych będzie oczywiście miał inne polecenia.

Automatyzacja kontroli kondycji bazy danych

Nie chcemy uruchamiać powtarzającego się zadania co tydzień lub co miesiąc, sprawdzenie kondycji bazy danych jest zadaniem czasochłonnym. Skrypt uruchamiamy na każdym węźle bazy danych, więc automatyzacja kontroli stanu pozwala nam zaoszczędzić sporo czasu.

Na podstawie listy skryptów sprawdzania kondycji możemy stworzyć skrypt bash do uruchamiania zadań i zaplanować je za pomocą crona. Poniżej znajduje się tylko próbka prostego raportu z kontroli stanu bazy danych:

#!/bin/sh
# Simple database check report
username = "audit_user"
password = "pwd001"
hostname = "db01-payment"
mycnf = "/etc/mysql/my.cnf"
dt=$(date '+%d/%m/%Y %H:%M:%S');
audit_name = "MySQL_Healthcheck_audit_report_"$dt

# check the queries
/bin/mysql -h $hostname -u $username  -p $password --skip-column-names -B -e "SHOW STATUS LIKE 'Queries'" > $audit_name

# check open table cache hit ratio
/bin/mysql -h $hostname -u $username  -p $password --skip-column-names -B -e "SHOW STATUS LIKE 'Table_open_cache_hits'" >> $audit_name

# check the ssl session mode
/bin/mysql -h $hostname -u $username  -p $password --skip-column-names -B -e "SHOW STATUS LIKE 'Ssl_session_cache_mode'" >> $audit_name

# check the buffer pool size
cat $mycnf | grep "innodb_buffer_pool_size" >> $audit_name

#check ssl key in my.cnf
cat $mycnf | grep "ssl_key" >> $audit_name

# check permission of my.conf
ls -ltr $mycnf >> $audit_name

Kontrole stanu zdrowia można również zautomatyzować za pomocą narzędzi do zarządzania konfiguracją, takich jak Ansible, Salt, Chef lub Puppet.

Automatyzacja kontroli stanu bazy danych za pomocą ClusterControl

ClusterControl to platforma operacyjna dla baz danych, która pokazuje problemy ze stanem, wydajnością lub dostępnością serwera w środowisku bazy danych, a wszystko to z centralnej konsoli. Obsługuje automatyzację kontroli kondycji bazy danych za pomocą raportów operacyjnych. Możesz generować lub planować raporty operacyjne, a także raporty o incydentach. Istnieje kilka typów raportów, jak pokazano poniżej:

Dzienny raport systemowy zawiera informacje o bieżącym klastrze bazy danych, który składa się z różne informacje, takie jak stan usługi węzła, stan kopii zapasowej, czas pracy węzłów, podsumowanie najczęstszych zapytań.

Raport aktualizacji pakietów zawiera podsumowanie dostępnych pakietów do aktualizacji z kierownik repozytorium.

Raport o zmianach schematu porównuje zmiany bazy danych w strukturze tabeli, które zaszły między dwoma różnymi wygenerowanymi raportami.

Raporty kopii zapasowych zawierają informacje o podsumowaniu kopii zapasowej i szczegółach, np. ostatnia utworzona kopia zapasowa, stan kopii zapasowej, stan weryfikacji kopii zapasowej i okres przechowywania kopii zapasowej.

Oprócz raportów operacyjnych, istnieją również Doradcy, które zapewniają wgląd w procesor, dysk, połączenia z bazą danych itp., jak poniżej:

Powiadomienia za pośrednictwem poczty e-mail i alertów za pośrednictwem skonfigurowanych kanałów stron trzecich dają wgląd w sprawy, które psują się (np. nieudane kopie zapasowe, kopie zapasowe, których nie można przywrócić, awarie węzłów).

Analizator schematu dostarcza informacji o zduplikowanych/nadmiarowych indeksach, tabelach bez kluczy podstawowych i tabelach korzystających z silnika pamięci masowej MyISAM. Szczególnie warto wiedzieć o nadmiarowych indeksach, ponieważ zwiększają rozmiar bazy danych (i kopii zapasowych) i mogą spowolnić aktualizacje tabeli.


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. MongoDB $asin

  2. Platforma agregująca nie może używać indeksów

  3. Kiedy do Redisa? Kiedy do MongoDB?

  4. Jak mogę przeglądać lub wyszukiwać dane na żywo MongoDB?

  5. Reszta danych rozruchu sprężynowego, ograniczenie @Notnull nie działa