ApsaraDB RDS:Use the SQL Explorer and Audit feature

logout! marca un evento de desconexión. La duración de ejecución que se muestra corresponde al tiempo de inactividad entre la última interacción y la desconexión. El código de estado 1158 significa desconexión de red, lo cual puede ocurrir por las siguientes razones:

• Se agotó el tiempo de espera de la conexión del cliente.

• El servidor cerró la conexión.

• La conexión superó el valor de interactive_timeout o de wait_timeout.

Aparece un % en la columna Access Source cuando interviene un procedimiento almacenado. Esto ocurre porque el procedimiento almacenado se define con un DEFINER que incluye % como host; por ejemplo, ` CREATE DEFINER= test_user @% PROCEDURE das () `.

Para reproducir este comportamiento:

1. En la consola de ApsaraDB RDS, cree una base de datos y una cuenta estándar, y otorgue permisos sobre la base de datos a dicha cuenta. Para más detalles, consulte Create accounts and databases.

2. Conéctese a la instancia mediante la CLI con la cuenta test_user. Para más detalles, consulte Use a database client or the CLI to connect to an ApsaraDB RDS for MySQL instance.

3. Cambie a la base de datos testdb y cree un procedimiento almacenado:

   -- Switch to testdb
   USE testdb;
   
   -- Create a stored procedure
   DELIMITER $$
   DROP PROCEDURE IF EXISTS `das` $$
   CREATE DEFINER=`test_user`@`%` PROCEDURE `das`()
   BEGIN
   SELECT * FROM information_schema.processlist WHERE Id = CONNECTION_ID();
   END $$
   DELIMITER;

4. Conéctese a la instancia con una cuenta con privilegios. Para más detalles, consulte Use a database client or the CLI to connect to an ApsaraDB RDS for MySQL instance.

5. Llame al procedimiento almacenado:

   -- Switch to testdb
   USE testdb;
   
   -- Call the stored procedure
   CALL das();

   Resultado esperado:

   +--------+-----------+--------+--------+---------+------+-----------+-------------------------------------------------------------------------+
   | ID     | USER      | HOST   | DB     | COMMAND | TIME | STATE     | INFO                                                                    |
   +--------+-----------+--------+--------+---------+------+-----------+-------------------------------------------------------------------------+
   | 487818 | test_user | %:2065 | testdb | Query   |    0 | executing | SELECT * FROM information_schema.processlist WHERE Id = CONNECTION_ID() |
   +--------+-----------+--------+--------+---------+------+-----------+-------------------------------------------------------------------------+

La función de caché de consultas rápidas está habilitada. Cuando la misma consulta coincide con la caché, MySQL devuelve directamente el resultado almacenado sin analizar InnoDB, por lo que el recuento de filas analizadas es cero. Para más detalles, consulte Fast query cache.

Ambos tipos de registro capturan cambios incrementales en la instancia de RDS, pero difieren en su cobertura y casos de uso:

	SQL Explorer logs	Binary logs
Cobertura	Todas las operaciones DQL, DML y DDL.	Solo operaciones de inserción, eliminación y modificación.
Integridad	Puede perderse una pequeña cantidad de registros bajo cargas elevadas.	Preciso dentro del periodo de retención de copias de seguridad.
Disponibilidad	En tiempo real.	No se genera en tiempo real; se transfiere periódicamente a Object Storage Service (OSS) y se retiene durante 7 días.
Incluye IP de origen y cuenta	Sí	No
Más indicado para	Auditorías de cumplimiento, solución de problemas y análisis completo de actividad.	Recuperación de datos mediante información incremental precisa.

Los archivos de registro binario que se están escribiendo actualmente no se pueden transferir a OSS. Como consecuencia, algunos archivos podrían fallar al cargarlos con la función Upload Binlogs. Para más detalles, consulte Obtain and parse binary logs for an RDS for MySQL instance

SQL Explorer and Audit es la versión actualizada de SQL Explorer. Ahora el punto de entrada se denomina SQL Explorer and Audit.

No. En las instancias de RDS solo se puede habilitar latest version of SQL Explorer and Audit.

No. Exportar los registros de auditoría no los elimina del sistema.

No. La configuración de alertas y auditoría de SQL Explorer and Audit se aplica a nivel de instancia y no se puede diferenciar por cuentas de base de datos individuales. Por ejemplo, no es posible configurar "el usuario A no recibe alertas" ni "auditar solo las operaciones del usuario B". Para gestionar las notificaciones de alerta por usuario, fíltrelas en la capa de su aplicación o mediante las políticas de notificación de Cloud Monitor.

Si los datos de una tabla se eliminan de forma accidental o malintencionada, puede usar SQL Explorer and Audit para identificar la cuenta y la dirección IP que ejecutaron la eliminación:

1. Inicie sesión en la consola de ApsaraDB RDS. Busque la instancia y haga clic en su ID.

2. En el panel de navegación izquierdo, elija Autonomy Services > SQL Explorer and Audit.

3. En la pestaña Audit, dentro de la sección Logs, establezca el intervalo de tiempo para cubrir el periodo en el que ocurrió la eliminación y, de manera opcional, filtre por nombre de base de datos.

4. Introduzca DELETE en el cuadro de búsqueda de palabras clave SQL y haga clic en el icono de búsqueda.

5. En los resultados, busque el registro de la operación DELETE y haga clic en él para ver los detalles, incluidos el nombre de la cuenta y la dirección IP del cliente.

Los campos del registro de errores, como el nombre de la base de datos y la dirección IP del cliente, se pueden usar como condiciones de filtro en SQL Explorer and Audit para localizar conexiones anómalas. Procedimiento:

1. Inicie sesión en la consola de ApsaraDB RDS y vaya a la página de detalles de la instancia. En el panel de navegación izquierdo, elija Autonomy Services > SQL Explorer and Audit.

2. En la pestaña Audit, haga clic en Enable Advanced Query para expandir las condiciones de filtro avanzadas.

3. En el campo Database, introduzca el nombre de la base de datos; por ejemplo, battery.

4. En el campo Client IP, introduzca el host del registro de errores; por ejemplo, 172.25.244.207.

5. Establezca Time Range para cubrir el periodo en el que ocurrió la conexión anómala.

6. Haga clic en Query para ejecutar la consulta con los filtros combinados.

Puede filtrar los resultados de Search (audit) por tipo de operación. En la página SQL Explorer and Audit, abra la pestaña Search y establezca el filtro Operation type en LOGIN para consultar el historial de inicios de sesión de la instancia. La lista de resultados incluye las columnas User (cuenta de inicio de sesión) y Client IP, que le ayudan a identificar quién inició sesión y desde dónde.

SQL Explorer and Audit registra las operaciones a nivel de instrucción SQL y no ofrece comparación de valores antes y después a nivel de campo. Para ver el valor de un campo específico, como status, antes y después de un cambio, utilice la función de seguimiento de datos de Data Management (DMS) para localizar el origen de la modificación.