最近也没有深入学习什么,这里就分享2个我觉得还有点用的小知识点吧,仅供按参考。
一、MySQL 8.0 收到信号关闭数据的特殊日志
以往我们在5.7关闭数据的时候,只要是正常关闭数据库,输出几乎都是一样的,因此很难判断到底是kill mysqldpid还是shutdown数据库指令。这一点到了8.0有了改变,当然这个改变很小,但是在处理问题的时候我却用到了,并且在history中确实找到了kill命令。
我们先来看8.0信号处理函数在收到了,也就是SIGTERM(15)和SIGQUIT(3)号信号后正常关闭数据库,会有什么特殊的输出如下:

也就是在进行正常关闭流程的时候,在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节点,也就是加入节点版本更低,默认为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节点有一些限制:
- 必须是online节点。
- group_replication_allow_local_lower_version_join默认为off,因此不允许高版本的donor节点,也就是加入节点版本更低。
网友评论