Bug #14471 | Relay bin log file corruption | ||
---|---|---|---|
Submitted: | 29 Oct 2005 18:08 | Modified: | 2 Oct 2006 12:28 |
Reporter: | Stephane PAQUOT | Email Updates: | |
Status: | No Feedback | Impact on me: | |
Category: | MySQL Server | Severity: | S2 (Serious) |
Version: | 5.0.15 | OS: | Windows (Windows) |
Assigned to: | Assigned Account | CPU Architecture: | Any |
[29 Oct 2005 18:08]
Stephane PAQUOT
[31 Oct 2005 11:50]
MySQL Verification Team
Hello Stephane, Thank you for the report, but we really need a repeatable test case the for bug report to reproduce and then fix this problem.
[2 Nov 2005 22:43]
Stephane PAQUOT
Hello Victoria, I'm sorry, it is very difficult to repeat the case. Since the last corruption in the relay log file relay_DBA_T2_MYS.000075, the problem did not occur again with the same stress test (108000 insertions). It is very interesting to notice that MySQL decided to make a rotation of the relay log just after the corruption. I understand if you close this case as it is not reproductible.
[6 Nov 2005 9:38]
Valeriy Kravchuk
Please, reopen this bug report in case of new similar failure. May be, it was some kind of network failure that lead to corruption.
[7 Dec 2005 0: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".
[31 Aug 2006 19:46]
Lars Thalmann
Please consider using 'mysqldump --hexdump' to show which characters are being wrongly encoded.
[31 Aug 2006 20:16]
Sveta Smirnova
Null characters are escaped by \{null character itself} instead of correct \0.
[5 Sep 2006 11:29]
Stephane PAQUOT
As I could not provide a reproductible case last year in December 2005, I have dumped the table, truncated this one and reloaded this table from the backup. No issue has been reported with this reload by the replication system. So I'm not able to give you the mysqldump with --hexdump option to give you the initial status with encoding when the issue occured, I'm really sorry. Further more, I have upgraded to version 5.0.24a. I can build a 5.0.15 system with replication to try to reproduce this encoding issue if you wish.
[28 Sep 2006 22:52]
Andrei Elkin
Sveta, after reading support documents i don't think this old bug really match your current issue. And to back this up: 1. in the old bug manifests as a sudden reaching relay-log-space-limit, with a show slave status reporting the offending query; there is mentioning on rotation log event also. 2. there is even no evindence of a common part betten old and new cases. The old reporter provided the original of the query as it was in master binlog, which is different from what appeared in relay-log of slave. But in new case, there is no master's version. This makes answering to the customer's question why this "scrumbling" happens hardly possible. I suggest to close this bug, to file a new bug and ask the customer to provide the original master's statement.
[2 Oct 2006 12:28]
Sveta Smirnova
As Andrei requested opened new bug #22889 for 4.0 issue and returned status to "No feedback" for this one.