maxscale在mariadb主从切换后如何处理event的状态-handle_events

Posted 2022-06-23 雅冰石

一 handle_events介绍

默认情况下，此设置处于启用状态。如果启用，监视器将连续查询服务器以查找已启用的计划事件，并在执行群集操作时使用此信息，根据需要启用和禁用事件。

当服务器降级时，任何状态为“ENABLED”的事件都将设置为“SLAVESIDE_DISABLED”。当服务器升级为主服务器时，如果上次成功查询旧的主服务器时也启用了相同的事件，则“SLAVESIDE_DISABLED”或“DISABLED”的事件将设置为“ENABLED”。如果事件具有相同的架构和名称，则认为它们是相同的。当独立服务器重新加入集群时，其事件也会被禁用，因为它现在是从服务器。

监视器不会启用或禁用事件计划程序本身(event scheduler)。对于要在新主服务器上运行的事件，管理员应启用调度程序。建议在服务器配置文件中启用它。

在故障切换场景中，高频率运行的事件可能会导致复制中断。如果发生故障转移的旧主库重新启动，如果在服务器配置文件中设置了event_scheduler = 1，则其事件计划程序将打开。它的事件还将记住其“已启用”状态，并按计划运行。这可能发生在监视器重新加入服务器并禁用事件之前。这应该仅适用于运行频率高于监视间隔的事件或服务器重新启动后立即运行的事件。

对应的官网介绍：

This setting is on by default. If enabled, the monitor continuously queries the servers for enabled scheduled events and uses this information when performing cluster operations, enabling and disabling events as appropriate.

When a server is being demoted, any events with "ENABLED" status are set to "SLAVESIDE_DISABLED". When a server is being promoted to master, events that are either "SLAVESIDE_DISABLED" or "DISABLED" are set to "ENABLED" if the same event was also enabled on the old master server last time it was successfully queried. Events are considered identical if they have the same schema and name. When a standalone server is rejoined to the cluster, its events are also disabled since it is now a slave.

The monitor does not check whether the same events were disabled and enabled during a switchover or failover/rejoin. All events that meet the criteria above are altered.

The monitor does not enable or disable the event scheduler itself. For the events to run on the new master server, the scheduler should be enabled by the admin. Enabling it in the server configuration file is recommended.

Events running at high frequency may cause replication to break in a failover scenario. If an old master which was failed over restarts, its event scheduler will be on if set in the server configuration file. Its events will also remember their "ENABLED"-status and run when scheduled. This may happen before the monitor rejoins the server and disables the events. This should only be an issue for events running more often than the monitor interval or events that run immediately after the server has restarted.

二 需要确保maxscale配置文件里配的监控账号有event权限

我们一开始搭建的maxscale里没给监控账号授event权限，结果导致maxscale在主库宕机后，没有将新主库事件的状态(可以这样查：SELECT NAME,STATUS FROM mysql.event)变为enable，在原主库启动后，也没将其状态降级为SLAVESIDE_DISABLED，导致事件在原主库上执行，主从数据不一致，而且原主库也因为gtid比现主库大，无法变为现主库的从库。

针对已发生的这个问题，需要做以下三步

① 给监控账号授grant权限：

GRANT EVENT ON *.* TO 'MonitorUser';

② 重启maxscale

因为授权只对新建的会话生效，发生过主从切换的mariadb，复制使用了监控账号：

/*

在show slave status \\G结果,可以看到Master_User为maxscale监控账号，而非最初配置主从复制时的复制账号。

*/

因此需要重启maxscale，使授权生效

③ 如果线上已经部署了event，且当前主库不是最初的主库，需要触发一次主从切换

示例，192.168.144.248是主库，192.168.144.249是从库。

假如生产环境在我们授event权限之前，已经部署了event事件，而且发生了一次主从切换，249变为了新主库（但event状态依然是SLAVESIDE_DISABLED），248变为了从库（但event状态仍然是enabled），此时依然是有问题的，所以需要手动切换下主从，确保主库上事件的状态是enabled，从库上的状态是SLAVESIDE_DISABLED