MySQL MGR源码分析2 - 从start group_replication看MGR代码框架

此文已由作者温正湖授权网易云社区发布。

欢迎访问网易云社区，了解更多网易技术产品运营经验。

上一篇我们从方案层面讲解了MGR的成员管理和故障恢复。本篇从源码层面捋一捋，通过本篇介绍，除了能够了解如何将一个节点加入到group中，也可以了解在这个过程中，节点是如何进行分布式通信模块进行初始化，上层如何响应底层上发的消息，事务进入MGR后是如何通过pipeline一步步执行的，等待。

start group_replication处理逻辑

该命令用于将一个正在运行且已经install了group_replication.so插件的mysqld加入到group中。又可以根据是否设置了group_replication_bootstrap_group来分为创建一个新的group或加入一个已有的group。start group_replication对应的实现函数为plugin_group_replication_start，其做些基本的检查后交由initialize_plugin_and_join()来执行节点加入group的任务，下图为该函数的主要执行流程。

下面我们注意对其9个阶段进行逐一分析：

1、调用Gcs_operations::initialize()来创建gcs_interface对象并设置gcs日志系统；

2、根据用户配置的MGR参数设置GCS，其中最重要的逻辑是调用Gcs_xcom_interface::initialize_xcom()来进行MGR目前唯一执行的gcs实现xcom的初始化，该函数详见后续小节描述。

3、设置本节点的MGR成员管理对象，包括本节点信息维护对象local_member_info和集群信息维护对象group_member_mgr，此时group_member_mgr还只有本地节点的信息。

4、initialize_recovery_module()函数初始化节点的MGR recovery模块，包括创建Recovery_module对象，为其设置节点上线策略（认证完上线还是回放完上线），设置全局故障恢复节点donor节点连接失败重试的次数和失败重连的时间间隔。Recovery_module模块在start group_replication命令返回后，负责将节点从恢复中变为在线状态。

5、接下来调用configure_and_start_applier_module()函数配置和启动节点的MGR Applier_module模块，该模块是MGR的核心模块之一，用于对通过xcom进入该节点的包括用户事务数据包（package）在内的众多行为（action）/事件（event）进行分发、认证和执行。

首先创建一个Applier_module对象，并将其赋予Recovery_module模块；接着对Applier_module对象进行初始化，包括创建用于缓存等待处理的消息的队列incoming，初始化模块的处理机制pipeline；最后启动一个新的线程，并制定处理函数applier_thread_handle()，用于具体处理这些入队的消息。MGR使用pipeline管道的方式处理每个消息，pipeline设置和初始化详见后续小节分析。

6、在单主模式下，调用initialize_asynchronous_channels_observer()进行节点异步复制通道的操作行为监听。主要监听行为是io thread和sql thread启动操作。原因是在单主模式下，只有primary节点能接收外部写请求，所以需要禁止MGR单主模式的secondary节点启动非MGR的异步复制和回放Relay log的通道。而多主模式下各节点均可写，不存在该限制。

7、下一步initialize_group_partition_handler()用于初始化MGR的网络分区处理对象group_partition_handler。应对MGR中的节点因为网络问题导致相互间无法进行正常的通信。当有节点无法连上其他节点时，就会启动handler->partition_thread_handler()网络分区处理线程，若在超时时间内（）网络无法恢复，则会进行网络分区处理，包括退出group并rollback已进入MGR的事务等。

8、调用start_group_communication()启动节点与group中其他节点的通信是及其重要的步骤。直接决定了该节点是否能够正常加入group。

该函数首先设置节点的自增列的自增区间和自增初始值。然后初始化group集群视图变化状态设置监听对象view_change_notifier，该notifier会设置和监控视图变化情况并作出相应处理，初始化非常重要的events_handler，该handler是向gcs注册的事件回调接口，用于处理gcs（paxos）返回的各种消息/事件，包括用户事务数据包、group变化的控制包等。接着，view_change_notifier设置view_changing变量，表示正式进入视图切换阶段（当view_changing重新变为false时，start group_replication即可返回）。最后调用Gcs_operations::join()函数执行将该节点加入group的操作，该函数详见后续小节描述。

9、以上就是start group_replication命令所要执行的所有操作，在完成这些操作后，initialize_plugin_and_join()调用view_change_notifier->wait_for_view_modification()来等待view_changing变为false，之命令返回。若返回值非零，则意味着加入失败，需要进行操作回滚。若返回值为零，则节点进入故障恢复流程，最终将节点设置为在线状态。

Gcs_xcom_interface::initialize_xcom()

initialize_xcom()用于初始化节点的xcom实例。但此时该实例仍未运行和加入的group。

如上图所示，该函数主要是初始化xcom实例的group信息及相关对象，设置将该xcom加入group所需的种子节点，注册各种xcom消息的回调处理函数，创建xcom的各种操作接口xcom_proxy，最后创建Gcs_xcom_engine对象，并调用Gcs_xcom_engine::initialize()来启动节点的xcom处理引擎，xcom引擎通过独立线程的处理函数process_notification_thread来调用2.2.1.3.3设置的回调函数处理各种xcom消息。process_notification_thread的处理逻辑如下所示：

paxos消息接收和执行

上面我们说了m_notification_queue消息的执行框架，那么这些消息如何加入m_notification_queue队列呢，详见下图例子：

deliver_to_app是MGR最底层paxos将已达成一致性的消息发送给上层的主要接口之一，其调用在该类消息处理函数xcom_receive_data()进行处理，处理操作很简单，经创建一个Data_notification对象，参数中指定了具体的消息处理函数，最后将其push到我们上面所述的m_notification_queue队列。我们进一步看看do_cb_xcom_receive_data()如何处理该消息：

首先，将从paxos接收到的消息进行pipeline处理（注意跟Applier_module的pipeline相区分），目前pipeline仅可注册一个stage，即Gcs_message_stage_lz4，用于对paxos消息进行压缩。可通过参数group_replication_compression_threshold来设置进行消息压缩的阈值。

接着，若消息类型为进行视图切换时产生的成员状态交换消息（CT_INTERNAL_STATE_EXCHANGE），调用process_control_message()函数进行处理。否则，判断是否正在进行视图切换，若是，则暂时buffer住这些消息，等到视图完成切换后（即成员加入group后）再处理。否则，调用上层为每种消息注册的回调函数on_message_received()进行处理。

下面，我们简要介绍process_control_message()和on_message_received()：

on_view_changed是各个节点对视图切换的响应，是视图切换关键性的函数，包含了对加入节点、退出节点的处理，处理完成后还会判断是否需要发起选主，如果是节点加群那么还会调用故障恢复模块recovery_module函数start_recovery()。其处理流程如下：

on_message_received()是个消息分发枢纽，其操作如下：

如上图所示，根据消息类型的不同，分别调用不同的处理函数，其中对于单主模式新primary完成relay log回放后的消息和事务性消息（事务和视图数据包）均进入到applier_module的incoming队列按顺序执行。其他三种消息分别是用于节点间进行事务执行状态周期性同步的CT_PIPELINE_STATS_MEMBER_MESSAGE消息，该消息是performance_schema.replication_group_member_stats和replication_group_members的主要数据来源。会触发节点进入流控模式。CT_RECOVERY_MESSAGE消息用于在节点完成故障恢复后将自己设置为在线状态前给group发送的广播消息，确保其他节点及时感知节点状态变化。CT_CERTIFICATION_MESSAGE是周期性发送的，用于对applier_module模块的冲突检测数据库进行无用信息purge的消息。

Applier_module的pipeline实现

MGR使用pipeline管道的方式处理每个消息，pipeline设置和初始化详见第5小节分析。目前官方设置了3个pipeline处理器（handler），分别是CATALOGING_HANDLER、CERTIFICATION_HANDLER和SQL_THREAD_APPLICATION_HANDLER，其中CATALOGING_HANDLER用于待处理的事件进行分类，主要通过判断事件类型是否为binary_log::TRANSACTION_CONTEXT_EVENT来设置事务开始的标志，并判断是否为SINGLE_VIEW_EVENT来标识处理视图变更事件。CERTIFICATION_HANDLER是最核心的pipeline处理器，在各个节点采用相同的规则独立进行事务认证，包括认证模块初始化和销毁、事务快照版本解析、对事务进行冲突检测和在视图变更的时候初始化冲突检测数据库等。

SQL_THREAD_APPLICATION_HANDLER用于并行回放通过了认证的异地事务，更新本地的数据库版本。3个pipeline的汇总信息如下图所示：

Gcs_operations::join()

该接口用于在start group_replication时将节点加入group。具体流程如下：

首先进行通信（gcs_communication）和控制（gcs_control）接口初始化，确保从gcs层发送上来的各种消息能够被正确执行。最后调用Gcs_xcom_control::join()来执行最终的节点入群操作，该函数判断是创建group还是加入group场景，并在Gcs_xcom_control::do_join()中进行对应处理，do_join在Gcs_xcom_interface::initialize_xcom()的基础上完成最后的加入操作，流程如下：

先创建m_xcom_thread线程，通过proxy->xcom_init()进行最后的初始化，让xcom实例进入运行状态；在确保xcom实例通信正常的情况下，分别调用proxy->xcom_client_boot()或proxy->xcom_client_add_node()创建一个group或加入已存在的group。

梳理总结

上面就是start group_replication命令的全部操作。经过上面介绍后，还有2个大疑问没有解释清楚：

1、该命令在什么时候返回？

上面我们只是说在view_changing为false的时候返回，那么该变量什么时候会变为false呢，首先需要明确的是在前述的Plugin_gcs_events_handler::on_view_changed()函数中设置，对于执行该命令的节点，会在Plugin_gcs_events_handler::handle_joining_members()函数中调用view_change_notifier->end_view_modification()设置，并进行广播：

2、在介绍process_control_message()时我们知道该函数是接收了CT_INTERNAL_STATE_EXCHANGE消息后调用执行的。那么该消息是在什么场景下发出的？

下面我们从源头开始进行简单介绍：

detector_task是paxos层的一个定时任务机制，用于发现group的成员变化情况，并进行相应的处理。对于我们所述的场景，有一个新的节点加入paxos group中，所以会触发该任务发送一个view_msg消息。最终调用do_cb_xcom_receive_global_view进行处理。具体逻辑为：

该函数会获取自己节点的状态信息get_exchangeable_data()，并使用Gcs_xcom_state_exchange::broadcast_state()来广播一个CT_INTERNAL_STATE_EXCHANGE。

网易云免费体验馆，0成本体验20+款云产品！

更多网易技术、产品、运营经验分享请点击。

相关文章：
【推荐】 干货|盘点国内真正的大数据分析产品
【推荐】 一步一步学习JNI