Автоматизирана проверка на конфигурацията на базата данни

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

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

Инструменти за управление на конфигурацията

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

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

Следният пример показва шаблонен файл за конфигурация на MySQL:

[mysqld]
thread_concurrency = <%= processorcount.to_i * 2 %>
# Replication
log-bin            = /var/lib/mysql/mysql-bin.log
log-bin-index      = /var/lib/mysql/mysql-bin.index
binlog_format      = mixed
server-id         = <%= @mysql_server_id or 1 %>

# InnoDB
innodb_buffer_pool_size = <%= (memorysizeinbytes.to_i / 2 / 1024 / 1024).to_i -%>M
innodb_log_file_size    = <%= ((memorysizeinbytes.to_i / 2 / 1024 / 1024) * 0.25).to_i -%>M

Както е показано по-горе, стойността на конфигурацията може да бъде фиксирана стойност или динамично изчислена. Следователно, крайният резултат може да бъде различен според хардуерната спецификация на целевия хост с други предварително дефинирани променливи. Във файла с дефиниция на Puppet можем да избутаме нашия шаблон за конфигурация по следния начин:

# Apply our custom template
file { '/etc/mysql/conf.d/my-custom-config.cnf':
  ensure  => file,
  content => template('mysql/my-custom-config.cnf.erb')
}

Освен шаблониране, можем също да избутаме конфигурационните стойности директно от файла с дефиниция. По-долу е даден пример за дефиниция на Puppet за конфигурация на MariaDB 10.5 с помощта на Puppet MySQL модул:

# MariaDB configuration
class {'::mysql::server':
  package_name     => 'mariadb-server',
  service_name     => 'mariadb',
  root_password    => 't5[sb^D[+rt8bBYu',
  manage_config_file => true,
  override_options => {
    mysqld => {
      'bind_address' => '127.0.0.1',
      'max_connections' => '500',
      'log_error' => '/var/log/mysql/mariadb.log',
      'pid_file'  => '/var/run/mysqld/mysqld.pid',
    },
    mysqld_safe => {
      'log_error' => '/var/log/mysql/mariadb.log',
    },
  }
}

Горещият пример показва, че използвахме manage_config_file => true с override_options, за да структурираме нашите конфигурационни редове, които по-късно ще бъдат изтласкани от Puppet. Всяка промяна на файла на манифеста ще отразява само съдържанието на целевия конфигурационен файл на MySQL. Този модул няма нито да зареди конфигурацията във времето за изпълнение, нито да рестартира услугата MySQL след натискане на промените в конфигурационния файл. Отговорност на SysAdmin е да рестартира услугата, за да активира промените.

За Puppet и Chef проверете изхода на дневника на агента, за да видите дали опциите за конфигурация са коригирани. За Ansible просто погледнете изхода за отстраняване на грешки, за да видите дали поздравленията са актуализирани успешно. Използването на инструменти за управление на конфигурацията може да ви помогне да автоматизирате проверките на конфигурацията и да наложите централизиран подход за конфигуриране.

MySQL Shell

Проверката за здравина е важна преди извършване на каквото и да е надграждане. MySQL Shell има много готина функция, която е предназначена да изпълнява серия от тестове, за да провери дали съществуващата ви инсталация е безопасна за надграждане до MySQL 8.0, наречена Upgrade Checker Utility. Можете да спестите много време, когато се подготвяте за надстройка. Голямо надграждане, особено на MySQL 8.0, въвежда и отменя много опции за конфигурация и следователно крие голям риск от несъвместимост след надстройката.

Този инструмент е специално проектиран за MySQL (включен Percona Server), особено когато искате да извършите сериозна надстройка от MySQL 5.7 до MySQL 8.0. За да извикате тази помощна програма, свържете се с MySQL Shell и като root потребител посочете идентификационните данни, целевата версия и конфигурационния файл:

$ mysqlsh
mysql> util.checkForServerUpgrade('[email protected]:3306', {"password":"p4ssw0rd", "targetVersion":"8.0.11", "configPath":"/etc/my.cnf"})

В долната част на отчета ще получите основното обобщение:

Errors:   7
Warnings: 36
Notices:  0

7 errors were found. Please correct these issues before upgrading to avoid compatibility issues.

Съсредоточете се първо върху коригирането на всички грешки, защото това ще причини големи проблеми след надстройката, ако не се предприемат действия. Обърнете внимание на генерирания отчет и намерете всички проблеми с формулировката „Грешка:“ вградена, например:

15) Removed system variables

  Error: Following system variables that were detected as being used will be
    removed. Please update your system to not rely on them before the upgrade.
  More information: https://dev.mysql.com/doc/refman/8.0/en/added-deprecated-removed.html#optvars-removed

  log_builtin_as_identified_by_password - is set and will be removed
  show_compatibility_56 - is set and will be removed

След като всички грешки бъдат коригирани, опитайте да намалите предупрежденията, доколкото е възможно. Предупрежденията най-вече няма да повлияят на надеждността на MySQL сървъра, но могат потенциално да влошат производителността или да променят поведението от това, което са използвали. Например, разгледайте следните предупреждения:

13) System variables with new default values

  Warning: Following system variables that are not defined in your
    configuration file will have new default values. Please review if you rely on
    their current values and if so define them before performing upgrade.
  More information:
    https://mysqlserverteam.com/new-defaults-in-mysql-8-0/

  back_log - default value will change
  character_set_server - default value will change from latin1 to utf8mb4
  collation_server - default value will change from latin1_swedish_ci to
    utf8mb4_0900_ai_ci
  event_scheduler - default value will change from OFF to ON
  explicit_defaults_for_timestamp - default value will change from OFF to ON
  innodb_autoinc_lock_mode - default value will change from 1 (consecutive) to
    2 (interleaved)
  innodb_flush_method - default value will change from NULL to fsync (Unix),
    unbuffered (Windows)
  innodb_flush_neighbors - default value will change from 1 (enable) to 0
    (disable)
  innodb_max_dirty_pages_pct - default value will change from 75 (%)  90 (%)
  innodb_max_dirty_pages_pct_lwm - default value will change from_0 (%) to 10
    (%)
  innodb_undo_log_truncate - default value will change from OFF to ON
  innodb_undo_tablespaces - default value will change from 0 to 2
  log_error_verbosity - default value will change from 3 (Notes) to 2 (Warning)
  max_allowed_packet - default value will change from 4194304 (4MB) to 67108864
    (64MB)
  max_error_count - default value will change from 64 to 1024
  optimizer_trace_max_mem_size - default value will change from 16KB to 1MB
  performance_schema_consumer_events_transactions_current - default value will
    change from OFF to ON
  performance_schema_consumer_events_transactions_history - default value will
    change from OFF to ON
  slave_rows_search_algorithms - default value will change from 'INDEX_SCAN,
    TABLE_SCAN' to 'INDEX_SCAN, HASH_SCAN'
  table_open_cache - default value will change from 2000 to 4000
  transaction_write_set_extraction - default value will change from OFF to
    XXHASH64

Помощната програма за проверка на надстройката предоставя критичен преглед на това какво да очакваме и ни предпазва от огромна изненада след надстройката.

Съветници за ClusterControl

ClusterControl има редица вътрешни мини-програми, наречени Advisors, където пишете малка програма, която живее и работи в структурата на обектите на ClusterControl. Можете да го мислите като планирана функция, която изпълнява скрипт, създаден в Developer Studio, и произвежда резултат, съдържащ състояние, съвет и обосновка. Това позволява на потребителите лесно да разширят функционалността на ClusterControl чрез създаване на персонализирани съветници, които могат да работят при поискване или по график.

Следната екранна снимка показва пример за InnoDB Advisors, наречен проверка innodb_log_file_size, след като е бил активиран и планиран в ClusterControl:

Горният резултат може да бъде намерен в ClusterControl -> Performance -> Advisors. За всеки съветник той показва състоянието на съветника, екземпляр на базата данни, обосновка и съвет. Има също информация за графика и последното време на изпълнение. Съветникът може да бъде изпълнен и при поискване, като щракнете върху бутона „Компилиране и стартиране“ под Developer Studio.

Горещите съветници, съдържащи следния код, написан с помощта на ClusterControl Domain-Specific Language (DSL), който е доста подобен на JavaScript:

#include "common/mysql_helper.js"
#include "cmon/graph.h"

var DESCRIPTION="This advisor calculates the InnoDB log growth per hour and"
" compares it with the innodb_log_file_size configured on the host and"
" notifies you if the InnoDB log growth is higher than what is configured, which is important to avoid IO spikes during flushing.";
var TITLE="Innodb_log_file_size check";
var MINUTES = 20;


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;
        }
        if (checkPrecond(host))
        {
            var configured_logfile_sz = host.sqlSystemVariable("innodb_log_file_size");
            var configured_logfile_grps = host.sqlSystemVariable("innodb_log_files_in_group");
            if (configured_logfile_sz.isError() || configured_logfile_grps.isError())
            {
                justification = "";
                msg = "Not enough data to calculate";
                advice.setTitle(TITLE);
                advice.setJustification("");
                advice.setAdvice(msg);
                advice.setHost(host);
                advice.setSeverity(Ok);
                advisorMap[idx]= advice;
                continue;
            }
            var endTime   = CmonDateTime::currentDateTime();
            var startTime = endTime - MINUTES * 60 /*seconds*/;
            var stats     = host.sqlStats(startTime, endTime);
            var array     = stats.toArray("created,interval,INNODB_LSN_CURRENT");

            if(array[2,0] === #N/A  || array[2,0] == "")
            {
                /* Not all vendors have INNODB_LSN_CURRENT*/
                advice.setTitle(TITLE);
                advice.setJustification("INNODB_LSN_CURRENT does not exists in"
                                        " this MySQL release.");
                advice.setAdvice("Nothing to do.");
                advice.setHost(host);
                advice.setSeverity(Ok);
                advisorMap[idx]= advice;
                continue;
            }
            var firstLSN = array[2,0].toULongLong();
            var latestLSN = array[2,array.columns()-1].toULongLong();
            var intervalSecs = endTime.toULongLong() - startTime.toULongLong();
            var logGrowthPerHourMB = ceiling((latestLSN - firstLSN) * 3600 / 1024/1024 / intervalSecs / configured_logfile_grps);
            var logConfiguredMB =  configured_logfile_sz/1024/1024;
            if (logGrowthPerHourMB > logConfiguredMB)
            {
                justification = "Innodb is producing " + logGrowthPerHourMB + "MB/hour, and it greater than"
                " the configured innodb log file size " + logConfiguredMB + "MB."
                " You should set innodb_log_file_size to a value greater than " +
                    logGrowthPerHourMB + "MB. To change"
                " it you must stop the MySQL Server and remove the existing ib_logfileX,"
                " and start the server again. Check the MySQL reference manual for max/min values. "
                "https://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_log_file_size";
                msg = "You are recommended to increase the innodb_log_file_size to avoid i/o spikes"
                " during flushing.";
                advice.setSeverity(Warning);
            }
            else
            {
                justification = "Innodb_log_file_size is set to " + logConfiguredMB +
                    "MB and is greater than the log produced per hour: " +
                    logGrowthPerHourMB + "MB.";
                msg = "Innodb_log_file_size is sized sufficiently.";
                advice.setSeverity(Ok);
            }
        }
        else
        {
            justification = "Server uptime and load is too low.";
            msg = "Not enough data to calculate";
            advice.setSeverity(0);
        }
        advice.setHost(host);
        advice.setTitle(TITLE);
        advice.setJustification(justification);
        advice.setAdvice(msg);
        advisorMap[idx]= advice;
        print(advice.toString("%E"));
    }
    return advisorMap;
}

ClusterControl предоставя готова интегрирана среда за разработка (IDE), наречена Developer Studio (достъпна под Управление -> Developer Studio), за писане, компилиране, запазване, отстраняване на грешки и планиране на съветника:

С Developer Studio и Advisors потребителите нямат ограничение в разширяването на функциите за наблюдение и управление на ClusterControl. Това е буквално идеалният инструмент за автоматизиране на проверката на конфигурацията за целия ви софтуер за база данни с отворен код като MySQL, MariaDB, PostgreSQL и MongoDB, както и за балансиращите устройства като HAProxy, ProxySQL, MaxScale и PgBouncer. Можете дори да напишете съветник, за да използвате помощната програма за проверка на надстройката на MySQL Shell, както е показано в предишната глава.

Последни мисли

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