Replication of invoked features such as user-defined functions (UDFs) and stored programs (stored functions and procedures, triggers, and events) was re-implemented in MySQL 5.1.18 to provide 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 may not be safe to log in statement format. (Prior to MySQL 5.1.36, this was Statement is not safe to log in statement format — see Bug#42415.) 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 slave
regardless of the state specified (this does not
apply to DROP EVENT
).
The master on which the event was created is
identified on the slave by its server ID. The
ORIGINATOR
column in
INFORMATION_SCHEMA.EVENTS
and the originator
column in
mysql.event
were added to these
tables in MySQL 5.1.18 to store this information.
(See Section 20.20, “The INFORMATION_SCHEMA EVENTS
Table”, and
Section 12.4.5.19, “SHOW EVENTS
Syntax”.)
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), use SHOW
EVENTS
, like this:
SHOW EVENTS WHERE STATUS = 'SLAVESIDE_DISABLED';
Alternatively, you might wish to query the
INFORMATION_SCHEMA.EVENTS
table as
shown here:
SELECT EVENT_SCHEMA, EVENT_NAME, ORIGINATOR FROM INFORMATION_SCHEMA.EVENTS WHERE STATUS = 'SLAVESIDE_DISABLED';
When promoting a replication slave having such events to a replication master, use the following query to enable the events:
UPDATE mysql.event SET STATUS = 'ENABLED' WHERE STATUS = 'SLAVESIDE_DISABLED';
If more than one master was involved in creating events on this
slave, and you wish to enable events that were created only on a
given master having the server ID
master_id
, use the following query
instead:
UPDATE mysql.event
SET STATUS = 'ENABLED'
WHERE ORIGINATOR = master_id
AND STATUS = 'SLAVESIDE_DISABLED';
Before executing either of the previous two
UPDATE
statements, you should
disable the Event Scheduler on the slave (using SET
GLOBAL event_scheduler = OFF;
), run the
UPDATE
, restart the server,
then re-enable the Event Scheduler afterwards (using
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
UPDATE
statement. You can do
this by storing in a separate table the event names from the
SELECT
statement shown
previously, or using an UPDATE
statement to rename the events with a common prefix to
identify them, as shown in this example:
UPDATE mysql.event SET name = CONCAT('replicated_', name) WHERE status = 'SLAVESIDE_DISABLED';
When demoting this server back to being a replication slave, you can then rename and disable the events like this:
UPDATE mysql.event SET name = REPLACE(name, 'replicated_', ''), status = 'SLAVESIDE_DISABLED' WHERE INSTR(name, 'replicated_') = 1;
User Comments
Add your own comment.