Enhancements to be more specific about what is audited

[creechy]

There are a changes I have made to the plugin you may be interested in,

New options to limit auditing

First and foremost, these changes provide more options to limit the amount of data that is recorded in the audit log. Specifically for my purposes, I want to only log operations that change the data, and only do this for specific tables in specific databases. To support this I added the following options:

audit_record_cmds - This is a comma/whitespace separated list of operations to log.

audit_record_objs - This is a comma/whitespace separated list of databases & tables to log of the form "database:table"

So, for example, if I wanted to log only inserts, updates & replaces that occur in the account table in the financials database, I would set the following

audit_record_cmds = insert,update,replace
audit_record_objs = financials:account

New checksum assurance option

Considering the plugin appears to hotpatch into routines in the running process, and does so by identifying the specific version by checksum, I added an option that can be used with audit_offsets as another assurance the offsets are only used for the expected version.

To do this I added an audit_checksum option which is used when audit_offsets is present. This value would be the checksum that is generated when running the offset-extract.sh command. The plugin will shutdown if the specified offset doesn't match the calculated one.

I find that this could be useful in situations where you upgrade the mysql package.

Bugfix

Bugfix: the audit_delay_cmds was not configured correctly when specified in my.cnf because the update() method does not get called. I added code in audit_plugin_init() to parse and load.

Code reorganization

Created new string_to_array() function used in audit_delay_cmds parsing (and the new audit_record_cmds & audit_record_objs) processing to turn a string into an array of values.

[glicht]

Thanks for submitting this pull request and the detailed explanation.

I think these are good enhancement and we will try to merge this in soon.

Regarding the format of audit_record_objs I would go with a naming scheme of: database.table. I think using a "." instead of ":" is better understood.

Another thing I am thinking about is adding support for the syntax of: database.* as a means to indicate all tables in a specific database will probably come in as useful.

[creechy]

Not sure why I chose color instead of period, the later definitely makes more sense. Is will make that change in my fork.

I had thought about wild cards but decided to defer implementation until we decide if the plugin will fit our needs and tought it might be a pain to implement. However I realized that I really could just check three permutations against the configured values - database.table, .table and database. - all of which would be easy to build and check against. I may just make that change as well.