ApsaraDB RDS:Use the SQL Explorer and Audit feature

logout! marca um evento de desconexão. A duração de execução mostrada é o tempo ocioso entre a última interação e a desconexão. O código de status 1158 significa desconexão de rede, o que pode acontecer porque:

• A conexão do cliente expirou

• O servidor desconectou

• A conexão excedeu o valor de interactive_timeout ou wait_timeout

Um % na coluna Access Source aparece quando uma stored procedure está envolvida. Isso acontece porque a stored procedure é definida com um DEFINER que inclui % como host — por exemplo, ` CREATE DEFINER= test_user @% PROCEDURE das () `.

Para reproduzir esse comportamento:

1. No console do ApsaraDB RDS, crie um banco de dados e uma conta padrão e conceda permissões no banco de dados para essa conta. Para mais detalhes, consulte Criar contas e bancos de dados.

2. Conecte-se à instância usando a conta test_user via CLI. Para mais detalhes, consulte Usar um cliente de banco de dados ou a CLI para conectar-se a uma instância ApsaraDB RDS for MySQL.

3. Mude para o banco de dados testdb e crie uma stored procedure:

   -- 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. Conecte-se à instância usando uma conta privilegiada. Para mais detalhes, consulte Usar um cliente de banco de dados ou a CLI para conectar-se a uma instância ApsaraDB RDS for MySQL.

5. Chame a stored procedure:

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

   Saída esperada:

   +--------+-----------+--------+--------+---------+------+-----------+-------------------------------------------------------------------------+
   | 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() |
   +--------+-----------+--------+--------+---------+------+-----------+-------------------------------------------------------------------------+

O recurso de cache de consulta rápida está ativado. Quando a mesma consulta atinge o cache, o MySQL retorna o resultado armazenado em cache diretamente sem verificar o InnoDB — portanto, a contagem de linhas verificadas é zero. Para mais detalhes, consulte Cache de consulta rápida.

Ambos os tipos de log capturam alterações incrementais na sua instância RDS, mas diferem na cobertura e nos casos de uso:

	Logs do SQL Explorer	Logs binários
Cobertura	Todas as operações DQL, DML e DDL	Apenas operações de adição, exclusão e modificação
Completude	Um pequeno número de registros pode ser perdido sob carga elevada	Preciso dentro do período de retenção de backup
Disponibilidade	Tempo real	Não gerado em tempo real; transferido periodicamente para o Object Storage Service (OSS), retido por 7 dias
Inclui IP de origem e conta	Sim	Não
Mais adequado para	Auditoria de conformidade, solução de problemas, análise completa de atividades	Recuperação de dados usando dados incrementais precisos

Os arquivos de log binário que estão sendo gravados atualmente não podem ser transferidos para o OSS. Como resultado, alguns arquivos podem falhar ao fazer upload ao usar o recurso Upload Binlogs. Para mais detalhes, consulte Obter e analisar logs binários para uma instância RDS for MySQL

O SQL Explorer and Audit é uma versão atualizada do SQL Explorer. O ponto de entrada agora está rotulado como SQL Explorer and Audit.

Não. Apenas a versão mais recente do SQL Explorer and Audit pode ser ativada nas instâncias RDS.

Não. A exportação de registros de auditoria não os exclui do sistema.

Não. As configurações de alerta e auditoria do SQL Explorer and Audit se aplicam no nível da instância e não podem ser diferenciadas para contas de banco de dados individuais. Por exemplo, você não pode configurar "o usuário A não recebe alertas" ou "auditar apenas as operações do usuário B". Para gerenciar notificações de alerta por usuário, filtre-as na camada da sua aplicação ou usando as políticas de notificação do Cloud Monitor.

Se os dados da tabela forem excluídos acidentalmente ou intencionalmente, você pode usar o SQL Explorer and Audit para identificar a conta e o endereço IP que realizaram a exclusão:

1. Faça logon no console do ApsaraDB RDS. Encontre a instância e clique no ID dela.

2. No painel de navegação à esquerda, escolha Autonomy Services > SQL Explorer and Audit.

3. Na guia Audit, na seção Logs, defina o intervalo de tempo para cobrir o período em que a exclusão ocorreu e, opcionalmente, filtre por nome do banco de dados.

4. Insira DELETE na caixa de pesquisa de palavras-chave SQL e clique no ícone de pesquisa.

5. Nos resultados, encontre o registro da operação DELETE e clique nele para visualizar os detalhes, incluindo o nome da conta e o endereço IP do cliente.

Os campos dos logs de erros, como o nome do banco de dados e o endereço IP do cliente, podem ser usados como condições de filtro no SQL Explorer and Audit para localizar conexões anômalas. Procedimento:

1. Faça logon no console do ApsaraDB RDS e acesse a página de detalhes da instância. No painel de navegação à esquerda, escolha Autonomy Services > SQL Explorer and Audit.

2. Na guia Audit, clique em Enable Advanced Query para expandir as condições de filtro avançadas.

3. No campo Database, insira o nome do banco de dados, por exemplo, battery.

4. No campo Client IP, insira o host do log de erros, por exemplo, 172.25.244.207.

5. Defina o Time Range para cobrir o período em que a conexão anômala ocorreu.

6. Clique em Query para executar a consulta de filtro combinada.

Você pode filtrar os resultados da Pesquisa (auditoria) por tipo de operação. Na página SQL Explorer and Audit, abra a guia Search e defina o filtro Operation type como LOGIN para consultar o histórico de logon da instância. A lista de resultados inclui as colunas User (conta de logon) e Client IP, que ajudam a identificar quem fez logon e de onde.

O SQL Explorer and Audit registra operações no nível da instrução SQL e não fornece comparação de valores antes e depois no nível do campo. Para visualizar o valor de um campo específico, como status, antes e depois de uma alteração, use o recurso de rastreamento de dados do Data Management (DMS) para localizar a origem da alteração.