[MDEV-21758] Events switched randomly to SLAVESIDE_DISABLED - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Blocker
Resolution: Fixed
Affects Version/s: 10.3.22, 10.2(EOL), 10.3(EOL), 10.4(EOL)
Fix Version/s: 10.2.32, 10.3.23, 10.4.13, 10.5.2
Component/s: Events, Server
Labels:
- regression
Environment:
Debian Buster, 64bit

Description

After upgrade from 10.3.18 to 10.3.22, events in all databases probably randomly switched it's status to 'SLAVESIDE_DISABLED' (statuses before this happened were ENABLED and some events were DISABLED). I'm not using master-slave configuration at all, it is single server.

Attachments

Issue Links

is caused by

MDEV-20511 Galera replication of events is not consistent

Closed

relates to

MDEV-21896 Document events that may have been disabled after upgrade

Closed

Activity

Ascending order - Click to sort in descending order

Elena Stepanova added a comment - 2020-03-07 18:51

Thanks for the report.

The regression was introduced by this commit:

commit 0fd5b11eb05be8e8e996b26d845aae3b863448d3

Author: Jan Lindström <jan.lindstrom@mariadb.com>

Date:   Fri Sep 6 14:54:22 2019 +0300

    MDEV-20511: Galera replication of events is not consistent

    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. It can be solved by comparing event's originator with server_id. if not equal, then change its status to 'SLAVESIDE_DISABLED'

The change makes all events which were created by a server with a different server_id to get disabled. Moreover, they remain disabled even if the server is later started with the initial server_id again.

create event ev on schedule every 1 minute do set @a= 1;

select name, originator, status from mysql.event;

--let $server_id= `SELECT @@global.server_id`

--echo #

--echo # Restarting server with server_id=100

--echo #

--let $restart_parameters= --server-id=100

--source include/restart_mysqld.inc

select @@global.server_id;

select name, originator, status from mysql.event;

--eval set global server_id= $server_id

--echo #

--echo # Restarting server with the original server_id=$server_id

--echo #

--let $restart_parameters=

--source include/restart_mysqld.inc

select @@global.server_id;

select name, originator, status from mysql.event;

# Cleanup

drop event ev;

10.2 8382f106
select name, originator, status from mysql.event;
name originator status
ev 1 ENABLED
#
# Restarting server with server_id=100
#
select @@global.server_id;
@@global.server_id
100
select name, originator, status from mysql.event;
name originator status
ev 1 SLAVESIDE_DISABLED
set global server_id= 1;
#
# Restarting server with the original server_id=1
#
select @@global.server_id;
@@global.server_id
1
select name, originator, status from mysql.event;
name originator status
ev 1 SLAVESIDE_DISABLED

Elena Stepanova added a comment - 2020-03-07 18:51 Thanks for the report. The regression was introduced by this commit: commit 0fd5b11eb05be8e8e996b26d845aae3b863448d3 Author: Jan Lindström <jan.lindstrom@mariadb.com> Date: Fri Sep 6 14:54:22 2019 +0300 MDEV-20511: Galera replication of events is not consistent 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. It can be solved by comparing event's originator with server_id. if not equal, then change its status to 'SLAVESIDE_DISABLED' The change makes all events which were created by a server with a different server_id to get disabled. Moreover, they remain disabled even if the server is later started with the initial server_id again. create event ev on schedule every 1 minute do set @a= 1; select name , originator, status from mysql.event; --let $server_id= `SELECT @@global.server_id` --echo # --echo # Restarting server with server_id=100 --echo # --let $restart_parameters= --server-id=100 --source include/restart_mysqld.inc select @@ global .server_id; select name , originator, status from mysql.event; --eval set global server_id= $server_id --echo # --echo # Restarting server with the original server_id=$server_id --echo # --let $restart_parameters= --source include/restart_mysqld.inc select @@ global .server_id; select name , originator, status from mysql.event; # Cleanup drop event ev; 10.2 8382f106 select name , originator, status from mysql.event; name originator status ev 1 ENABLED # # Restarting server with server_id=100 # select @@ global .server_id; @@ global .server_id 100 select name , originator, status from mysql.event; name originator status ev 1 SLAVESIDE_DISABLED set global server_id= 1; # # Restarting server with the original server_id=1 # select @@ global .server_id; @@ global .server_id 1 select name , originator, status from mysql.event; name originator status ev 1 SLAVESIDE_DISABLED

Jan Lindström (Inactive) added a comment - 2020-03-09 06:01

If SST is done from a galera node that is also acting as MASTER newly synced node in galera eco-system will also copy-over the event state enabling duplicate event in galera eco-system. Identification uses naturally server_id so not sure what you can do here to (1) avoid enabling events that should not be enabled and (2) allow events that should be enabled to be enabled.

Jan Lindström (Inactive) added a comment - 2020-03-09 06:01 If SST is done from a galera node that is also acting as MASTER newly synced node in galera eco-system will also copy-over the event state enabling duplicate event in galera eco-system. Identification uses naturally server_id so not sure what you can do here to (1) avoid enabling events that should not be enabled and (2) allow events that should be enabled to be enabled.

Elena Stepanova added a comment - 2020-03-09 12:04

greenman, jacob.moorman,

We should probably add some sort of a note or a warning for users recommending them to check their events (at least if there was a chance that server_id of their server has changed at least once). As I understand, the fix makes sure that the events don't get disabled anymore, but those which did will remain disabled, so people would need to update them manually to re-enable.

Elena Stepanova added a comment - 2020-03-09 12:04 greenman , jacob.moorman , We should probably add some sort of a note or a warning for users recommending them to check their events (at least if there was a chance that server_id of their server has changed at least once). As I understand, the fix makes sure that the events don't get disabled anymore, but those which did will remain disabled, so people would need to update them manually to re-enable.

Ian Gilfillan added a comment - 2020-03-09 12:14

Thanks elenst, will document - ~~MDEV-21896~~

Ian Gilfillan added a comment - 2020-03-09 12:14 Thanks elenst , will document - MDEV-21896

People

Assignee:: Jan Lindström (Inactive)

Reporter:: azurit

Votes:: 0 Vote for this issue

Watchers:: 6 Start watching this issue

Dates

Created:: 2020-02-18 07:16

Updated:: 2020-03-09 12:14

Resolved:: 2020-03-09 11:58

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server