Oracle 5.0, Справочное руководство

Страница: 1520 / 3232

Replication Features and Issues
1500
the compiler used to build MySQL, and so forth. See Section 12.2, “Type Conversion in Expression
Evaluation” , and Section C.5.5.8, “Problems with Floating-Point Values” .
16.4.1.7. Replication and
FLUSH
Some forms of the
FLUSH
statement are not logged because they could cause problems if replicated
to a slave:
FLUSH LOGS
,
FLUSH MASTER
,
FLUSH SLAVE
, and
FLUSH TABLES WITH READ LOCK
.
For a syntax example, see Section 13.7.6.2, “
FLUSH
Syntax” . The
FLUSH TABLES
,
ANALYZE TABLE
,
OPTIMIZE TABLE
, and
REPAIR TABLE
statements are written to the binary log and thus replicated to
slaves. 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 slaves 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 slaves. These statements are written to the binary log unless you specify
NO_WRITE_TO_BINLOG
or its alias
LOCAL
.
16.4.1.8. Replication and System Functions
Certain functions do not replicate well under some conditions:
• The
USER()
[964] ,
CURRENT_USER()
[959] ,
UUID()
[967] ,
VERSION()
[964] , and
LOAD_FILE()
[890] functions are replicated without change and thus do not work reliably on the
slave.
• For
NOW()
[926] , the binary log includes the timestamp. This means that the value as returned by the
call to this function on the master is replicated to the slave. This can lead to a possibly unexpected
result when replicating between MySQL servers in different time zones. Suppose that the master
is located in New York, the slave is located in Stockholm, and both servers are using local time.
Suppose further that, on the master, you create a table
mytable
, perform an
INSERT
statement on
this table, and then select from the table, as shown here:
mysql> CREATE TABLE mytable (mycol TEXT);
Query OK, 0 rows affected (0.06 sec)
mysql> INSERT INTO mytable VALUES ( NOW() );
Query OK, 1 row affected (0.00 sec)
mysql> SELECT * FROM mytable;
+---------------------+
| mycol |
+---------------------+
| 2009-09-01 12:00:00 |
+---------------------+
1 row in set (0.00 sec)
Local time in Stockholm is 6 hours later than in New York; so, if you issue
SELECT NOW()
on the
slave at that exact same instant, the value
2009-09-01 18:00:00
is returned. For this reason,
if you select from the slave's copy of
mytable
after the
CREATE TABLE
and
INSERT
statements
just shown have been replicated, you might expect
mycol
to contain the value
2009-09-01
18:00:00
. However, this is not the case; when you select from the slave's copy of
mytable
, you
obtain exactly the same result as on the master:
mysql> SELECT * FROM mytable;
+---------------------+
| mycol |
+---------------------+
| 2009-09-01 12:00:00 |
+---------------------+
1 row in set (0.00 sec)
As of MySQL 5.0.13, the
SYSDATE()
[928] function is no longer equivalent to
NOW()
[926] .
Implications are that
SYSDATE()
[928] is not replication-safe because it is not affected by
SET