So there are five problems here. I think to fix any one of them needs some efforts because it can't be fixed in wsrep patch only but needs some changes in MySQL code too.
1. "ONE TIME" events are not dropped on slave nodes after expiring on master (event creator node)
This is because when event scheduler drop one-time event, it does not call TOI to trigger replication.
2. After doing ALTER EVENT, slave nodes end up with empty Definer "@"
It's because wsrep_TOI_begin does not save 'definer' information into trx hold by galera (more precisely, Query_log_event::write does not pass 'definer' into IO_CACHE)
3. After SST from master node (the one where event is ENABLED) - you will end up with the event enabled on two nodes, hence it's now being executed twice.
This can be a feature(?). It needs to be well documented. However to my mind, it can be solved by comparing event's originator with server_id. if not equal, then change its status to 'SLAVESIDE_DISABLED'
4. If event owner node is re-created using SST, all the nodes have the event now in "SLAVESIDE_DISABLED" state, hence manual action is needed to re-enable the event on one of the nodes.
This can be a feature too(?). It needs to be well documented. However compared to previous problem, It much harder to solve. Because you can not set event's status to 'ENABLE' in master simply.
5. MySQL 5.5 loses event if this event is SLAVESIDE_DISABLED and replicated from slaves.
So there are five problems here. I think to fix any one of them needs some efforts because it can't be fixed in wsrep patch only but needs some changes in MySQL code too.
1. "ONE TIME" events are not dropped on slave nodes after expiring on master (event creator node)
This is because when event scheduler drop one-time event, it does not call TOI to trigger replication.
2. After doing ALTER EVENT, slave nodes end up with empty Definer "@" event:: write does not pass 'definer' into IO_CACHE)
It's because wsrep_TOI_begin does not save 'definer' information into trx hold by galera (more precisely, Query_log_
3. After SST from master node (the one where event is ENABLED) - you will end up with the event enabled on two nodes, hence it's now being executed twice. DISABLED'
This can be a feature(?). It needs to be well documented. However to my mind, it can be solved by comparing event's originator with server_id. if not equal, then change its status to 'SLAVESIDE_
4. If event owner node is re-created using SST, all the nodes have the event now in "SLAVESIDE_ DISABLED" state, hence manual action is needed to re-enable the event on one of the nodes.
This can be a feature too(?). It needs to be well documented. However compared to previous problem, It much harder to solve. Because you can not set event's status to 'ENABLE' in master simply.
5. MySQL 5.5 loses event if this event is SLAVESIDE_DISABLED and replicated from slaves.