Bug #24231 Mixed-endian replication issue
Submitted: 12 Nov 2006 16:21 Modified: 26 Oct 2009 20:26
Reporter: John David Duncan Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Cluster: Replication Severity:S3 (Non-critical)
Version:mysql-5.1 OS:Any
Assigned to: Mats Kindahl CPU Architecture:Any
Tags: 5.1.11
Triage: Triaged: D1 (Critical)

[12 Nov 2006 16:21] John David Duncan
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.
[26 Apr 2007 18:45] Sveta Smirnova
Thank you for the report.

Verified as described.
[4 Sep 2007 11:28] Lars Thalmann
See also BUG#29549.
[26 Oct 2009 20:22] John David Duncan
I cannot repeat this problem with 6.3.20, so I think it got fixed at some point.
[27 Oct 2009 8:26] Mats Kindahl
Yes, the bug mentioned by Lars above has a patch for fixing it.