MySQL Bugs: #24231: Mixed-endian replication issue

Bug #24231	Mixed-endian replication issue
Submitted:	12 Nov 2006 17:21	Modified:	26 Oct 21:26
Reporter:	John David Duncan
Status:	Closed
Category:	Server: ClusterRep	Severity:	S3 (Non-critical)
Version:	mysql-5.1	OS:	Any
Assigned to:	Mats Kindahl	Target Version:	CGE
Tags:	5.1.11
Triage:	Triaged: D1 (Critical)

Description:
When you enable replication from an Intel cluster to a PowerPC cluster, some data is
corrupted.  This issue was discovered by testing cluster replication in a room full of
laptops at mysqlcamp.  

How to repeat:
Configure an Intel-based cluster. 
Configure a mysql node on the Intel cluster as the replication master.
Configure a PowerPC-based cluster.
Configure a mysql node on the PPC cluster as a replication slave.

master> CREATE TABLE t ( i int not null primary key, d timestamp) ;
master> INSERT into t values (1, now()) ;

Then try "SELECT * from t" on both clusters.  

In our test, the timestamp value on the master was 'Sat Nov 11 16:21:32 PST 2006' which
is decimal 1163290892 and hex 4556690C.   But the reported value on the slave was hex
0C695645, i.e. decimal 208229957. 

Suggested fix:
This is a very esoteric case.  It could be documented as a limitation. 
 
However, there is also a more interesting case, where the slave is not a whole cluster
but a single mysql server used for reporting.  In this situation it would not be unusual
for the reporting machine to have a different architecture than the cluster machines.

Thank you for the report.

Verified as described.

See also BUG#29549.

I cannot repeat this problem with 6.3.20, so I think it got fixed at some point.

Yes, the bug mentioned by Lars above has a patch for fixing it.