El monitoreo proactivo de su base de datos MySQL es imperativo hoy en día. Desempeña un papel crucial y significativo para administrar y controlar su base de datos, especialmente para sus clústeres de grado de producción. La falta de información específica que sería beneficiosa para mejorar su base de datos o la falta de identificación de la causa raíz de los problemas que pueden surgir puede producir una dificultad extrema para solucionar o recuperarse de sus días de gloria.
El monitoreo proactivo en su base de datos MySQL le permite a su equipo comprender cómo se están desempeñando los servicios de su base de datos. ¿Funciona y se entrega en función de la carga de trabajo que se espera que lleve? ¿Tiene suficientes recursos para que el servidor funcione según la carga de trabajo que está manejando actualmente? El monitoreo proactivo aplica cosas que evitarán desastres o dañarán su base de datos, lo que le notificará con anticipación. Por lo tanto, permite que los DBA o los administradores realicen tareas importantes para evitar fallas de funcionamiento, corrupción de datos, vulnerabilidades y ataques de seguridad, o rebotes inesperados de tráfico en su clúster de base de datos. Al ser atendidos de inmediato, el monitoreo proactivo para MySQL debe automatizarse y operar las 24 horas del día, los 7 días de la semana sin interrupción y depende de los DBA, Devops y administradores decidir si se basa en la prioridad de las tareas y cuán crucial es si requiere mantenimiento o solo un trabajo de rutina diaria típica.
Monitoreo proactivo con ClusterControl
ClusterControl ofrece un estilo diverso para monitorear sus servidores de bases de datos MySQL. Su enfoque es comparable con otras herramientas de monitoreo empresarial y con soluciones en la nube de nivel empresarial. ClusterControl tiende a aplicar todas las mejores prácticas para administrar y monitorear las bases de datos, pero con la flexibilidad de configurar para lograr la configuración deseada en función de su entorno.
Cuando se trata de alarmas y notificaciones, ClusterControl tiene un enfoque mixto para el cual hay alarmas integradas, y luego están los asesores de los que hablaremos más adelante en este blog.
Alarmas de ClusterControl para MySQL
Las alarmas indican problemas que podrían afectar o degradar el clúster en su totalidad. Esta interfaz proporciona una explicación detallada del problema, junto con la acción recomendada (si está disponible) para resolverlo. Cada alarma se clasifica como:
-
Clúster
-
Recuperación de clúster
-
Estado de la base de datos
-
Rendimiento de la base de datos
-
Anfitrión
-
Nodo
-
Red
Se puede reconocer una alarma marcando la casilla ¿Ignorar? caja. Cuando se ignora, no se enviará ninguna notificación por correo electrónico. Una alarma no se puede eliminar ni descartar, aunque puede ocultarla de la lista haciendo clic en el botón Ocultar alarmas ignoradas.
Vea la captura de pantalla de ejemplo a continuación,
Proactividad con ClusterControl
ClusterControl admite la recuperación automática que reacciona cada vez que se detecta una falla. La recuperación automática con ClusterControl es una de las funcionalidades más proactivas que juega un papel crucial en caso de desastres.
Se requiere habilitar la recuperación automática para este monitoreo proactivo que reacciona en varias situaciones, por ejemplo, si falla el nodo MySQL principal.
En ClusterControl, esto se detectará de inmediato mientras escucha la conexión con el servidor de base de datos, o en este caso el servidor primario. ClusterControl reaccionará lo antes posible y aplicará una conmutación por error.
La conmutación por error es parte de la recuperación del clúster habilitada. Dado que ambos botones Clúster y Nodo están habilitados, sigue la recuperación del nodo como se ve a continuación.
Dependiendo de la accesibilidad de los nodos, ClusterControl intentará continuamente por conectándose a través de SSH e intente llegar al nodo e intente recuperarse comenzando a usar sysvinit o systemd. Obviamente, podría pensar que aplica una conmutación por error y ClusterControl intenta iniciar el primario fallido. Eso podría significar que hay dos nodos de base de datos disponibles, ¿verdad? Aunque es cierto, ClusterControl llevará el servidor principal fallido a un estado de solo lectura mientras se recupera. Véase más abajo,
Aunque hay ciertas opciones que puede configurar para administrar el mecanismo de conmutación por error, debe consultar nuestra documentación para esto, ya que no es el enfoque de este blog.
Uso de asesores para la proactividad con ClusterControl
En ClusterControl, los asesores se ubicarán yendo a
Mientras está en un clúster de Galera, agrega los asesores específicos de Galera como se muestra a continuación ,
Personalizar sus asesores MySQL de ClusterControl
Los asesores son personalizables y se pueden modificar según sus necesidades. En la captura de pantalla anterior de los asesores, simplemente haga clic en Editar y será redirigido al IDE simple que hemos integrado en ClusterControl.
También puede crear sus propios asesores de ClusterControl. Puedes referirte a ti mismo para obtener más información sobre la creación leyendo Write Your First Advisor o tomar la serie de 2 partes para crear la tuya propia usando el script de detección Meltdown/Spectre.
¿Cómo son proactivos los asesores de ClusterControl?
Técnicamente, los asesores de ClusterControl actúan principalmente como notificadores y, literalmente, sus asesores. ClusterControl Advisors le notificará si detecta un comportamiento inusual si supera los umbrales básicos establecidos de forma predeterminada por ClusterControl. Normalmente, los umbrales aplicados son valores genéricos. Estos valores genéricos se basan en las mejores prácticas y en la carga de trabajo o la configuración del entorno más comunes y aceptables. La mayoría de los asesores predeterminados no proporcionan alarmas ni mecanismos de alerta en la interfaz de usuario de ClusterControl. Le notifica a través de la interfaz de usuario (consulte la captura de pantalla de muestra del asesor de ubicación de almacenamiento de Binlog a continuación).
Como se mencionó anteriormente, los asesores se pueden modificar y editar a través de nuestro editor simple o IDE. Por ejemplo, en un clúster de replicación de MySQL, ClusterControl proporciona un asesor de ubicación de almacenamiento de Binlog. Detecta que los binlogs están almacenados en el directorio de datos donde advierte que debe estar fuera del directorio de datos.
Tomemos un ejemplo de la lista de asesores y seleccione Conexiones actualmente en uso . Editemos esto como se muestra a continuación,
o alternativamente, puede ir a
Al hacerlo más proactivo mediante el envío de alarmas, puede modificarlo y agregar las siguientes funciones como a continuación,
function myAlarm(title, message, recommendation)
{
return Alarm::alarmId(
Node,
true,
title,
message,
recommendation
);
}Mientras que, al establecer el umbral en 20, luego agregue estas líneas a continuación justo dentro de la declaración de condición if donde el umbral se alcanza por encima de su valor de umbral dado.
myAlarmId = myAlarm(TITLE, msg, ADVICE_WARNING);
// Let's raise an alarm.
host.raiseAlarm(myAlarmId, Warning);
Here's the complete script with my modifications in bold,
#include "common/mysql_helper.js"
var DESCRIPTION="This advisor calculates the percentage of threads_connected over max_connections,"
" if the percentage is higher than 20% you will be notified,"
" preventing your database server from becoming unstable.";
var WARNING_THRESHOLD=20;
var TITLE="Connections currently used";
var ADVICE_WARNING="You are using more than " + WARNING_THRESHOLD +
"% of the max_connections."
" Consider regulating load, e.g by using HAProxy. Using up all connections"
" may render the database server unusable.";
var ADVICE_OK="The percentage of currently used connections is satisfactory." ;
function myAlarm(title, message, recommendation)
{
return Alarm::alarmId(
Node,
true,
title,
message,
recommendation
);
}
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;
}
var Threads_connected = host.sqlStatusVariable("Threads_connected");
var Max_connections = host.sqlSystemVariable("Max_connections");
if (Threads_connected.isError() || Max_connections.isError())
{
justification = "";
msg = "Not enough data to calculate";
}
else
{
var used = round(100 * Threads_connected / Max_connections,1);
if (used > WARNING_THRESHOLD)
{
advice.setSeverity(1);
msg = ADVICE_WARNING;
justification = used + "% of the connections is currently used,"
" which is > " + WARNING_THRESHOLD + "% of max_connections.";
myAlarmId = myAlarm(TITLE, msg, ADVICE_WARNING);
// Let's raise an alarm.
host.raiseAlarm(myAlarmId, Warning);
}
else
{
justification = used + "% of the connections is currently used,"
" which is < 90% of max_connections.";
advice.setSeverity(0);
msg = ADVICE_OK;
}
}
advice.setHost(host);
advice.setTitle(TITLE);
advice.setJustification(justification);
advice.setAdvice(msg);
advisorMap[idx]= advice;
print(advice.toString("%E"));
}
return advisorMap;
}Puede usar sysbench para probarlo. En mi prueba, se me notifica de forma proactiva mediante el envío de la alarma. Esto también se me enviará por correo electrónico o se me puede notificar si ha integrado notificaciones de terceros. Vea la captura de pantalla a continuación,
Advertencias de los asesores de ClusterControl
La modificación o edición de un asesor existente en ClusterControl se aplica a todos los clústeres. Eso significa que debe verificar en su secuencia de comandos si tiene una condición específica aplicable solo para su clúster existente (ya sea MySQL u otras bases de datos compatibles con ClusterControl). Esto se debe a que los asesores de ClusterControl se almacenan en una sola fuente solo a través de nuestra base de datos cmon. Estos son extraídos o recuperados por todos los clústeres que ha creado en ClusterControl.
Por ejemplo, puede hacer esto en un script:
var hosts =clúster::mySqlNodes();
var asesorMap ={};
imprimir(hosts[1].clusterId());
Este script imprimirá la ID del clúster. Una vez que obtenga el valor, asígnelo a una variable y use esa variable para evaluar si es cierto que este ID de clúster específico es aceptable o no según la tarea que desea que realice su asesor. Digamos,
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 (host.clusterId() == 15)
{
print("Not applicable for cluster id == 15");
continue;
}
…
….
…..lo que significa que si es cluster_id ==15, simplemente omita o continúe con el siguiente bucle.
Conclusión
Crear o modificar los asesores de ClusterControl es una buena oportunidad para aprovechar la funcionalidad oculta que le puede proporcionar ClusterControl. Puede parecer que está oculto, pero está ahí; es solo que la función se usa menos. Proporciona una característica simple pero poderosa llamada lenguaje específico de dominio de ClusterControl (CDSL) que se puede usar para tareas extremadamente difíciles de las que carece ClusterControl. Solo asegúrese de conocer todas las advertencias y también pruebe todo primero antes de finalmente aplicarlo a su entorno de producción.
