Events and Replication, part 1
MySQL events have been in GA for 2 years. Events are not used as much as I would like -- often organizations will have cron jobs or scheduled tasks to perform ETL, maintenance and small aggregation tasks. For example, a website that shows how many users are logged in might update a "cache table" with a count of active sessions every 5 minutes.
Events are great because they are a part of the database. They only run when the database is running, and they are backed up with the database. There is no need to store a password in a file or in a cron listing.
Events and replication can be a tricky matter. Events can change data, and data changes are replicated. In the example of an event that updates a table with a count of active sessions every 5 minutes, let's assume that the event itself would run on a primary master (write) server. All slaves (including a secondary master) would receive the table update.
The tricky part is that CREATE EVENT statements are replicated. There are three ways to avoid an event that changes data running on more than just the master:
0) Do not replicate the CREATE EVENT, or replicate it but then delete the event on any slaves. I do not like this approach because if you promote one of the slaves to be a master, the event will not be in place.
1) Replicate the CREATE EVENT, knowing that the SLAVESIDE_DISABLED bit will be set even if you do not specify DISABLE ON SLAVE in the CREATE statement. If you promote a slave to be a master, all you need to do is ALTER EVENT event_name ENABLED for each event that needs to be turned on. This is the method I prefer, even though it still requires knowledge to turn on the events when a slave is promoted, and turn off events on the old master.
2) Replicate the CREATE EVENT, and enable the event right away, but set the event scheduler off. This is easier if there are lots of events, because all that needs to be done when a slave is promoted to a master is:
mysql> SET GLOBAL event_scheduler=ON;
However, this means that you cannot have any events running on the slave itself - it is either all the events running, or not.
Part 2 will discuss some specific issues I have run into with events and replication.
Archives
- May 2013
- March 2013
- February 2013
- January 2013
- December 2012
- November 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- October 2010
- September 2010
- November 2009
- March 2008
- November 2007
- October 2007


Comments
What makes it complicated in the event case is that the event on the slave is only executed if the slave is running. If the slave is down for an hour and comes back online, it misses all events from that time whereas all trigger executions are done as the statements invoking the triggers are replicated. So handling events like triggers is also not the final solution.
The way events are replicated is the other way round to the way triggers are replicated. With triggers, only the trigger itself is replicated, but the actions the trigger make do not get replicated.Thus, a slave would just have the same trigger activated, and by determinism ,reach the same result as the master.It's too bad things do not work the same for events, where both event definition *and* event statements get replicated.I'm not sure which solution is more correct, but I just wish it would be consistent.
Reply