Replication of invoked features such as user-defined functions (UDFs) and stored programs (stored procedures and functions, triggers, and events) provides the following characteristics:
The effects of the feature are always replicated.
The following statements are replicated using statement-based replication:
However, the effects of features created, modified, or dropped using these statements are replicated using row-based replication.
Attempting to replicate invoked features using statement-based replication produces the warning Statement is not safe to log in statement format. For example, trying to replicate a UDF with statement-based replication generates this warning because it currently cannot be determined by the MySQL server whether the UDF is deterministic. If you are absolutely certain that the invoked feature's effects are deterministic, you can safely disregard such warnings.
The status of the event is set to
SLAVESIDE_DISABLED on the slave
regardless of the state specified (this does not apply
The master on which the event was created is identified
on the slave by its server ID. The
ORIGINATOR column in
originator column in
mysql.event store this information.
See Section 19.7, “The
INFORMATION_SCHEMA EVENTS Table”, and
Section 188.8.131.52, “
SHOW EVENTS Syntax”, for more information.
The feature implementation resides on the slave in a renewable state so that if the master fails, the slave can be used as the master without loss of event processing.
To determine whether there are any scheduled events on a MySQL
server that were created on a different server (that was acting
as a replication master), query the
INFORMATION_SCHEMA.EVENTS table in
a manner similar to what is shown here:
SELECT EVENT_SCHEMA, EVENT_NAME FROM INFORMATION_SCHEMA.EVENTS WHERE STATUS = 'SLAVESIDE_DISABLED';
Alternatively, you can use the
EVENTS statement, like this:
SHOW EVENTS WHERE STATUS = 'SLAVESIDE_DISABLED';
When promoting a replication slave having such events to a
replication master, you must enable each event using
event_name is the name of the event.
If more than one master was involved in creating events on this
slave, and you wish to identify events that were created only on
a given master having the server ID
master_id, modify the previous query
EVENTS table to include the
ORIGINATOR column, as shown here:
SELECT EVENT_SCHEMA, EVENT_NAME, ORIGINATOR FROM INFORMATION_SCHEMA.EVENTS WHERE STATUS = 'SLAVESIDE_DISABLED' AND ORIGINATOR = '
You can employ
ORIGINATOR with the
SHOW EVENTS statement in a
SHOW EVENTS WHERE STATUS = 'SLAVESIDE_DISABLED' AND ORIGINATOR = '
Before enabling events that were replicated from the master, you
should disable the MySQL Event Scheduler on the slave (using a
statement such as
SET GLOBAL event_scheduler =
OFF;), run any necessary
EVENT statements, restart the server, then re-enable
the Event Scheduler on the slave afterward (using a statement
SET GLOBAL event_scheduler = ON;)-
If you later demote the new master back to being a replication
slave, you must disable manually all events enabled by the
ALTER EVENT statements. You can
do this by storing in a separate table the event names from the
SELECT statement shown
previously, or using
statements to rename the events with a common prefix such as
replicated_ to identify them.
If you rename the events, then when demoting this server back to
being a replication slave, you can identify the events by
EVENTS table, as shown
SELECT CONCAT(EVENT_SCHEMA, '.', EVENT_NAME) AS 'Db.Event' FROM INFORMATION_SCHEMA.EVENTS WHERE INSTR(EVENT_NAME, 'replicated_') = 1;
Copyright © 1997, 2014, Oracle and/or its affiliates. All rights reserved. Legal Notices