Using different server SQL mode settings on the master and the
slave may cause the same
statements to be handled differently on the master and the
slave, leading the master and slave to diverge. For best
results, you should always use the same server SQL mode on the
master and on the slave. This advice applies whether you are
using statement-based or row-based replication.
If you are replicating partitioned tables, using different SQL modes on the master and the slave is likely to cause issues. At a minimum, this is likely to cause the distribution of data among partitions to be different in the master's and slave's copies of a given table. It may also cause inserts into partitioned tables that succeed on the master to fail on the slave.
For more information, see Section 5.1.7, “Server SQL Modes”.
As of MySQL 5.7.4, the deprecated
NO_ZERO_IN_DATE SQL modes do
nothing. Instead, their previous effects are included in the
effects of strict SQL mode
STRICT_TRANS_TABLES). In other
words, strict mode now means the same thing as the previous
meaning of strict mode plus the
NO_ZERO_IN_DATE modes. This
change reduces the number of SQL modes with an effect dependent
on strict mode and makes them part of strict mode itself.
To prepare for these SQL mode changes, it is advisable before upgrading to read SQL Mode Changes in MySQL 5.7. That discussion provides guidelines to assess whether your applications will be affected by these changes.
NO_ZERO_IN_DATE SQL modes are
still recognized so that statements that name them do not
produce an error, but will be removed in a future version of
MySQL. To make advance preparation for versions of MySQL in
which these modes do not exist, applications should be modified
to not refer to those mode names.