To determine whether there are any scheduled events on a MySQL server that were created on a different server (that was acting as a source), 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 having such events to a source, you must enable each event using ALTER EVENT event_name  ENABLE , where event_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: 

## 17.5.1.17 Replication of JSON Documents 

SELECT CONCAT(EVENT_SCHEMA, ’.’, EVENT_NAME) AS ’Db.Event’ FROM INFORMATION_SCHEMA.EVENTS WHERE INSTR(EVENT_NAME, ’replicated_’) = 1; 

Before MySQL 8.0, an update to a JSON column was always written to the binary log as the complete document. In MySQL 8.0, it is possible to log partial updates to JSON documents (see Partial Updates of JSON Values), which is more efficient. The logging behavior depends on the format used, as described here: 

Statement-based replication.  JSON partial updates are always logged as partial updates. This cannot be disabled when using statement-based logging. 

Row-based replication.  JSON partial updates are not logged as such by default, but instead are logged as complete documents. To enable logging of partial updates, set 

