← Back to team overview

linux-traipu team mailing list archive

[Bug 929918] Re: Drizzledump import from MySQL crashing slave replication

 

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

-- 
You received this bug notification because you are a member of UBUNTU -
AL - BR, which is subscribed to Drizzle.
https://bugs.launchpad.net/bugs/929918

Title:
  Drizzledump import from MySQL crashing slave replication

Status in A Lightweight SQL Database for Cloud Infrastructure and Web Applications:
  New

Bug description:
  I'm importing data from a MySQL database and applying it to a new
  Drizzle database server using --destination-type=database.

  This drizzle database server is part of a master-master pair, and as
  such is adding transactions to sys_replication.queue .. One of these
  very early on is apparently failing to insert into the queue and
  crashing the import.

  (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_value:' at line 1
  Failure while executing:
  INSERT INTO `sys_replication`.`queue` (`master_id`, `trx_id`, `seg_id`, `commit_order`,  `originating_server_uuid`, `originating_commit_id`, `msg`) VALUES (1, 28694, 1, 24, 'd64ec01b-2755-42cd-8922-c04c28ca0536' , 24, 'transaction_context {
    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', 'e02c7b2dd2edeb1664770610c22bf06b1a524daa', 'ios', 'Seby''s iPhone 4', '1', '0', '2011-08-10 11:14:45', '2011-08-10 11:14:45'

  Here's the part of the log output where things go sour.

  record {
        insert_value: \"13\"
        insert_value: \"10000015\"
        insert_value: \"e02c7b2dd2edeb1664770610c22bf06b1a524daa\"
        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_message_stderr' errmsg() failedReplication slave: Unable to insert into queue.

  You can see all of the log for the box I'm doing the insert into at
  http://paste.drizzle.org/show/598/ .. minus the binary data that it
  started spewing after that point. (Which was keeping me from using ANY
  paste service..) I've attached the log including the binary data as
  well.

  I'm on CentOS 5.6, using the RPM installation of Drizzle drizzle-
  rel.2012.01.30-rpm . I'm hosted on Amazon, my EC2 node type is
  m2.2xlarge.

  I'm happy to provide any configuration details you'd like to see.

To manage notifications about this bug go to:
https://bugs.launchpad.net/drizzle/+bug/929918/+subscriptions


References