MySQL: 8.0通过信号关闭的日志和MGR donor节点的选择

最近也没有学习什么，这里就分享2个我觉得还有点用的小知识吧，仅供参考。

一、MySQL 8.0 收到信号关闭数据的特殊日志

以往我们在5.7关闭数据的时候，只要是正常关闭数据库，输出几乎都是一样的，因此很难判断到底是kill mysqldpid还是shutdown数据库指令。这一点到了8.0有了改变，当然这个改变很小，但是在处理问题的时候我却用到了，并且在history中确实找到了kill命令。

我们先来看8.0信号处理函数在收到了，也就是SIGTERM（15）和SIGQUIT（3）信号后正常关闭数据库，会有什么特殊的输出如下：

MySQL: 8.0通过信号关闭的日志和MGR donor节点的选择 — image.png

也就是在进行正常关闭流程的时候，在signal_hand函数，也就是信号处理函数里面有特别的输出，当然这本身很简单，但是我们运维处理问题的时候就可以通过这个输出判定，到底是发了shutdown命令还是kill 发的信号关闭的数据，默认的kill 命令就是SIGTERM（15）号信号，日志如下：

如果是shutdown则为如下：

当然如果是kill -9 啥也看不到了，信号不能被捕获，更不可能有日志，典型的数据库OOM了，这个时候可以查看OS日志。反正这点改进不能说是大型真香现场，但是还是比较有用。

二、MGR donor节点选择问题

这个也是朋友问到的一个问题，一直知道大概是随机选择的，同时也咨询了一下叶老师。但是还是要验一下代码，实际上代码就是：

Recovery_state_transfer::establish_donor_connection
  ->build_donor_list
  ->initialize_donor_connection

这里涉及到几个参数：

group_replication_advertise_recovery_endpoints：如果这个参数设置了，donor节点的选择就不完全是随机的，而是和这个参数的设置有关。但是呢，一般都没设置，因为默认没有设置，也不会去改它。
group_replication_recovery_reconnect_interval：如果存在多个donor节点，会每次随机选择一个出来进行连接，如果连接失败还会连接下一个donor节点，如果全部都失败，再来循环一次，直到达到这个参数设置的次数。
group_replication_allow_local_lower_version_join：是否允许当前节点选择版本更高的节点作为donor节点，也就是加入节点版本低于donor节点，默认为OFF

最终要随机选择donor节点，最重要的算法就是如下：

  if (suitable_donors.size() > 1) { //如果候选donors大于2 随机洗牌 donor节点的候选
    std::random_device rng;
    std::mt19937 urng(rng());
    std::shuffle(suitable_donors.begin(), suitable_donors.end(), urng);
  }

明显看到随机算法，通过随机算法来打乱容器suitable_donors中的元素，其中每个元素就是一个候选的donor节点，当然donor节点有一些限制：