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 > >
