Seguimiento de la actividad

Completado

Una parte importante del mantenimiento de las bases de datos es el ajuste del rendimiento. Los mismos archivos de registro que se usan para revisar las bases de datos locales siguen estando disponibles con Azure Database for MySQL/PostgreSQL.

Una vez que las bases de datos se migran a Azure, deberá seguir revisando los archivos de registro para asegurarse de que se mantiene el rendimiento de las bases de datos.

En esta unidad verá dónde se almacenan los archivos de registro de PostgreSQL y MySQL en Azure y el nivel de detalle que contienen.

Uso de registros de servidor para hacer el seguimiento de la actividad de bases de datos

Azure Database for MySQL/PostgreSQL también registra información de diagnóstico en los registros del servidor. Los registros de servidor son los archivos de registro de mensajes nativos para MySQL y PostgreSQL (no los archivos de registro de transacciones, que son inaccesibles en Azure Database for MySQL/PostgreSQL). Estos archivos contienen mensajes, el estado del servidor y otro tipo de información de error que se usa para depurar problemas con las bases de datos. Los registros del servidor se conservan durante hasta siete días (menos, si el tamaño total de los archivos de registro del servidor supera los 7 GB).

Azure Database for MySQL y Azure Database for PostgreSQL registran detalles distintos en los registros de servidor. En las secciones siguientes se describen los registros de servidor para cada servicio por separado.

Registros de servidor en Azure Database for MySQL

En Azure Database for MySQL, el registro de servidor proporciona la información que suele estar disponible en el registro de consultas lentas y el registro de auditoría en un servidor MySQL.

La información del registro de consultas lentas se usa para ayudar a identificar las consultas de ejecución lenta. De forma predeterminada, los registros de consultas lentas están deshabilitados. Para habilitarlos, establezca el parámetro slow_query_log del servidor en ON (Activado). Puede configurar el registro de consultas lentas para determinar lo que significa una consulta lenta con los parámetros de servidor siguientes:

• log_queries_not_using_indexes. Este parámetro es ON (Activado) u OFF (Desactivado). Establézcalo en ON (Activado) para registrar todas las consultas que es probable que realicen un recorrido de tabla completo en lugar de una búsqueda de índice.
• log_throttle_queries_not_using_indexes. Especifica el número máximo de consultas lentas que no usan índices que se pueden registrar por minuto.
• log_slow_admin_queries. Establezca este parámetro en ON (Activado) para incluir las consultas administrativas de ejecución lenta en el registro.
• long_query_time. El umbral (en segundos) para que una consulta se considere como de ejecución lenta.

Una vez que habilite el registro de consultas lentas y el registro de auditoría, los archivos de registro comenzarán a aparecer en la página Registros del servidor correspondiente al servidor. Cada día se crea un registro de consultas lentas nuevo. Haga clic en un archivo de registro para descargarlo:

Para habilitar el registro de auditoría, establezca el parámetro audit_log_enabled del servidor en ON (Activado). Puede configurar el registro de auditoría con estos parámetros:

• audit_log_events. Especifique los eventos que se van a auditar. En Azure Portal, este parámetro proporciona una lista desplegable de eventos, como CONNECTION, DDL, DML, ADMIN, entre otros.
• audit_log_exclude_users. Este parámetro es una lista separada por comas de usuarios cuyas actividades no se incluirán en el registro de auditoría.

Si necesita conservar el registro de consultas lentas y el registro de auditoría durante más de siete días, puede hacer que se transfieran a Azure Storage. Use la página Configuración de diagnóstico del servidor y, a continuación, seleccione + Agregar configuración de diagnóstico. En la página Configuración de diagnóstico, seleccione Archivar en una cuenta de almacenamiento, seleccione una cuenta de almacenamiento en la que guardar los archivos de registro (esta cuenta de almacenamiento ya debe existir), seleccione MySqlSlowLogs y MySqlAuditLogs y especifique un período de retención de hasta 365 días. Puede descargar los archivos de registro desde Azure Storage en cualquier momento durante este período. Seleccione Guardar:

Los datos de registro de consultas lentas se escribirán en formato JSON en blobs en un contenedor con el nombreinsights-logs-mysqlslowlogs. Los archivos de registro pueden tardar hasta 10 minutos en aparecer en Azure Storage. Los registros de auditoría se almacenan en el contenedor de blobs insights-logs-mysqlslowlogs, también en formato JSON.

Registros de servidor en Azure Database for PostgreSQL

En Azure Database for PostgreSQL, el registro del servidor contiene los archivos de registro de errores y de consulta. Utilice la información de estos archivos para localizar los orígenes de los errores y las consultas ineficaces.

Para habilitar el registro, establezca los distintos parámetros de configuración log_ del servidor en ON (Activado). Estos parámetros son:

• log_checkpoints. Se produce un punto de comprobación cada vez que se actualiza un archivo de datos con la información más reciente del registro de transacciones. Si se produce un error en el servidor, este punto marca la hora a la que se debe iniciar la recuperación al ponerse al día a partir del registro de transacciones.
• log_connection y log_disconnections. Esta configuración registra cada conexión correcta y el final de cada sesión.
• log_duration. Esta configuración hace que se registre la duración de cada instrucción SQL completada.
• log_lock_waits. Esta configuración hace que se registren los eventos de espera de bloqueo. Las esperas de bloqueo pueden deberse a transacciones mal implementadas en el código de la aplicación.
• log_statement_stats. Esta configuración escribe en el registro información acumulada sobre el rendimiento del servidor.

Azure Database for PostgreSQL también proporciona más parámetros para ajustar la información que se registra:

• log_error_verbosity. Esta configuración especifica el nivel de detalle registrado para cada mensaje del registro.
• log_retention_days. La cantidad de días durante los que el servidor conserva cada archivo de registro antes de quitarlo. El valor predeterminado es tres días y puede establecerlo en un máximo de siete.
• log_min_messages y log_min_error_statement. Utilice estos parámetros para especificar los niveles de advertencia y de error para las instrucciones de registro.

Al igual que ocurre con Azure Database for MySQL, los archivos de registro que genera Azure Database for PostgreSQL están disponibles en la página Registros del servidor. También puede usar la página Configuración de diagnóstico para copiar los registros a Azure Storage.

Seguimiento del rendimiento de las consultas

El Almacén de consultas es una característica adicional que proporciona Azure para ayudarlo a identificar las consultas que tienen un rendimiento deficiente y hacer un seguimiento de ellas. Úselo con Azure Database for MySQL y Azure Database for PostgreSQL.

Habilitación del seguimiento del rendimiento de las consultas

El Almacén de consultas registra información en el esquema mysql en Azure Database for MySQL y en una base de datos denominada azure_sys en Azure Database for PostgreSQL. El Almacén de consultas pueden capturar dos tipos de información: datos sobre la ejecución de las consultas e información sobre las estadísticas de espera. El Almacén de consultas está deshabilitada de manera predeterminada. Para habilitarla:

• Si usa Azure Database for MySQL, establezca los parámetros del servidor query_store_capture_mode y query_store_wait_sampling_capture_mode en ALL.
• Si usa Azure Database for PostgreSQL, establezca el parámetro del servidor pg_qs.query_capture_mode en ALL o en TOP y establezca el parámetro pgms_wait_sampling.query_capture_mode en ALL.

Análisis de los datos de rendimiento de las consultas

Puede consultar directamente las tablas que utiliza el Almacén de consultas. Si ejecuta Azure Database for MySQL, conéctese al servidor y ejecute las consultas siguientes:

SELECT * FROM mysql.query_store;

SELECT * FROM mysql.query_store_wait_stats;

En su lugar, si usa Azure Database for PostgreSQL, ejecute las consultas siguientes:

SELECT * FROM query_store.qs_view;

SELECT * FROM query_store.pgms_wait_sampling_view;

En ambos casos, la primera consulta mostrará el texto de cada consulta ejecutada recientemente y diversas estadísticas sobre cuánto tiempo tardó la consulta en compilarse y ejecutarse. La segunda consulta muestra información sobre los eventos de espera. Un evento de espera se produce cuando se impide la ejecución de una consulta porque requiere los recursos que retiene otra consulta.

Si examina directamente el Almacén de consultas, puede generar sus propios informes personalizados y obtener una visión detallada de cómo funciona el sistema. Sin embargo, la cantidad de datos disponibles puede dificultar la comprensión de lo que ocurre. Azure Database for MySQL/PostgreSQL proporciona dos herramientas adicionales que lo ayudarán a navegar por estos datos:Información de rendimiento de consultasy las Recomendaciones de consulta.

Información de rendimiento de consultas es una utilidad gráfica que está disponible en la página Información de rendimiento de consultas del servidor. La pestaña Consultas de larga duración muestra las estadísticas de las consultas que se ejecutan durante más tiempo. Debe especificar el período de tiempo y ver los detalles incluso de algunos minutos. La leyenda muestra el texto de cada consulta, junto con la duración y la cantidad de veces que se ejecutó. El gráfico brinda una vista comparativa de la duración de cada consulta. Los datos se muestran según el tiempo promedio de cada consulta, pero también se puede mostrar el tiempo total (duración * número de ejecuciones) de cada consulta. En la imagen siguiente se muestra un ejemplo:

La pestaña Estadísticas de espera muestra la información de eventos de espera para cada consulta. Verá durante cuánto tiempo una consulta espera diversos recursos.

Por lo general, los eventos de espera se dividen en tres categorías:

• Esperas de bloqueo. Estos eventos se producen si una consulta intenta leer o modificar datos bloqueados por otra consulta. Si experimenta una gran cantidad de esperas de bloqueo, compruebe las transacciones de larga duración o las operaciones que san un nivel de aislamiento muy restrictivo.
• Esperas de E/S. Este tipo de espera se produce si una consulta realiza una cantidad significativa de E/S. Esto puede deberse a una consulta mal diseñada (compruebe la cláusula WHERE), una operación de combinación ineficaz o un recorrido de tabla completo en el que se incurre debido a que falta un índice.
• Esperas de memoria. Se produce una espera de memoria si no hay memoria suficiente disponible para procesar una consulta. Es posible que la consulta intente leer una gran cantidad de datos o puede estar bloqueada porque otras consultas acaparan la memoria. Nuevamente, esto podría indicar que faltan índices, lo que hace que las consultas lean tablas enteras en la memoria.

También es muy probable que una forma de espera desencadene otra, por lo que no necesariamente puede examinar estos problemas de forma aislada. Por ejemplo, una transacción que lee y actualiza datos en tablas distintas puede estar sujeta a una espera de memoria. A su vez, esta transacción podría haber bloqueado datos, lo que hace que otra transacción incurra en una espera de bloqueo.

La página Recomendaciones de rendimiento del servidor toma la información contenida en el Almacén de consultas y la usa para hacer recomendaciones sobre cómo ajustar la base de datos para las cargas de trabajo que experimenta.