Replication of Invoked Features
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:
CREATE EVENT
ALTER EVENT
DROP EVENT
CREATE PROCEDURE
DROP PROCEDURE
CREATE FUNCTION
DROP FUNCTION
CREATE TRIGGER
DROP TRIGGER
However, the effects of features created, modified, or dropped using these statements are replicated using row-based replication.Note
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 MariaDB 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
andALTER EVENT
:- The status of the event is set to
SLAVESIDE_DISABLED
on the slave regardless of the state specified (this does not apply toDROP EVENT
). - The master on which the event was created is identified on the slave by its server ID. The
ORIGINATOR
column inINFORMATION_SCHEMA.EVENTS
and theoriginator
column inmysql.event
store this information. See , "TheINFORMATION_SCHEMA EVENTS
Table", and , "SHOW EVENTS
Syntax", for more information.
- The status of the event is set to
- 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 MariaDB 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 SHOW 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 ALTER EVENT
, where event_name
ENABLEDevent_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 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 = 'master_id
'
You can employ ORIGINATOR
with the SHOW EVENTS
statement in a similar fashion:
SHOW EVENTS
WHERE STATUS = 'SLAVESIDE_DISABLED'
AND ORIGINATOR = 'master_id
'
Before enabling events that were replicated from the master, you should disable the MariaDB Event Scheduler on the slave (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 slave afterward (using a statement such as 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 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 replication slave, you can identify the events by querying the EVENTS
table, as shown here: