Replication Features and Issues 17.5.1.10 Replication and DIRECTORY Table Options 17.5.1.11 Replication of DROP ... IF EXISTS Statements 17.5.1.12 Replication and Floating-Point Values 17.5.1.13 Replication and FLUSH 17.5.1.14 Replication and System Functions If a  DATA DIRECTORY  or  INDEX DIRECTORY  table option is used in a  CREATE TABLE  statement on the source server, the table option is also used on the replica. This can cause problems if no corresponding directory exists in the replica host file system or if it exists but is not accessible to the replica MySQL server. This can be overridden by using the  NO_DIR_IN_CREATE  server SQL mode on the replica, which causes the replica to ignore the  DATA DIRECTORY  and  INDEX DIRECTORY  table options when replicating CREATE TABLE  statements. The result is that  MyISAM  data and index files are created in the table’s database directory. For more information, see Section 5.1.11, “Server SQL Modes” . The  DROP DATABASE IF EXISTS ,  DROP TABLE IF EXISTS , and  DROP VIEW IF EXISTS statements are always replicated, even if the database, table, or view to be dropped does not exist on the source. This is to ensure that the object to be dropped no longer exists on either the source or the replica, once the replica has caught up with the source. DROP ... IF EXISTS  statements for stored programs (stored procedures and functions, triggers, and events) are also replicated, even if the stored program to be dropped does not exist on the source. With statement-based replication, values are converted from decimal to binary. Because conversions between decimal and binary representations of them may be approximate, comparisons involving floating- point values are inexact. This is true for operations that use floating-point values explicitly, or that use values that are converted to floating-point implicitly. Comparisons of floating-point values might yield different results on source and replica servers due to differences in computer architecture, the compiler used to build MySQL, and so forth. See Section 12.3, “Type Conversion in Expression Evaluation” , and Section B.3.4.8, “Problems with Floating-Point Values” . Some forms of the  FLUSH  statement are not logged because they could cause problems if replicated to a replica:  FLUSH LOGS  and  FLUSH TABLES WITH READ LOCK . For a syntax example, see Section 13.7.8.3, “FLUSH Statement” . The  FLUSH TABLES ,  ANALYZE TABLE ,  OPTIMIZE TABLE , and  REPAIR TABLE  statements are written to the binary log and thus replicated to replicas. This is not normally a problem because these statements do not modify table data. However, this behavior can cause difficulties under certain circumstances. If you replicate the privilege tables in the  mysql  database and update those tables directly without using  GRANT , you must issue a  FLUSH PRIVILEGES  on the replicas to put the new privileges into effect. In addition, if you use FLUSH TABLES  when renaming a  MyISAM  table that is part of a  MERGE  table, you must issue  FLUSH TABLES  manually on the replicas. These statements are written to the binary log unless you specify NO_WRITE_TO_BINLOG  or its alias  LOCAL . Certain functions do not replicate well under some conditions: •The  USER() ,  CURRENT_USER()  (or  CURRENT_USER ),  UUID() ,  VERSION() , and  LOAD_FILE() functions are replicated without change and thus do not work reliably on the replica unless row-based replication is enabled. (See Section 17.2.1, “Replication Formats” .) 3662