Muitos administradores de sistema geralmente ignoram a importância do ajuste contínuo da configuração do banco de dados. As opções de configuração geralmente são configuradas ou ajustadas uma vez, durante o estágio de instalação, e deixadas de fora até que alguns eventos indesejados ocorram no serviço de banco de dados. Só então, deve-se dar mais atenção para revisitar as opções de configuração e ajustar os limites, limites, buffers, caches, etc, no desejo de restaurar o serviço de banco de dados novamente.
Nosso foco nesta postagem do blog é automatizar o processo de verificação e validação da configuração do banco de dados. Este é um processo importante porque as opções de configuração estão sempre mudando nas versões principais. Um arquivo de configuração inalterado pode ter opções obsoletas que não são mais suportadas pela versão mais recente do servidor, o que geralmente causa alguns problemas importantes no servidor atualizado.
Ferramentas de gerenciamento de configuração
Puppet, Ansible, Chef e SaltStack são mais comumente usados pelo DevOps para gerenciamento de configuração e automação. O gerenciamento de configuração permite que os usuários documentem o ambiente, melhorem a eficiência, a capacidade de gerenciamento e a reprodutibilidade e sejam parte integrante da integração e implantação contínuas. A maioria das ferramentas de gerenciamento de configuração fornece um catálogo de módulos e repositórios para que outros possam contribuir, simplificando a curva de aprendizado para o usuário da comunidade se adaptar à tecnologia.
Embora as ferramentas de gerenciamento de configuração sejam usadas principalmente para automatizar a implantação e a instalação, também podemos realizar verificações e aplicação de configuração em uma abordagem push-out centralizada. Cada uma dessas ferramentas tem sua própria maneira de modelar um arquivo de configuração. Quanto ao Puppet, o arquivo de template geralmente tem o sufixo ".erb" e dentro dele podemos definir as opções de configuração junto com os valores pré-formulados.
O exemplo a seguir mostra um arquivo de modelo para configuração do 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 -%>MComo mostrado acima, o valor de configuração pode ser um valor fixo ou calculado dinamicamente. Portanto, o resultado final pode ser diferente de acordo com a especificação de hardware do host de destino com outras variáveis predefinidas. No arquivo de definição do Puppet, podemos enviar nosso modelo de configuração assim:
# Apply our custom template
file { '/etc/mysql/conf.d/my-custom-config.cnf':
ensure => file,
content => template('mysql/my-custom-config.cnf.erb')
}Além da modelagem, também podemos enviar os valores de configuração diretamente do arquivo de definição. Veja a seguir um exemplo de definição do Puppet para configuração do MariaDB 10.5 usando o módulo 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',
},
}
}O exemplo acima mostra que usamos manage_config_file => true com override_options para estruturar nossas linhas de configuração que mais tarde serão enviadas pelo Puppet. Qualquer modificação no arquivo de manifesto refletirá apenas o conteúdo do arquivo de configuração MySQL de destino. Este módulo não carregará a configuração em tempo de execução nem reiniciará o serviço MySQL após enviar as alterações para o arquivo de configuração. É responsabilidade do SysAdmin reiniciar o serviço para ativar as alterações.
Para Puppet e Chef, verifique a saída do log do agente para ver se as opções de configuração estão corrigidas. Para o Ansible, basta observar a saída de depuração para ver se os parabéns foram atualizados com êxito. O uso de ferramentas de gerenciamento de configuração pode ajudá-lo a automatizar verificações de configuração e aplicar uma abordagem de configuração centralizada.
Shell MySQL
Uma verificação de integridade é importante antes de realizar qualquer atualização. O MySQL Shell tem um recurso muito legal que se destina a executar uma série de testes para verificar se sua instalação existente é segura para atualizar para o MySQL 8.0, chamada Upgrade Checker Utility. Você pode economizar muito tempo ao se preparar para uma atualização. Uma grande atualização, especialmente para o MySQL 8.0, introduz e descontinua muitas opções de configuração e, portanto, tem um grande risco de incompatibilidade após a atualização.
Esta ferramenta foi projetada especificamente para MySQL (Percona Server incluído), especialmente quando você deseja realizar uma grande atualização do MySQL 5.7 para o MySQL 8.0. Para invocar este utilitário, conecte-se ao MySQL Shell e, como usuário root, especifique as credenciais, a versão de destino e o arquivo de configuração:
$ mysqlsh
mysql> util.checkForServerUpgrade('[email protected]:3306', {"password":"p4ssw0rd", "targetVersion":"8.0.11", "configPath":"/etc/my.cnf"})Na parte inferior do relatório, você obterá o resumo principal:
Errors: 7
Warnings: 36
Notices: 0
7 errors were found. Please correct these issues before upgrading to avoid compatibility issues.Concentre-se em corrigir todos os erros primeiro, porque isso causará grandes problemas após a atualização se nenhuma ação for tomada. Dê uma olhada no relatório gerado e encontre todos os problemas com o texto "Erro:" embutido, por exemplo:
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 removedAssim que todos os erros forem corrigidos, tente reduzir os avisos tanto quanto possível. Os avisos principalmente não afetarão a confiabilidade do servidor MySQL, mas podem potencialmente degradar o desempenho ou alterar o comportamento do que costumavam. Por exemplo, dê uma olhada nos seguintes avisos:
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
XXHASH64Upgrade Checker Utility fornece uma visão geral crítica do que esperar e evita uma grande surpresa após a atualização.
Consultores de Controle de Cluster
ClusterControl tem vários miniprogramas internos chamados Advisors, onde você escreve um pequeno programa que vive e é executado dentro da estrutura dos objetos ClusterControl. Você pode pensar nisso como uma função agendada que executa um script criado no Developer Studio e produz um resultado contendo status, aviso e justificativa. Isso permite que os usuários estendam facilmente a funcionalidade do ClusterControl criando orientadores personalizados que podem ser executados sob demanda ou em um agendamento.
A captura de tela a seguir mostra um exemplo de InnoDB Advisors chamado innodb_log_file_size check, após ser ativado e agendado dentro do ClusterControl:
O resultado acima pode ser encontrado em ClusterControl -> Performance -> Advisors. Para cada Advisor, ele mostra o status do advisor, instância do banco de dados, justificativa e aconselhamento. Há também informações sobre o cronograma e o último horário de execução. O orientador também pode ser executado sob demanda clicando no botão "Compile and Run" no Developer Studio.
Os orientadores acima contêm o código a seguir, escrito usando o ClusterControl Domain-Specific Language (DSL), que é bastante semelhante ao 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 fornece um ambiente de desenvolvimento integrado (IDE) pronto para uso chamado Developer Studio (acessível em Gerenciar -> Developer Studio) para escrever, compilar, salvar, depurar e agendar o Advisor:
Com o Developer Studio e Advisors, os usuários não têm limites para estender as funcionalidades de monitoramento e gerenciamento do ClusterControl. É literalmente a ferramenta perfeita para automatizar a verificação de configuração de todos os seus softwares de banco de dados de código aberto como MySQL, MariaDB, PostgreSQL e MongoDB, bem como os balanceadores de carga como HAProxy, ProxySQL, MaxScale e PgBouncer. Você pode até escrever um Advisor para fazer uso do MySQL Shell Upgrade Checker Utility, como mostrado no capítulo anterior.
Considerações finais
Verificação e ajuste de configuração são partes importantes da rotina de DBA e SysAdmin para garantir que sistemas críticos como banco de dados e proxies reversos sejam sempre relevantes e ideais à medida que suas cargas de trabalho crescem.
