Bug #45151 | Binary Log mixed mode restore reports duplicates and missing fields. | ||
---|---|---|---|
Submitted: | 28 May 2009 8:28 | Modified: | 28 Jun 2009 9:28 |
Reporter: | Ilias Ber | Email Updates: | |
Status: | No Feedback | Impact on me: | |
Category: | MySQL Server | Severity: | S1 (Critical) |
Version: | 5.1.34 | OS: | FreeBSD |
Assigned to: | CPU Architecture: | Any | |
Tags: | BINARY, duplicate, log, mixed, mode, restore |
[28 May 2009 8:28]
Ilias Ber
[28 May 2009 8:34]
Sveta Smirnova
Thank you for the report. Please provide repeatable test case showing this is a bug in MySQL code and not just wrong usage. For example, this duplicate key error can occur if one started recovery while increment property for tables set to wrong value.
[28 May 2009 8:37]
Ilias Ber
Hello, Forgot to mention duplicates were incurring on innodb tables that were not using any kind of auto-increment. Could you please inform me as to how statements are logged when ROW mode is automatically chosen by mysql? Thanks,
[28 May 2009 9:28]
Sveta Smirnova
Thank you for the feedback. You can read about replication formats at http://dev.mysql.com/doc/refman/5.1/en/replication-formats.html, especially at http://dev.mysql.com/doc/refman/5.1/en/replication-sbr-rbr.html When MIXED mode is using mysqld chooses ROW format in case it statement is not safe for STATEMENT format and STATEMENT otherwise. What I need from you as repeatable test case: 1. Initial dump 2. Step-by-step description how you started recovery 3. Minimum set of binary logs problem is observable with. Would be good if you could minimize it to minimum possible test case. For example, one table.
[28 Jun 2009 23:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".