MHA在启用GTID的MySQL集群丢数据的问题

今天有朋友咨询我MySQL高可用方案MHA的事情，恰好之前在公司改造过MHA，看过MHA的代码，解答了朋友的问题，在这里也分享一下经验。

MHA使用Perl语言编写，本文尽量不涉及语法，直观讲解。

MHA作为业界内火了十几年的MySQL高可用方案，必然有他的过人之处。在传统的MySQL复制模式下（文件 + 点位），MHA可以追补relay log，可以重放差异的binlog，还有丰富的工具支持，在当时看来，基本上无懈可击。

但是随着MySQL版本的迭代，GTID横空出世。虽然MHA也可在启用GTID的MySQL集群中使用，但是第一个坑就出现了。

直接上代码：

    $log->info("* Phase 3: Master Recovery Phase..\n");
    $log->info();

    $log->info("* Phase 3.1: Getting Latest Slaves Phase..\n");
    $log->info();
    check_set_latest_slaves();

    if ( !$_server_manager->is_gtid_auto_pos_enabled() ) {
      $log->info();
      $log->info("* Phase 3.2: Saving Dead Master's Binlog Phase..\n");
      $log->info();
      save_master_binlog($dead_master);
    }

    $log->info();
    $log->info("* Phase 3.3: Determining New Master Phase..\n");
    $log->info();

    my $latest_base_slave;
    if ( $_server_manager->is_gtid_auto_pos_enabled() ) {
      $latest_base_slave = $_server_manager->get_most_advanced_latest_slave();
    }
    else {
      $latest_base_slave = find_latest_base_slave($dead_master);
    }
    $new_master = select_new_master( $dead_master, $latest_base_slave );

    my $start_failover_subject = "Start Failover";
    send_report($dead_master, $new_master, $start_failover_subject);

    my ( $master_log_file, $master_log_pos, $exec_gtid_set ) =
      recover_master( $dead_master, $new_master, $latest_base_slave,
      $binlog_server_ref );
    $new_master->{activated} = 1;

    $log->info("* Phase 3: Master Recovery Phase completed.\n");

从上述代码中可以看出，如果没有启用GTID，也就是!$_server_manager->is_gtid_auto_pos_enabled()，会保存原主库的binlog，也就是save_master_binlog($dead_master)函数。如果启用了GTID呢，就进入了选主阶段，并没有保存原主库的binlog。

那么问题来了，假设一套启用了GTID的MySQL集群，所有从库都有延时，这时候主库宕机，就出现了我朋友的问题，切换过程中会丢失数据。

如果丢失数据，那MHA岂不是不可靠了吗？

其实不然，上述问题可解。在上面代码的最后，是在补新主库（$new_master）和原主库（$dead_master）的差异数据。调用的函数为recover_master( $dead_master, $new_master, $latest_base_slave,$binlog_server_ref )。在这个函数中，穿入的参数$binlog_server_ref，就是上面问题的解，下面上论据。

我们先看一下recover_master这个函数

sub recover_master($$$$) {
...
  my ( $master_log_file, $master_log_pos, $exec_gtid_set );
  if ( $_server_manager->is_gtid_auto_pos_enabled() ) {
    ( $master_log_file, $master_log_pos, $exec_gtid_set ) =
      recover_master_gtid_internal( $new_master, $latest_base_slave,
      $binlog_server_ref );
  }
  else {
    ( $master_log_file, $master_log_pos ) =
      recover_master_internal( $new_master, $latest_base_slave );
  }
  ...
  return ( $master_log_file, $master_log_pos, $exec_gtid_set );
}

这里只提取了恢复新主库和原主库差异binlog相关的部分。可以看到，如果启用了GTID（$_server_manager->is_gtid_auto_pos_enabled()），那么调用recover_master_gtid_internal( $new_master, $latest_base_slave,$binlog_server_ref );；否则会调用recover_master_internal( $new_master, $latest_base_slave )。从这里可以看出，如果启用GTID，调用的函数中的参数有$binlog_server_ref，也就是binlog server的相关配置。

我们继续看被调用的函数recover_master_gtid_internal。

sub recover_master_gtid_internal($$$) {
  ...
  if (
    save_from_binlog_server(
      $relay_master_log_file, $exec_master_log_pos, $binlog_server_ref
    )
    )
  {
    apply_binlog_to_master($target);
  }
  return $_server_manager->get_new_master_binlog_position($target);
}

上面代码中，略去了补relay log和change master部分。可以看出，如果启用了$binlog_server_ref，则会调用apply_binlog_to_master来补binlog。apply_binlog_to_master这个函数就不展开了，大致过程就是调用save_binary_logs把binlog server的binlog拉取到本地，然后在新主库上回放。

综上，在启用GTID的MySQL集群上部署MHA，必须额外增加binlog server，来解决延时带来的数据丢失隐患。

注意，binlog server的原理也是采用mysqlbinlog模拟一个从库来保存binlog日志，因此binlog server的配置要>= slaves。

聊到这里，朋友的问题已经解答完毕，至于如何在MHA中配置binlog server，我让他自行百度去了。

后面，我们又聊了一下MySQL 8.x中能否使用MHA？答案是可以的。（这里不做MGR和MHA的比较，只讨论可行性）。MySQL 8.x在使用MHA时有哪些问题，参考这里。