Transaction log losing data when a bad query (ERROR 1093) is encountered mid-transaction.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Drizzle |
Fix Released
|
High
|
David Shrewsbury | ||
7.0 |
Fix Released
|
High
|
David Shrewsbury |
Bug Description
The transaction log is appearing to lose data from row-touching queries with AUTOCOMMIT=OFF after a new START TRANSACTION has been issued.
With AUTOCOMMIT = OFF, this query:
UPDATE `c` SET `col_bigint` = 4 ORDER BY `col_bigint`
Appears to not be logged. The diff is produced via drizzledump output of the original server and a server populated by the output of transaction_reader called on the original server's transaction.log file.
This appears to affect several other transactions as well. Only the simplest diff is provided as example.
Still working on a repeatable test case / troubleshooting what exactly is happening here.
# 2010-09-20T13:06:06 Executing diff --unified /tmp//translog_
--- /tmp//translog_
+++ /tmp//translog_
@@ -278,7 +278,7 @@
KEY `col_char_10_key` (`col_char_
KEY `col_char_1024_key` (`col_char_
) ENGINE=InnoDB COLLATE = utf8_general_ci;
-INSERT INTO `c` VALUES (1,NULL,
+INSERT INTO `c` VALUES (1,NULL,
Related branches
- Drizzle Merge Team: Pending requested
-
Diff: 1416 lines (+316/-329)3 files modifieddrizzled/transaction_services.cc (+2/-1)
plugin/transaction_log/tests/r/transaction_log_data_type.result (+142/-142)
plugin/transaction_log/tests/r/transaction_log_transaction.result (+172/-186)
Changed in drizzle: | |
status: | New → Confirmed |
importance: | Undecided → High |
Changed in drizzle: | |
assignee: | nobody → David Shrewsbury (dshrews) |
tags: | added: replication |
Changed in drizzle: | |
status: | Confirmed → In Progress |
Changed in drizzle: | |
status: | In Progress → Fix Committed |
Attached is trimmed randgen output. For clarity, I have removed all bad queries (impossible WHERE's, etc) and SELECT's (I doubt they contributed to this).
What I have tried to do is compare randgen queries to the SQL generated by transaction_reader when called against the server's transaction log.
From my analysis, it appears that a block of queries was somehow missed / ignored by the log as queries that came before and after this block are visible in the transaction_reader output.
I can provide assistance with running the randgen test if you are interested in duplicating things yourself that way. Otherwise, we can work on trying to produce a test-run'able test case.