views:

15

answers:

1

I am researching the possibility to log all the changes made to a MySQL database including DDL statements that may occur and use that information so it can be synchronized with a remote database.

The application itself is written in C# so the best synchronization technology that I have seen so far to be available is Microsoft Sync Framework. This framework itself proposes a solution to track changes made to the DB by adding triggers and additional tables to store the deleted rows.

This does not seem to be a great idea for my case since it involves changing the schema of a standard DB used by more than 4 products. This method is also effectively doubling the number of tables (by adding a new table for the deleted rows of each table) which also does not feel to good.

On the other side MySQL has this great thing binlog, which tracks all the changes and can also use the so called mixed mode to track statements in most cases (so they can be executed again on the remote DB to replicate data) and the raw data when a non-deterministic function is called (like NOW()) so the data updated is the same on both places.

Also there seems to be 2 standard ways to retrieve this data: 1) The mysqlbinlog utility 2) Calling 'SHOW BINLOG EVENTS'

Option 2 seems the better to me since it does not require calling another external application, and running an application on the DB machine, BUT it does not include the actual data for the logged ROW format statements (only stuff like: table_id: 47 flags: STMT_END_F which tells me nothing).

So finally my questions are:

  1. Is there a better way to track the changes made to a MySQL db without changing the whole structure and adding a ton of triggers and tables? I can change the product to log it's changes too but then we have to change all the products using this db to be sure we log everything ... and I think it's almost impossible to convince everyone.

  2. Can I get all the information about the changes made using SHOW BINLOG EVENTS? Including the ROW data.

Thanks!

P.S. I researched MySQL Proxy too, but the problem in logging statements in all cases is that the actual data in non deterministic functions is not included.

A: 

Option 3 would be to parse the bin log yourself from within your app - that way you get total control of how often you check etc, and you can see all the statements with the actual values used.

Mat
Yes this is an option, but the problem is that MySQL has a several versions of the binary log file, and they keep changing it...Option 4 would be probably best. In MySQL 5.5 there is so called Semi-Synchronous replication which signals the slaves on transaction commit. It is possible to write an app which can mimic a slave and wait for a message with a whole transaction. Unfortunately 5.5 is not generally available and this option is still available for Linux only which is not that great :(.
flipm0de