One of my first tasks on the Drizzle team was to check out the transaction log, part of
Jay Pipes' work on replication. We needed to make sure that the log itself was rock-solid and that any code written to use it would have a worthy foundation. As it turns out, some people are really interested in getting replication working ; )
As can be seen from the
blueprint, testing will involve two of our main testing tools, the randgen and our standard test suite (test-run, dtr, etc). So far, our efforts have been concentrated on writing tests for the test suite. These tests have largely consisted of executing queries that should make it into the transaction log, then using the UDF print_transaction_message($log_file,$log_offset) to examine the log's contents. The tests can be found
here and executed with ./test-run --suite=transaction_log. (NOTE: The tests themselves are largely complete, but our expected results are not yet finalized / correct due to the bugs noted below). I'd like to extend a special thanks to Joe Daly for his help in writing these tests and finding some bugs in the log.
While we have tested all of the available data types and basic transactions and they are looking quite solid, our efforts have still turned up some interesting bugs:
(this list is maintained at the launchpad blueprint noted above)
- Bug #594873: transaction log incorrectly records NULL INSERT into an ENUM as the first permissible value
- Bug #594876: transaction log not differentiating NULL values and empty string for char columns
- Bug #596972: transaction log logging 0 for NULL INTEGER VALUES
- Bug #599582: Transaction log does not appear to be collecting all information for multi-row REPLACE statements
- Bug #597910: Transaction log does not appear to be capturing FOREIGN KEY information
- Bug #599851: Transaction log not capturing CASCADE'd UPDATE data on a table using a foreign key
- Bug #599952: transaction log attributing statements to wrong tables on multi-table, multi-statement transactions
- Bug #600032: rollback to savepoint not handled correctly in transaction log
- Bug #600795: LOAD DATA INFILE INSERTs not registered by the transaction log
The first 3 bugs relate to how the log captures NULL values for various data types and have been traced to a single root cause. The remaining 6 seem more interesting and serious for replication functionality. To summarize, the transaction log appears to have trouble with trickier (more complex) transactions. These include changes propagated via a foreign key, multi-row REPLACE, and multi-table transactions.
Once these bugs have been addressed, we will continue with test development for the randgen. This will include stress testing the server / log with DDL-generating grammars and validation of the data stored within the log. Initial experiments with high-volume (10+ threads at 250k queries each) have looked promising (no crashes, locks, major slow downs over time). In the meantime, we'll be busy with
other tasks (dump+restore)
As always, we welcome any feedback, questions, or bug fixes : )
More information on Drizzle testing can be found
here.
