Muchos administradores de sistemas suelen pasar por alto la importancia del ajuste constante de la configuración de la base de datos. Las opciones de configuración a menudo se configuran o ajustan una vez, durante la etapa de instalación, y se omiten hasta que ocurren algunos eventos no deseados en el servicio de la base de datos. Solo entonces, uno pondría más atención en volver a visitar las opciones de configuración y ajustar los límites, umbrales, búferes, cachés, etc., en la urgencia de restaurar el servicio de la base de datos nuevamente.
Nuestro enfoque en esta publicación de blog es automatizar el proceso de verificación y validación de la configuración de la base de datos. Este es un proceso importante porque las opciones de configuración siempre cambian en las versiones principales. Un archivo de configuración sin cambios podría tener opciones obsoletas que ya no son compatibles con la versión más nueva del servidor, lo que suele causar algunos problemas importantes en el servidor actualizado.
Herramientas de administración de configuración
Puppet, Ansible, Chef y SaltStack son los más utilizados por DevOps para la gestión y automatización de la configuración. La gestión de la configuración permite a los usuarios documentar el entorno, mejorar la eficiencia, la capacidad de gestión y la reproducibilidad, y es una parte integral de la integración y el despliegue continuos. La mayoría de las herramientas de administración de configuración brindan un catálogo de módulos y repositorios para que otros contribuyan, lo que simplifica la curva de aprendizaje para que el usuario de la comunidad se adapte a la tecnología.
Aunque las herramientas de gestión de la configuración se utilizan principalmente para automatizar la implementación y la instalación, también podemos realizar controles de configuración y cumplimiento en un enfoque centralizado de extracción. Cada una de estas herramientas tiene su propia forma de crear plantillas para un archivo de configuración. En cuanto a Puppet, el archivo de plantilla comúnmente tiene el sufijo ".erb" y dentro de él, podemos definir las opciones de configuración junto con valores preformulados.
El siguiente ejemplo muestra un archivo de plantilla para la configuración de 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
Como se muestra arriba, el valor de configuración puede ser un valor fijo o calculado dinámicamente. Por lo tanto, el resultado final puede ser diferente según la especificación de hardware del host de destino con otras variables predefinidas. En el archivo de definición de Puppet, podemos enviar nuestra plantilla de configuración de esta manera:
# Apply our custom template
file { '/etc/mysql/conf.d/my-custom-config.cnf':
ensure => file,
content => template('mysql/my-custom-config.cnf.erb')
}Además de las plantillas, también podemos enviar los valores de configuración directamente desde el archivo de definición. El siguiente es un ejemplo de definición de Puppet para la configuración de MariaDB 10.5 utilizando el módulo MySQL de Puppet:
# 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',
},
}
}El ejemplo anterior muestra que usamos manage_config_file => true con override_options para estructurar nuestras líneas de configuración que luego serán enviadas por Puppet. Cualquier modificación del archivo de manifiesto solo reflejará el contenido del archivo de configuración de MySQL de destino. Este módulo no cargará la configuración en el tiempo de ejecución ni reiniciará el servicio MySQL después de introducir los cambios en el archivo de configuración. Es responsabilidad del SysAdmin reiniciar el servicio para activar los cambios.
Para Puppet y Chef, verifique la salida del registro del agente para ver si las opciones de configuración están correctas. Para Ansible, simplemente mire el resultado de la depuración para ver si las felicitaciones se actualizaron correctamente. El uso de herramientas de administración de configuración puede ayudarlo a automatizar las comprobaciones de configuración y aplicar un enfoque de configuración centralizado.
Shell MySQL
Es importante realizar una verificación de estado antes de realizar cualquier actualización. MySQL Shell tiene una función muy interesante que está diseñada para ejecutar una serie de pruebas para verificar si su instalación existente es segura para actualizar a MySQL 8.0, llamada Upgrade Checker Utility. Puede ahorrar una gran cantidad de tiempo al prepararse para una actualización. Una actualización importante, especialmente a MySQL 8.0, introduce y elimina muchas opciones de configuración y, por lo tanto, tiene un gran riesgo de incompatibilidad después de la actualización.
Esta herramienta está diseñada específicamente para MySQL (servidor Percona incluido), especialmente cuando desea realizar una actualización importante de MySQL 5.7 a MySQL 8.0. Para invocar esta utilidad, conéctese con MySQL Shell y, como usuario raíz, especifique las credenciales, la versión de destino y el archivo de configuración:
$ mysqlsh
mysql> util.checkForServerUpgrade('[email protected]:3306', {"password":"p4ssw0rd", "targetVersion":"8.0.11", "configPath":"/etc/my.cnf"})En la parte inferior del informe, obtendrá el resumen clave:
Errors: 7
Warnings: 36
Notices: 0
7 errors were found. Please correct these issues before upgrading to avoid compatibility issues.Concéntrese en corregir todos los errores primero, porque esto causará problemas importantes después de la actualización si no se toman medidas. Vuelva a mirar el informe generado y encuentre todos los problemas con la redacción "Error:" en línea, por ejemplo:
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
Una vez solucionados todos los errores, intente reducir las advertencias tanto como sea posible. Las advertencias en su mayoría no afectarán la confiabilidad del servidor MySQL, pero pueden degradar potencialmente el rendimiento o cambiar el comportamiento de lo que solían. Por ejemplo, eche un vistazo a las siguientes advertencias:
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
Upgrade Checker Utility proporciona una descripción general crítica de lo que se puede esperar y nos evita una gran sorpresa después de la actualización.
Asesores de control de clúster
ClusterControl tiene varios miniprogramas internos llamados Asesores, en los que se escribe un pequeño programa que vive y se ejecuta dentro de la estructura de los objetos de ClusterControl. Puede considerarlo como una función programada que ejecuta un script creado en Developer Studio y produce un resultado que contiene estado, asesoramiento y justificación. Esto permite a los usuarios ampliar fácilmente la funcionalidad de ClusterControl mediante la creación de asesores personalizados que pueden ejecutarse bajo demanda o según un cronograma.
La siguiente captura de pantalla muestra un ejemplo de InnoDB Advisors llamado innodb_log_file_size check, después de activarse y programarse dentro de ClusterControl:
El resultado anterior se puede encontrar en ClusterControl -> Rendimiento -> Asesores. Para cada Asesor, muestra el estado del asesor, la instancia de la base de datos, la justificación y el consejo. También hay información sobre el cronograma y la última hora de ejecución. El asesor también se puede ejecutar a pedido haciendo clic en el botón "Compilar y ejecutar" en Developer Studio.
Los asesores anteriores contienen el siguiente código, escrito con el lenguaje específico de dominio (DSL) de ClusterControl, que es bastante similar a 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 proporciona un entorno de desarrollo integrado (IDE) listo para usar llamado Developer Studio (accesible en Administrar -> Developer Studio) para escribir, compilar, guardar, depurar y programar el Asesor:
Con Developer Studio y Advisors, los usuarios no tienen límite para ampliar las funcionalidades de supervisión y gestión de ClusterControl. Es, literalmente, la herramienta perfecta para automatizar la comprobación de la configuración de todo su software de base de datos de código abierto como MySQL, MariaDB, PostgreSQL y MongoDB, así como los balanceadores de carga como HAProxy, ProxySQL, MaxScale y PgBouncer. Incluso puede escribir un asesor para hacer uso de la utilidad MySQL Shell Upgrade Checker, como se muestra en el capítulo anterior.
Reflexiones finales
La verificación y el ajuste de la configuración son partes importantes de la rutina DBA y SysAdmin para garantizar que los sistemas críticos, como la base de datos y los proxies inversos, sean siempre relevantes y óptimos a medida que crecen sus cargas de trabajo.
