According to the MySQL 5.0 Certification Study Guide
Chapter 32 Section 32.3.4, Pages 456,457 describe the Conditions for Binary Portability which bring out the following:
Binary portability is important if you
want to take a binary backup that was
made on one machine and use it on
another machine that has a different
architecture. For example, using a
binary backup is one way to copy
databases from one MySQL server to
another.
For MyISAM, binary portability means
that you can directly copy the files
for a MyISAM table from one MySQL
server to another on a different
machine and the second server will be
able to access the table.
For InnoDB, binary portability means
that you can directly copy the
tablespace files from a MySQL server
on one machine to another server on a
different machine and the second
server will be able to access the
tablespace. By default, all the InnoDB
tables managed by a server are stored
together in the tablespace, so
portability of the tablespace is a
function of whether all individual
InnoDB tables are portable. If even
one table is not portable, neither is
the tablespace.
MyISAM tables and InnoDB tablespaces
are binary portable from one host to
another if two conditions are met:
- Both machines must use two's-complement integer arithmetic
- Both machines must use IEEE floating-point format or else the
tables must contain no floating-point
columns (FLOAT or DOUBLE)
In practice, those two conditions pose
little restriction. Two's-complement
integer arithmetic and IEEE
floating-point format are the norm on
modern hardware. A third condition for
InnoDB binary portability is that you
should use lowercase names for tables
and databases. This is because InnoDB
stores these names internally (in its
data dictionary) in lowercase on
Windows. Using lowercase names allows
binary portability between Windows and
Unix, to force the use of lowercase
names, you can put the following lines
in an option file:
[mysqld]
lower_case_table_names=1
If you configure InnoDB to use
per-table tablespaces, the conditions
for binary portability are extended to
include the .ibd files for InnoDB
tables as well. (The conditions for
the shared tablespaces still appliy
because it contains the data
dictionary that stores information
about all InnoDB tables.)
If conditions for binary portability
are not satisfied, you can copy MyISAM
or InnoDB tables from one server to
another by dumping them using some
text format (for example, with
mysqldump) and reloading them into the
destination server.
From this quotation, you can see that InnoDB's data dictionary is very case sensitive to table names. You are basically playing Russian Roulette by mixing tablename case sensitivity between Master and Slave.
I have discussed mixing cases between operating systems in MySQL :
Terminology
What you're describing is a common set up that may be variously described as master-master replication, dual-master, active-active, bidirectional, or a few other terms.
Good reasons not to do it
The team who wrote High Performance MySQL offer this pithy summary of master-master replication - specifically, "active-active" replication:
In general, allowing writes on both servers causes way more trouble than it’s worth.
Baron Schwartz, one of the authors, offers a slightly more blunt opinion on his blog.
Save yourself grief, work, and money. Never write to both masters.
There are many things that can go wrong if both servers are updating data at the same time, including (but by no means limited to):
If something goes wrong with replication - even a temporary network glitch, you'll likely end up with a split brain and it may be impossible to determine which data is "correct"
If AUTO_INCREMENT MySQL settings are wrong, it's easy for data collision to take place
Row locking no longer offers any protection - data can be manipulated on one master even while a transaction has it locked on another
Good reasons to do it - carefully
The most common reason for master-master replication is to so that you can very quickly switch the "current" master if something goes wrong with one of your servers.
The common way to implement this is to set up a barrier that ensures that only one of your servers is every written to by your application servers. This is usually a hardware load balancer, or software load balancer like HAProxy.
The authors of High Performance MySQL (mentioned above) describe this as "active-passive" master-master replication.
As long as the barrier is robust, you are fairly well protected from all of the issues described above. This may be supported by setting read_only on the "passive" server for an extra layer of protection.
A well-built master-master setup can offer you some amazing flexibility - you can do some really complex table or server maintenance on your passive server, wait for replication to catch up, then migrate your load balancer over to point at your shiny, reconfigured environment with almost no service downtime. This sort of thing does need to be planned carefully, though, and a lot can go wrong.
Best Answer
Do this on both machines:
Also check the OS dates.
I think you will find a configuration difference.