MySQL 5.6 Reference Manual Including MySQL NDB Cluster 7.3-7.4 Reference Guide
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.
In the case of CREATE EVENT
and ALTER EVENT
:
The status of the event is set to
SLAVESIDE_DISABLED
on the replica
regardless of the state specified (this does not apply
to DROP EVENT
).
The source on which the event was created is identified
on the replica by its server ID. The
ORIGINATOR
column in
INFORMATION_SCHEMA.EVENTS
and the originator
column in
mysql.event
store this information.
See Section 21.8, “The INFORMATION_SCHEMA EVENTS Table”,
and Section 13.7.5.19, “SHOW EVENTS Statement”, for more information.
The feature implementation resides on the replica in a renewable state so that if the source fails, the replica can be used as the source 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 source server), 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 SHOW
EVENTS
statement, like this:
SHOW EVENTS WHERE STATUS = 'SLAVESIDE_DISABLED';
When promoting a replica that has such events to a replication
source server, you must enable each event using
ALTER EVENT
, where
event_name
ENABLEevent_name
is the name of the event.
If more than one source was involved in creating events on this
replica, and you wish to identify events that were created only
on a given source having the server ID
source_id
, modify the previous query
on the 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 = 'source_id
'
You can employ ORIGINATOR
with the
SHOW EVENTS
statement in a
similar fashion:
SHOW EVENTS
WHERE STATUS = 'SLAVESIDE_DISABLED'
AND ORIGINATOR = 'source_id
'
Before enabling events that were replicated from the source, you
should disable the MySQL Event Scheduler on the replica (using a
statement such as SET GLOBAL event_scheduler =
OFF;
), run any necessary ALTER
EVENT
statements, restart the server, then re-enable
the Event Scheduler on the replica afterward (using a statement
such as SET GLOBAL event_scheduler = ON;
)-
If you later demote the new source back to being a replica, 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 ALTER EVENT
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 replica, you can identify the events by querying the
EVENTS
table, as shown here:
SELECT CONCAT(EVENT_SCHEMA, '.', EVENT_NAME) AS 'Db.Event' FROM INFORMATION_SCHEMA.EVENTS WHERE INSTR(EVENT_NAME, 'replicated_') = 1;