Very interesting. Waiting for update.
On Jun 15, 2011 4:51 AM, "Hank" <hes...@gmail.com> wrote:
>
> The slave is receiving "null" as the statement based insert, not an out of
> range number from the master.
>
> I've been doing more research all day on this bug and have a bit more
> information as to what's causing it. I plan to write it up tomorrow and
> post it.
>
> Basically, everything works perfectly, until I add a
> "replication-ignore-table=xxx" statement in my.cnf where "xxx" is a
> different table with a unique id INT auto-increment as the single primary
> key And then the values being inserted into the "test" table (above, not
> ignored) represent the last-insert-id of the replication *ignored* table
on
> the slave
>
> Yeah, pretty strange, I know. But totally repeatable.
>
> -Hank
>
>
> 2011/6/14 Halász Sándor <h...@tbbs.net>
>
> > >>>> 2011/06/13 22:38 -0400, Hank >>>>
> > But that bug report was closed two years ago. I have no idea if it's
the
> > server sending bad data or the slaves. I think it's the slaves, because
on
> > the slave error, it clearly is getting this statement: "insert into
test
> > values (1,null)" to replicate, but when it is executed, the "null" is
> > converted into a random number. But it's happening on all of my slaves,
a
> > mix of 32 and 64 bit 5.5.8 and 5.5.11 boxes.
> > <<<<<<<<
> >
> > If the master were sending random big numbers, and replication on the
slave
> > in the usual way handled out-of-bound numbers when not allowed to fail,
then
> > 65535 would be an expected value for a signless 16-bit number. Of
course, if
> > this were true, the slave would be getting not that statement but
"insert
> > into test values (1,469422)".
> >
> >
> > --
> > MySQL General Mailing List
> > For list archives: http://lists.mysql.com/mysql
> > To unsubscribe: http://lists.mysql.com/mysql?unsub=hes...@gmail.com
> >
> >
