17.4.1.8. 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:

    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 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 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 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 event_name ENABLED, where event_name is the name of the event. You can do this with a stored procedure, such as the one shown here:

CREATE PROCEDURE enable_events()
BEGIN
  DECLARE done INT DEFAULT 0;
  DECLARE db, name VARCHAR(64);

  DECLARE cur CURSOR FOR
      SELECT EVENT_SCHEMA, EVENT_NAME
      FROM INFORMATION_SCHEMA.EVENTS
    WHERE STATUS = 'SLAVESIDE_DISABLED';

  DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;

  OPEN cur;

  REPEAT
    FETCH cur INTO db, name;
    IF NOT done THEN
      SET @str = CONCAT('ALTER EVENT ', db , '.', name, ' ENABLE');
      PREPARE stmt FROM @str;
      EXECUTE stmt;
      DEALLOCATE PREPARE stmt;
    END IF;
  UNTIL done END REPEAT;

  CLOSE cur;
END

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 MySQL 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 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. We can incorporate the latter action into a a new stored procedure that also accepts the master's server ID as a parameter:

CREATE PROCEDURE enable_events_from(IN server_id BIGINT)
BEGIN
  DECLARE done INT DEFAULT 0;
  DECLARE db, name VARCHAR(64);
  DECLARE orig BIGINT;

  DECLARE cur CURSOR FOR
      SELECT EVENT_SCHEMA, EVENT_NAME, ORIGINATOR
      FROM INFORMATION_SCHEMA.EVENTS
      WHERE STATUS = 'SLAVESIDE_DISABLED';

  DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;

  OPEN cur;

  REPEAT
    FETCH cur INTO db, name, orig;
    IF NOT done THEN
      IF orig = server_id THEN
        SET @str = CONCAT('ALTER EVENT ', db , '.', name, 
                          ' RENAME TO ', CONCAT(db, '.replicated_', name), 
                          ' ENABLE');
        PREPARE stmt FROM @str;
        EXECUTE stmt;
        DEALLOCATE PREPARE stmt;
      END IF;
    END IF;
  UNTIL done END REPEAT;

  CLOSE cur;
END

When demoting this server back to being a replication slave, you can identify these renamed 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;

You can rename and disable these events using a stored procedure like this one:

CREATE PROCEDURE disable_replicated_events()
BEGIN
  DECLARE done INT DEFAULT 0;
  DECLARE db, name VARCHAR(64);

  DECLARE cur CURSOR FOR
      SELECT EVENT_SCHEMA, EVENT_NAME
      FROM INFORMATION_SCHEMA.EVENTS
      WHERE INSTR(EVENT_NAME, 'replicated_') = 1;

  DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;

  OPEN cur;

  REPEAT
    FETCH cur INTO db, name;
    IF NOT done THEN
      SET @str = CONCAT('ALTER EVENT ', db , '.', name, 
                        ' RENAME TO ', db, '.' REPLACE(name, 'replicated_', ''), 
                        ' SLAVESIDE_DISABLED');
      PREPARE stmt FROM @str;
      EXECUTE stmt;
      DEALLOCATE PREPARE stmt;
    END IF;
  UNTIL done END REPEAT;

  CLOSE cur;
END
Copyright © 2010-2024 Platon Technologies, s.r.o.           Home | Man pages | tLDP | Documents | Utilities | About
Design by styleshout