I will write some more on this interface eventually, following up my previous MySQL Audit API post, and will show some ideas and hopefully push some interesting code (I have ideas!). But note that the API so far isn't well documented (only source so far), but there is work underway to fix this by the friendly MySQL docs team.
Already I have realized that Audit events are different than I thought. The source of the event is currentlyt either from inside the parser code or from the general log code. The events I got looked like general log events, so I just imaginged this was the source of what I saw, and I never relaized that there was another possible source, the parser. Actually, when the general log is not on, the parser events is all you get, but as I have shown, this is usually good enough. For the log events to be received, you still have to have the general log on. In practice, this doesn't seem to be much of a difference, but I'll keep an eye on it once the documentation is in place, and if there is a use for having Audit general log events, without having the general log per-se on, then I will create a worklog for that (along the lines of having the general_log variables have 3 values (ON, AUDIT_ONLY and OFF) or something like that.
/Karlsson
2 comments:
It's a bug, MYSQL_AUDIT_GENERAL_LOG events should be generated independently from general log being enabled.
Besides, there is no source of events inside the parser code. sql_parse.cc is not a parser, sql_yacc.yy is.
Thanx Sergeii. Regarding the parser, you are right of course that the parser, in terms of sybtax definitions, is in sql_yacc.yy. What sql_parse.cc contains though, is the entry point for the parser itself, i.e. whenever you call "the parser", you actually call a function in sql_parse.cc that in turn calls the parser. But then again, this is not where the auditing is called anyway, so you are probably right.
/Karlsson
Post a Comment