2011-04-07 3 views

Répondre

3

Exécutez la commande suivante à partir d'un outil mysql pour afficher tous les processus en cours d'exécution (y compris les connexions de couchage):

SHOW PROCESSLIST 

Ou, vous pouvez interroger la table information_schema pour obtenir le même:

select * from information_schema.processlist 

Pour voir un historique de tous ceux qui se sont connectés, vous pouvez configurer le journal de requête général pour aller à une table, en ajoutant le paramètre de démarrage suivant à votre démarrage mysqld "--log-output = TABLE --general-log", puis vous pouvez interroger cette information sur le général_log ta ble dans le schéma mysql. Voici la requête que vous pouvez utiliser:

select * from mysql.general_log where command_type = 'Connect'; 

Un mot d'avertissement cependant, cette table pourrait devenir énorme. Vous voudrez le nettoyer périodiquement.

+1

Ceci montrera seulement les requêtes en cours d'exécution - pas qui a déjà accédé à la base de données. –

+0

Ah. J'ai manqué ça. Il n'y a aucun moyen de voir qui s'est vraiment déconnecté, vous ne pouvez voir que les utilisateurs actuellement connectés (même s'ils n'exécutent pas de requêtes, ils auront toujours une connexion ouverte). Si vous voulez garder une trace de tous ceux qui ont été connectés, vous aurez probablement besoin de créer un travail cron qui capture ces informations dans une table périodiquement, que vous pouvez ensuite interroger. – squawknull

+0

Vous pouvez également utiliser le journal de requête général - http://dev.mysql.com/doc/refman/5.1/en/query-log.html. Vous pouvez configurer cela pour vous connecter à une table que vous pourriez ensuite interroger directement. – squawknull

1

Vous pouvez consulter les utilisateurs qui maintiennent une connexion à la base de données en consultant SHOW PROCESSLIST ou INFORMATION_SCHEMA.PROCESSLIST.

Un enregistrement historique de ces données n'est pas disponible. L'utilisation du journal de requête général comme suggéré ailleurs n'est pas une bonne idée, car elle ne s'échelonne pas du tout: Le journal de requête général enregistre chaque instruction que voit votre serveur et l'écrit ajoute considérablement à la contention sur LOCK_log et sur le disque I/O. Si votre journal de requête général est une table CSV, il ne peut pas être interrogé efficacement, et s'il s'agit d'une table MyISAM, il va essentiellement sérialiser toutes les requêtes (même les requêtes de lecture!) Dans votre base de données. C'est-à-dire, parce que chaque requête devra être enregistrée, même lire des requêtes. Pour cela, une écriture dans le journal de requête générale est nécessaire. Pour cela, un verrou de table sur la table de journal MyISAM est demandé. Ceci est très extrêmement lent et pas conseillé du tout, même sur les serveurs à faible charge.

D'autres formats pour le journal de requête générale ne sont pas pris en charge.

Il existe un ensemble de variables pouvant définir des actions au démarrage du serveur, à la connexion esclave et à la connexion de l'utilisateur.

[email protected] [kris]> show global variables like 'init%'; 
+---------------+-------+ 
| Variable_name | Value | 
+---------------+-------+ 
| init_connect |  | 
| init_file  |  | 
| init_slave |  | 
+---------------+-------+ 
3 rows in set (0.00 sec) 

En mettant init_connect à une instruction d'insertion qui se connecte l'utilisateur courant, l'heure et l'identifiant de connexion, vous pouvez générer le journal que vous voulez d'une manière plus échelonnable. Utilisez une table InnoDB avec l'identifiant auto_increment pour cela.

Veuillez noter que init_connect n'est pas traité pour les connexions d'un utilisateur root (SUPER_PRIV) pour des raisons de sécurité. Ceux-ci échapperont à votre journalisation.

Dans MySQL 5.5, l'API d'audit a été ajoutée au serveur. Ce que vous voulez vraiment, je crois, c'est un plugin d'audit. Voir http://dev.mysql.com/doc/refman/5.5/en/writing-audit-plugins.html pour plus de détails.

Questions connexes