Автоматизирана проверка на състоянието на базата данни

Осигуряването на изправност на базата данни е едно от критичните и важни неща, които администраторът на базата данни трябва да направи. Ако пренебрегнем поддръжката на базата данни, има по-голяма вероятност да се сблъскаме с проблем; например проблем с производителността на базата данни, причинен от работно натоварване, което се е променило с течение на времето, или неправилна конфигурация, която води до пробив на данни.

Редовната проверка на конфигурацията, използването на ресурсите, процедурите за архивиране и възстановяване, сигурността на данните, производителността на заявките може да помогне за избягване на проблеми с базата данни. Трябва да имаме стандартна проверка на базата данни за нашата среда на база данни, за да можем да наблюдаваме дали базата данни все още е под контрол.

Какво е проверка на състоянието на базата данни

Проверката на състоянието на базата данни се състои от редица задачи за проверка на състоянието на нашата база данни. Защо трябва да правим здравна проверка? Трябва да идентифицираме и коригираме всички проблеми или аномалии в средата на нашата база данни, независимо дали става въпрос за проблем с производителността, проблем с конфигурацията или нещо, което може да причини прекъсване.

Можем да разделим проверката на здравето в няколко категории:

Проверка на сигурността, за да заключите достъпа до базата данни и да гарантирате, че трафикът идва от надеждна мрежа с правото привилегии.
Проверка на конфигурацията, за да се гарантира, че конфигурацията отговаря на стандартните критерии, определени от организацията.
Проверка на производителността, за да се гарантира, че базата данни използва хардуерните ресурси и отговаря на приложенията.
Процедури за архивиране и възстановяване, за да гарантираме, че резервното копие, което взехме от базата данни, може да бъде възстановено.

От тези категории можем да направим разбивка на това, което трябва да проверим в базата данни. Това е много важно, така че можем да направим подробна проверка на всеки аспект. Например:

Сигурност на базата данни
Сравнете потребителя и привилегиите в базата данни с достъпа до матрицата на потребителите, който имаме
Проверете IP адреса на белия списък в базата данни, дали трафикът идва от надеждна мрежа
Уверете се, че регистрирането на одит на базата данни е активирано
Проверка на конфигурацията
Проверете SSL, който вече е на място
Уверете се, че конфигурацията на базата данни е правилна (както разрешение, така и собственост)
Проверка на производителността
Проверете съотношението на попадане в кеша на базата данни
Уверете се, че връзката с базата данни все още е достатъчно, за да се справи с трафика
Процедура за архивиране и възстановяване
Правилен график за архивиране, който осигурява договореното RPO
Уверете се, че тестваме резервни копия, за да знаем, че данните могат да бъдат възстановени

Въз основа на горния списък можем да създадем скрипт за проверка на тези елементи във всеки тип база данни (напр. MySQL, PostgreSQL, MongoDB). Всеки тип база данни очевидно ще има различни команди.

Автоматизиране на здравните проверки на базата данни

Не искаме да изпълняваме повтаряща се задача на седмична или месечна база, проверката на състоянието на базата данни е отнемаща време задача. Изпълняваме скрипта на всеки възел на базата данни, така че автоматизирането на проверките на здравето ни спестява доста време.

Въз основа на списъка със скриптове за проверка на здравето можем да създадем bash скрипт, за да изпълняваме задачите и да го планираме с cron. По-долу е само извадка от прост отчет за проверка на състоянието на базата данни:

#!/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

Проверките на здравето могат също да бъдат автоматизирани чрез инструменти за управление на конфигурацията, като Ansible, Salt, Chef или Puppet.

Автоматизиране на здравните проверки на базата данни с ClusterControl

ClusterControl е операционна платформа за бази данни, показва проблеми със здравето, производителността или наличността на сървъра в тяхната среда на база данни, всичко това от централна конзола. Той поддържа автоматизиране на проверките на състоянието на базата данни чрез оперативни отчети. Можете да генерирате или планирате оперативните отчети, както и докладите за инциденти. Има няколко типа отчети, както е показано по-долу:

Ежедневният системен отчет ви дава представа за текущия ви клъстер от база данни, който се състои от различна информация, като състояние на услугата на възела, състояние на архивиране, време на работа на възлите, обобщение на най-популярните заявки.

Отчетът за надграждане на пакета ви дава обобщение на наличните пакети за надстройката от мениджър на хранилището.

Отчетът за промени в схемата сравнява промените в базата данни в структура на таблица, които са се случили между два различни генерирани отчета.

Отчетите за архивиране ви предоставят информация за обобщението и подробностите за архивирането, напр. последното създадено архивно копие, състоянието на архива, състоянието на проверка на архива и периода на запазване на архива.

Освен оперативните отчети има и съветници, които ви дават представа за процесора, диска, връзките към базата данни и т.н., както е по-долу:

Уведомленията по имейл и сигнали чрез конфигурирани канали на трети страни дават представа за нещата, които се объркат (напр. неуспешни архиви, невъзстановими архиви, повреди на възли).

Schema Analyzer дава информация за дублиращи се/излишни индекси, таблици без първични ключове и таблици, използващи MyISAM механизъм за съхранение. Излишните индекси могат да бъдат особено добре да знаете, тъй като те увеличават размера на базата данни (и резервните копия) и могат да забавят актуализациите на таблицата.