Mnoho systémových administrátorů běžně přehlíží důležitost průběžného ladění konfigurace databáze. Možnosti konfigurace jsou často konfigurovány nebo laděny jednou, během fáze instalace, a jsou vynechány, dokud se v databázové službě nevyskytnou nějaké nežádoucí události. Teprve potom by bylo možné věnovat více pozornosti opětovné návštěvě konfiguračních možností a vyladění limitů, prahů, vyrovnávacích pamětí, mezipaměti atd. ve snaze znovu obnovit databázovou službu.
V tomto příspěvku na blogu se zaměřujeme na automatizaci kontroly konfigurace databáze a procesu ověřování. Toto je důležitý proces, protože možnosti konfigurace se v hlavních verzích vždy mění. Nezměněný konfigurační soubor může mít potenciálně zastaralé možnosti, které již nejsou podporovány novější verzí serveru, což obvykle způsobuje některé závažné problémy upgradovanému serveru.
Nástroje pro správu konfigurace
Puppet, Ansible, Chef a SaltStack DevOps nejčastěji používá pro správu konfigurace a automatizaci. Správa konfigurace umožňuje uživatelům dokumentovat prostředí, zlepšovat efektivitu, spravovatelnost a reprodukovatelnost a je nedílnou součástí nepřetržité integrace a nasazení. Většina nástrojů pro správu konfigurace poskytuje katalog modulů a úložišť, do kterých mohou přispívat ostatní, a zjednodušuje tak křivku učení pro uživatele z komunity, aby se přizpůsobili technologii.
Přestože nástroje pro správu konfigurace se většinou používají k automatizaci nasazení a instalace, můžeme také provádět kontroly a vynucování konfigurace centralizovaným přístupem push-out. Každý z těchto nástrojů má svůj vlastní způsob šablonování konfiguračního souboru. Pokud jde o Puppet, soubor šablony běžně s příponou „.erb“ a uvnitř něj můžeme definovat možnosti konfigurace spolu s předem formulovanými hodnotami.
Následující příklad ukazuje soubor šablony pro konfiguraci 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
Jak je uvedeno výše, konfigurační hodnota může být pevná hodnota nebo dynamicky vypočítaná. Proto se konečný výsledek může lišit podle hardwarové specifikace cílového hostitele s jinými předdefinovanými proměnnými. V definičním souboru Puppet můžeme naši konfigurační šablonu vložit takto:
# Apply our custom template
file { '/etc/mysql/conf.d/my-custom-config.cnf':
ensure => file,
content => template('mysql/my-custom-config.cnf.erb')
}Kromě šablonování můžeme konfigurační hodnoty také poslat přímo z definičního souboru. Níže je uveden příklad definice Puppet pro konfiguraci MariaDB 10.5 pomocí modulu 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',
},
}
}Výše uvedený příklad ukazuje, že jsme použili manage_config_file => true s override_options ke strukturování našich konfiguračních řádků, které později vytlačí Puppet. Jakákoli úprava souboru manifestu bude odrážet pouze obsah cílového konfiguračního souboru MySQL. Tento modul po vložení změn do konfiguračního souboru ani nenačte konfiguraci do runtime, ani nerestartuje službu MySQL. Je odpovědností SysAdmina restartovat službu, aby se změny aktivovaly.
Pro Puppet a Chef zkontrolujte výstup protokolu agenta, abyste zjistili, zda jsou možnosti konfigurace opraveny. Pro Ansible se jednoduše podívejte na výstup ladění, abyste zjistili, zda jsou blahopřání úspěšně aktualizovány. Použití nástrojů pro správu konfigurace vám může pomoci automatizovat kontroly konfigurace a prosadit centralizovaný přístup ke konfiguraci.
MySQL Shell
Před provedením jakéhokoli upgradu je důležitá kontrola zdravého rozumu. MySQL Shell má velmi skvělou funkci, která je určena ke spuštění řady testů k ověření, zda je vaše stávající instalace bezpečná pro upgrade na MySQL 8.0, nazývaná Upgrade Checker Utility. Při přípravě upgradu můžete ušetřit obrovské množství času. Velký upgrade, zejména na MySQL 8.0, zavádí a zavrhuje mnoho konfiguračních možností, a proto představuje velké riziko nekompatibility po upgradu.
Tento nástroj je speciálně navržen pro MySQL (včetně serveru Percona), zvláště když chcete provést velký upgrade z MySQL 5.7 na MySQL 8.0. Chcete-li vyvolat tento nástroj, připojte se k prostředí MySQL a jako uživatel root zadejte přihlašovací údaje, cílovou verzi a konfigurační soubor:
$ mysqlsh
mysql> util.checkForServerUpgrade('[email protected]:3306', {"password":"p4ssw0rd", "targetVersion":"8.0.11", "configPath":"/etc/my.cnf"})Ve spodní části přehledu se zobrazí klíčové shrnutí:
Errors: 7
Warnings: 36
Notices: 0
7 errors were found. Please correct these issues before upgrading to avoid compatibility issues.Zaměřte se nejprve na opravu všech chyb, protože to bude po upgradu způsobovat velké problémy, pokud neprovedete žádnou akci. Podívejte se zpět na vygenerovaný přehled a najděte všechny problémy se slovem „Chyba:“ v textu, například:
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
Jakmile jsou všechny chyby opraveny, pokuste se omezit varování, jakkoli je to možné. Varování většinou neovlivní spolehlivost serveru MySQL, ale mohou potenciálně snížit výkon nebo změnit chování, než tomu bylo dříve. Podívejte se například na následující varování:
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
Utilita Kontrola upgradu poskytuje kritický přehled toho, co lze očekávat, a odvrací nás od velkého překvapení po upgradu.
Poradci ClusterControl
ClusterControl má řadu interních miniprogramů zvaných Advisors, kde píšete malý program, který žije a běží ve struktuře objektů ClusterControl. Můžete si to představit jako naplánovanou funkci, která spustí skript vytvořený v Developer Studio a vytvoří výsledek obsahující stav, rady a odůvodnění. To umožňuje uživatelům snadno rozšířit funkčnost ClusterControl vytvořením vlastních poradců, kteří mohou běžet na vyžádání nebo podle plánu.
Následující snímek obrazovky ukazuje příklad InnoDB Advisors s názvem innodb_log_file_size check po aktivaci a naplánování v ClusterControl:
Výše uvedený výsledek lze nalézt v části ClusterControl -> Výkon -> Poradci. U každého poradce zobrazuje stav poradce, instanci databáze, zdůvodnění a radu. Nechybí ani informace o harmonogramu a čase posledního provedení. Poradce lze také spustit na vyžádání kliknutím na tlačítko "Compile and Run" pod Developer Studio.
Výše uvedené poradce obsahující následující kód napsaný pomocí jazyka ClusterControl Domain-Specific Language (DSL), který je velmi podobný JavaScriptu:
#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 poskytuje integrované vývojové prostředí (IDE) s názvem Developer Studio (dostupné pod Manage -> Developer Studio) pro psaní, kompilaci, ukládání, ladění a plánování poradce:
S Developer Studio a Advisors nemají uživatelé žádné omezení v rozšiřování funkcí monitorování a správy ClusterControl. Je to doslova dokonalý nástroj pro automatizaci kontroly konfigurace pro veškerý váš databázový software s otevřeným zdrojovým kódem, jako je MySQL, MariaDB, PostgreSQL a MongoDB, a také pro vyrovnávání zátěže, jako je HAProxy, ProxySQL, MaxScale a PgBouncer. Můžete dokonce napsat poradce, abyste mohli používat nástroj MySQL Shell Upgrade Checker, jak je uvedeno v předchozí kapitole.
Poslední myšlenky
Kontrola a ladění konfigurace jsou důležitými součástmi rutiny DBA a SysAdmin, aby bylo zajištěno, že kritické systémy, jako jsou databáze a reverzní proxy, jsou vždy relevantní a optimální, jak vaše pracovní zátěž roste.