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

I don't think this is the case -- this is a UTF-8 table.

For the record, I'll call it out again -- I'm attempting to have two drizzle servers replicate from each other a la master-master with MySQL. The other thing I suspect is going on here (and may be playing into this issue) is that the slave plugin for drizzle may not have the equivalent of replicate-same-server-id=0 (and may be trying to apply its own updates to itself)

Server 1:

/etc/drizzle/drizzled.cnf
server-id=1
pid-file = /var/run/drizzle/drizzled.pid
datadir = /mnt/drizzle/data
auto-increment-increment = 2
auto-increment-offset = 1
drizzle-protocol.bind-address = 0.0.0.0

/etc/drizzle/slave.cnf
ignore-errors

[master2]
master-host = ec2-50-18-94-202.us-west-1.compute.amazonaws.com
master-port = 3306
master-user = root
master-pass = cheese

Server 2:

/etc/drizzle/drizzled.cnf
server-id=2
pid-file = /var/run/drizzle/drizzled.pid
datadir = /mnt/drizzle/data
auto-increment-increment = 2
auto-increment-offset = 2
drizzle-protocol.bind-address = 0.0.0.0

/etc/drizzle/slave.cnf
ignore-errors

[master1]
master-host = ec2-50-18-228-13.us-west-1.compute.amazonaws.com
master-port = 3306
master-user = root
master-pass = cheese

Schema:

delimiter $$

CREATE TABLE `device` (
  `device_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `user_id` bigint(20) unsigned NOT NULL,
  `device_string` varchar(64) NOT NULL,
  `device_os` enum('ios','android') NOT NULL DEFAULT 'ios',
  `name` varchar(128) NOT NULL,
  `enabled` tinyint(1) NOT NULL DEFAULT '1',
  `is_deleted` tinyint(1) NOT NULL DEFAULT '0',
  `created_on` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `updated_on` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`device_id`),
  KEY `user_id` (`user_id`),
  KEY `device_idx` (`device_os`,`device_string`)
) ENGINE=InnoDB AUTO_INCREMENT=522 DEFAULT CHARSET=utf8$$

Attached is the first 13 rows, including the offending one.

Can't blame a guy for hoping it was something simple ; )
My thinking was also leaning in your direction: master-master = dupe-applying updates. (see the aforementioned wishes for the easy fix <g>)
For some reason, I had thought we had addressed this issue, but I cannot find reference to it.
Will work on a test case for this tomorrow. Thanks for the great / quick information

On Fri, 10 Feb 2012 01:49:42 -0000, Patrick Crews <email address hidden> wrote:
> Can't blame a guy for hoping it was something simple ; )
> My thinking was also leaning in your direction: master-master = dupe-applying updates. (see the aforementioned wishes for the easy fix <g>)
> For some reason, I had thought we had addressed this issue, but I cannot find reference to it.
> Will work on a test case for this tomorrow. Thanks for the great /
> quick information

there should be per server uuid - but I can't remember which version
these came in...

--
Stewart Smith

There are server uuids in this build. It doesn't seem to be solving this particular issue. :)