如何让 MGR 不从 Primary 节点克隆数据？

问题

MGR 中，新节点在加入时，为了与组内其它节点的数据保持一致，它会首先经历一个分布式恢复阶段。在这个阶段，新节点会随机选择组内一个节点（Donor）来同步差异数据。

在 MySQL 8.0.17 之前，同步的方式只有一种，即基于 Binlog 的异步复制，这种方式适用于差异数据较少或需要的 Binlog 都存在的场景。

从 MySQL 8.0.17 开始，新增了一种同步方式-克隆插件，克隆插件可用来进行物理备份恢复，这种方式适用于差异数据较多或需要的 Binlog 已被 purge 的场景。

克隆插件虽然极大提升了恢复的效率，但备份毕竟是一个 IO 密集型的操作，很容易影响备份实例的性能，所以，我们一般不希望克隆操作在 Primary 节点上执行。

但 Donor 的选择是随机的（后面会证明这一点），有没有办法让 MGR 不从 Primary 节点克隆数据呢？

本文主要包括以下几部分：

1. MGR 是如何执行克隆操作的？
2. 可以通过 clone_valid_donor_list 设置 Donor 么？
3. MGR 是如何选择 Donor 的？
4. MGR 克隆操作的实现逻辑。
5. group_replication_advertise_recovery_endpoints 的生效时机。

MGR 是如何执行克隆操作的？

起初还以为 MGR 执行克隆操作是调用克隆插件的一些内部接口。 但实际上，MGR 调用的就是CLONE INSTANCE命令。

登录后复制

// plugin/group_replication/src/sql_service/sql_service_command.cc
long Sql_service_commands::internal_clone_server(
    Sql_service_interface *sql_interface, void *var_args) {
  ...
  std::string query = "CLONE INSTANCE FROM \'";
  query.append(q_user);
  query.append("\'@\'");
  query.append(q_hostname);
  query.append("\':");
  query.append(std::get<1>(*variable_args));
  query.append(" IDENTIFIED BY \'");
  query.append(q_password);
  bool use_ssl = std::get<4>(*variable_args);
  if (use_ssl)
    query.append("\' REQUIRE SSL;");
  else
    query.append("\' REQUIRE NO SSL;");

  Sql_resultset rset;
  long srv_err = sql_interface->execute_query(query, &rset);
  ...
}

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.
• 11.
• 12.
• 13.
• 14.
• 15.
• 16.
• 17.
• 18.
• 19.
• 20.
• 21.
• 22.

既然调用的是 CLONE INSTANCE 命令，那是不是就可以通过 clone_valid_donor_list 参数来设置 Donor（被克隆实例）呢？

可以通过clone_valid_donor_list设置Donor么

不能。

在获取到 Donor 的 endpoint（端点，由 hostname 和 port 组成）后，MGR 会通过update_donor_list函数设置 clone_valid_donor_list。

clone_valid_donor_list 的值即为 Donor 的 endpoint。

所以，在启动组复制之前，在 mysql 客户端中显式设置 clone_valid_donor_list 是没有效果的。

登录后复制

// plugin/group_replication/src/plugin_handlers/remote_clone_handler.cc
int Remote_clone_handler::update_donor_list(
    Sql_service_command_interface *sql_command_interface, std::string &hostname,
    std::string &port) {
  std::string donor_list_query = " SET GLOBAL clone_valid_donor_list = \'";
  plugin_escape_string(hostname);
  donor_list_query.append(hostname);
  donor_list_query.append(":");
  donor_list_query.append(port);
  donor_list_query.append("\'");
  std::string error_msg;
  if (sql_command_interface->execute_query(donor_list_query, error_msg)) {
      ...
  }
  return 0;
}

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.
• 11.
• 12.
• 13.
• 14.
• 15.
• 16.

既然是先有 Donor，然后才会设置 clone_valid_donor_list，接下来我们看看 MGR 是如何选择 Donor 的？

MGR 是如何选择 Donor 的？

MGR 选择 Donor 可分为以下两步：

1. 首先，判断哪些节点适合当 Donor。满足条件的节点会放到一个动态数组（m_suitable_donors）中， 这个操作是在Remote_clone_handler::get_clone_donors函数中实现的。
2. 其次，循环遍历 m_suitable_donors 中的节点作为 Donor。如果第一个节点执行克隆操作失败，则会选择第二个节点，依次类推。

下面，我们看看Remote_clone_handler::get_clone_donors的实现细节。

登录后复制

void Remote_clone_handler::get_clone_donors(
    std::list<Group_member_info *> &suitable_donors) {
  // 获取集群所有节点的信息
  Group_member_info_list *all_members_info =
      group_member_mgr->get_all_members();
  if (all_members_info->size() > 1) {
    // 这里将原来的 all_members_info 打乱了，从这里可以看到 donor 是随机选择的。
    vector_random_shuffle(all_members_info);
  }

  for (Group_member_info *member : *all_members_info) {
    std::string m_uuid = member->get_uuid();
    bool is_online =
        member->get_recovery_status() == Group_member_info::MEMBER_ONLINE;
    bool not_self = m_uuid.compare(local_member_info->get_uuid());
    // 注意，这里只是比较了版本
    bool supports_clone =
        member->get_member_version().get_version() >=
            CLONE_GR_SUPPORT_VERSION &&
        member->get_member_version().get_version() ==
            local_member_info->get_member_version().get_version();

    if (is_online && not_self && supports_clone) {
      suitable_donors.push_back(member);
    } else {
      delete member;
    }
  }

  delete all_members_info;
}

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.
• 11.
• 12.
• 13.
• 14.
• 15.
• 16.
• 17.
• 18.
• 19.
• 20.
• 21.
• 22.
• 23.
• 24.
• 25.
• 26.
• 27.
• 28.
• 29.
• 30.
• 31.

该函数的处理流程如下：

1. 获取集群所有节点的信息，存储到 all_members_info 中。

   all_members_info 是个动态数组，数组中的元素是按照节点 server_uuid 从小到大的顺序依次存储的。

2. 通过vector_random_shuffle函数将 all_members_info 进行随机重排。

3. 选择 ONLINE 状态且版本大于等于 8.0.17 的节点添加到 suitable_donors 中。

   为什么是 8.0.17 呢，因为克隆插件是 MySQL 8.0.17 引入的。

   注意，这里只是比较了版本，没有判断克隆插件是否真正加载。

函数中的 suitable_donors 实际上就是 m_suitable_donors。

登录后复制

get_clone_donors(m_suitable_donors);

• 1.

基于前面的分析，可以看到，在 MGR 中，作为被克隆节点的 Donor 是随机选择的。

既然 Donor 的选择是随机的，想不从 Primary 节点克隆数据似乎是实现不了的。

分析到这里，问题似乎是无解了。

别急，接下来让我们分析下 MGR 克隆操作的实现逻辑。

MGR 克隆操作的实现逻辑

MGR 克隆操作是在Remote_clone_handler::clone_thread_handle函数中实现的。

登录后复制

// plugin/group_replication/src/plugin_handlers/remote_clone_handler.cc
[[noreturn]] void Remote_clone_handler::clone_thread_handle() {
  ...
  while (!empty_donor_list && !m_being_terminated) {
    stage_handler.set_completed_work(number_attempts);
    number_attempts++;

    std::string hostname("");
    std::string port("");
    std::vector<std::pair<std::string, uint>> endpoints;

    mysql_mutex_lock(&m_donor_list_lock);
    // m_suitable_donors 是所有符合 Donor 条件的节点
    empty_donor_list = m_suitable_donors.empty();
    if (!empty_donor_list) {
      // 获取数组中的第一个元素
      Group_member_info *member = m_suitable_donors.front();
      Donor_recovery_endpoints donor_endpoints;
      // 获取 Donor 的端点信息 
      endpoints = donor_endpoints.get_endpoints(member);
      ...
      // 从数组中移除第一个元素
      m_suitable_donors.pop_front();
      delete member;
      empty_donor_list = m_suitable_donors.empty();
      number_servers = m_suitable_donors.size();
    }
    mysql_mutex_unlock(&m_donor_list_lock);

    // No valid donor in the list
    if (endpoints.size() == 0) {
      error = 1;
      continue;
    }
    // 循环遍历 endpoints 中的每个端点
    for (auto endpoint : endpoints) {
      hostname.assign(endpoint.first);
      port.assign(std::to_string(endpoint.second));

      // 设置 clone_valid_donor_list
      if ((error = update_donor_list(sql_command_interface, hostname, port))) {
        continue; /* purecov: inspected */
      }

      if (m_being_terminated) goto thd_end;

      terminate_wait_on_start_process(WAIT_ON_START_PROCESS_ABORT_ON_CLONE);
      // 执行克隆操作
      error = run_clone_query(sql_command_interface, hostname, port, username,
                              password, use_ssl);

      // Even on critical errors we continue as another clone can fix the issue
      if (!critical_error) critical_error = evaluate_error_code(error);

      // On ER_RESTART_SERVER_FAILED it makes no sense to retry
      if (error == ER_RESTART_SERVER_FAILED) goto thd_end;

      if (error && !m_being_terminated) {
        if (evaluate_server_connection(sql_command_interface)) {
          critical_error = true;
          goto thd_end;
        }

        if (group_member_mgr->get_number_of_members() == 1) {
          critical_error = true;
          goto thd_end;
        }
      }

      // 如果失败，则选择下一个端点进行重试。
      if (!error) break;
    }

    // 如果失败，则选择下一个 Donor 进行重试。
    if (!error) break;
  }
...
}

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.
• 11.
• 12.
• 13.
• 14.
• 15.
• 16.
• 17.
• 18.
• 19.
• 20.
• 21.
• 22.
• 23.
• 24.
• 25.
• 26.
• 27.
• 28.
• 29.
• 30.
• 31.
• 32.
• 33.
• 34.
• 35.
• 36.
• 37.
• 38.
• 39.
• 40.
• 41.
• 42.
• 43.
• 44.
• 45.
• 46.
• 47.
• 48.
• 49.
• 50.
• 51.
• 52.
• 53.
• 54.
• 55.
• 56.
• 57.
• 58.
• 59.
• 60.
• 61.
• 62.
• 63.
• 64.
• 65.
• 66.
• 67.
• 68.
• 69.
• 70.
• 71.
• 72.
• 73.
• 74.
• 75.
• 76.
• 77.
• 78.

该函数的处理流程如下：

1. 首先会选择一个 Donor。可以看到，代码中是通过front()函数来获取 m_suitable_donors 中的第一个元素。
2. 获取 Donor 的端点信息。
3. 循环遍历 endpoints 中的每个端点。
4. 设置 clone_valid_donor_list。
5. 执行克隆操作。如果操作失败，则会进行重试，首先是选择下一个端点进行重试。如果所有端点都遍历完了，还是没有成功，则会选择下一个 Donor 进行重试，直到遍历完所有 Donor。

当然，重试是有条件的，出现以下情况就不会进行重试：

1. error == ER_RESTART_SERVER_FAILED：实例重启失败。

   实例重启是克隆操作的最后一步，之前的步骤依次是：1. 获取备份锁。2. DROP 用户表空间。3. 从 Donor 实例拷贝数据。

   既然数据都已经拷贝完了，就没有必要进行重试了。

2. 执行克隆操作的连接被 KILL 了且重建失败。

3. group_member_mgr->get_number_of_members() == 1：集群只有一个节点。

既然克隆操作失败了会进行重试，那么思路来了，如果不想克隆操作在 Primary 节点上执行，很简单，让 Primary 节点上的克隆操作失败了就行。

怎么让它失败呢？

一个克隆操作，如果要在 Donor（被克隆节点）上成功执行，Donor 需满足以下条件：

1. 安装克隆插件。
2. 克隆用户需要 BACKUP_ADMIN 权限。

所以，如果要让克隆操作失败，任意一个条件不满足即可。推荐第一个，即不安装或者卸载克隆插件。

为什么不推荐回收权限这种方式呢？

因为卸载克隆插件这个操作（uninstall plugin clone）不会记录 Binlog，而回收权限会。

虽然回收权限的操作也可以通过SET SQL_LOG_BIN=0 的方式不记录 Binlog，但这样又会导致集群各节点的数据不一致。所以，非常不推荐回收权限这种方式。

所以，如果不想 MGR 从 Primary 节点克隆数据，直接卸载 Primary 节点的克隆插件即可。

问题虽然解决了，但还是有一个疑问：endpoints 中为什么会有多个端点呢？不应该就是 Donor 的实例地址，只有一个么？这个实际上与 group_replication_advertise_recovery_endpoints 有关。

group_replication_advertise_recovery_endpoints

group_replication_advertise_recovery_endpoints 参数是 MySQL 8.0.21 引入的，用来自定义恢复地址。

看下面这个示例。

登录后复制

group_replication_advertise_recovery_endpoints= "127.0.0.1:3306,127.0.0.1:4567,[::1]:3306,localhost:3306"

• 1.

在设置时，要求端口必须来自 port、report_port 或者 admin_port。

而主机名只要是服务器上的有效地址即可（一台服务器上可能存在多张网卡，对应的会有多个 IP），无需在 bind_address 或 admin_address 中指定。

除此之外，如果要通过 admin_port 进行分布式恢复操作，用户还需要授予 SERVICE_CONNECTION_ADMIN 权限。

下面我们看看 group_replication_advertise_recovery_endpoints 的生效时机。

在选择完 Donor 后，MGR 会调用get_endpoints来获取这个 Donor 的 endpoints。

登录后复制

// plugin/group_replication/src/plugin_variables/recovery_endpoints.cc
Donor_recovery_endpoints::get_endpoints(Group_member_info *donor) {
  ...
  std::vector<std::pair<std::string, uint>> endpoints;
  // donor->get_recovery_endpoints().c_str() 即 group_replication_advertise_recovery_endpoints 的值
  if (strcmp(donor->get_recovery_endpoints().c_str(), "DEFAULT") == 0) {
    error = Recovery_endpoints::enum_status::OK;
    endpoints.push_back(
        std::pair<std::string, uint>{donor->get_hostname(), donor->get_port()});
  } else {
    std::tie(error, err_string) =
        check(donor->get_recovery_endpoints().c_str());
    if (error == Recovery_endpoints::enum_status::OK)
      endpoints = Recovery_endpoints::get_endpoints();
  }
  ...
  return endpoints;
}

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.
• 11.
• 12.
• 13.
• 14.
• 15.
• 16.
• 17.
• 18.

如果 group_replication_advertise_recovery_endpoints 为 DEFAULT（默认值），则会将 Donor 的 hostname 和 port 设置为 endpoint。

注意，节点的 hostname、port 实际上就是 performance_schema.replication_group_members 中的 MEMBER_HOST、 MEMBER_PORT。

hostname 和 port 的取值逻辑如下：

登录后复制

// sql/rpl_group_replication.cc
void get_server_parameters(char **hostname, uint *port, char **uuid,
                           unsigned int *out_server_version,
                           uint *out_admin_port) {
  ...
  if (report_host)
    *hostname = report_host;
  else
    *hostname = glob_hostname;

  if (report_port)
    *port = report_port;
  else
    *port = mysqld_port;
  ...
  return;
}

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.
• 11.
• 12.
• 13.
• 14.
• 15.
• 16.
• 17.

优先使用 report_host、report_port，其次才是主机名、mysqld 的端口。

如果 group_replication_advertise_recovery_endpoints 不为 DEFAULT，则会该参数的值设置为 endpoints。

所以，一个节点，只有被选择为 Donor，设置的 group_replication_advertise_recovery_endpoints 才会有效果。

而节点有没有设置 group_replication_advertise_recovery_endpoints 与它能否被选择为 Donor 没有任何关系。

总结

1. MGR 选择 Donor 是随机的。
2. MGR 在执行克隆操作之前，会将 clone_valid_donor_list 设置为 Donor 的 endpoint，所以，在启动组复制之前，在 mysql 客户端中显式设置 clone_valid_donor_list 是没有效果的。
3. MGR 执行克隆操作，实际上调用的就是CLONE INSTANCE命令。
4. performance_schema.replication_group_members 中的 MEMBER_HOST 和 MEMBER_PORT，优先使用 report_host、report_port，其次才是主机名、mysqld 的端口。
5. 一个节点，只有被选择为 Donor，设置的 group_replication_advertise_recovery_endpoints 才会有效果。
6. 如果不想 MGR 从 Primary 节点克隆数据，直接卸载 Primary 节点的克隆插件即可。

延伸阅读

1.  MySQL 8.0 新特性之 Clone Plugin
2. 《MySQL实战》组复制章节

原创作者: u_15829120 转载于: https://blog.51cto.com/u_15829120/11528242