Drizzledump import from MySQL crashing slave replication
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Drizzle |
New
|
Undecided
|
Patrick Crews |
Bug Description
I'm importing data from a MySQL database and applying it to a new Drizzle database server using --destination-
This drizzle database server is part of a master-master pair, and as such is adding transactions to sys_replication
(SQLSTATE 00000) You have an error in your SQL syntax; check the manual that corresponds to your Drizzle server version for the right syntax to use near 's iPad\"
insert_value: \"1\"
insert_value: \"0\"
insert_
Failure while executing:
INSERT INTO `sys_replicatio
server_id: 1
transaction_id: 28694
start_timestamp: 1328637584310604
end_timestamp: 1328637584362243
}
...
It appears to get 12 records correctly, but crashes on the 13th. Here's the source row from MySQL:
'13', '10000015', 'e02c7b2dd2edeb
Here's the part of the log output where things go sour.
record {
insert_value: \"13\"
insert_value: \"10000015\"
insert_value: \"e02c7b2dd2ede
insert_value: \"ios\"
insert_value: \"Seby\\\\\\'s iPhone 4\"
insert_value: \"1\"
insert_value: \"0\"
insert_valu <THERE IS BINARY GARBAGE HERE THAT I DELETED TO LET THE PASTE GET UPLOADED SUCCESSFULLY>
errmsg plugin 'Error_
You can see all of the log for the box I'm doing the insert into at http://
I'm on CentOS 5.6, using the RPM installation of Drizzle drizzle-
I'm happy to provide any configuration details you'd like to see.
Changed in drizzle: | |
assignee: | nobody → Patrick Crews (patrick-crews) |
tags: |
added: slave-plugin removed: slave |
Very interesting bug...would this drizzledump option perhaps be of use ? (just a shot in the dark)
If this doesn't help, if you could provide a limited dump of your MySQL data (the first 13 - 14 records) + your drizzled configs (+ slave configs), I can see about creating a test case for this. Also, is there anything in the logs of the other server of note?
Thanks for the report.
--my-data- is-mangled
If your data is UTF8 but has been stored in a latin1 table using a latin1 connection then corruption is likely and drizzledump by default will retrieve mangled data. This is because MySQL will convert the data to UTF8 on the way out to drizzledump and you effectively get a double-conversion to UTF8.
This typically happens with PHP apps that do not use SET NAMES.
In these cases setting this option will retrieve the data as you see it in your application.
New in version Drizzle7: 2011-01-31