备案控制台
探索云世界
开发者社区 数据库 文章 正文

Mysql 5.7 Gtid内部学习(五) mysql.gtid_executed表/gtid_executed变量/gtid_purged变量的更改时机

2017-12-18 1810
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云数据库 RDS MySQL Serverless，0.5-2RCU 50GB
推荐场景：
学生管理系统数据库设计 搭建个人博客
简介： 简书地址: http://www.jianshu.com/p/905d7e89a305

本节将集中讨论下面三种Gtid更新的时机，这部分相当重要，后面的故障案列会和这节有关。下面先来看一下他们的定义

  • mysql.gtid_executed表：Gtid持久化的介质，Mysql启动阶段会读取这个表来获取gtid_executed变量的值。
  • gtid_executed变量(show global variables)：Mysql数据库已经执行了哪些Gtid事务，处于内存中。show slave status中的Executed_Gtid_Set也取自这里。
  • gtid_purged变量(show global variables)：由于binlog文件的删除(如purge binary logfiles或者超过expire_logs_days设置)已经丢失的Gtid事务，同时在搭建备库的我们使用set global gtid_purged变量来提示Mysql哪些Gtid事务我已经执行过了。

这也是我们DBA通常能够观察到的几种Gtid，有了前文的描述我们知道其中mysql.gtid_executed表是一种Gtid持久化的介质，而gtid_executed变量和gtid_purged变量则对应
了Gtid_state中的executed_gtids和lost_gtids内存数据。他们分别表示Mysql数据库执行了哪些Gtid事务，有哪些Gtid事务由于binlog文件的删除已经丢失了。
其次我们先来达成一个共识gtid_executed变量一定是实时更新的不管主库和从库。我们的讨论分为主库，从库和通用从源码的角度进行详细讨论。并且约定都是打开Gtid的情况下。最后给出最终总结。

一、主库修改时机

(1) binlog关闭

不生成Gtid,mysql.gtid_executed表/gtid_executed变量/gtid_purged变量均不更新。

(2) binlog打开

  • mysql.gtid_executed表修改时机

在binlog发生切换(rotate)的时候保存直到上一个binlog文件执行过的全部Gtid，它不是实时更新的。
栈帧如下:

#0  Gtid_table_persistor::save (this=0x2f9f9c0, gtid_set=0x7ffff03595a0) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid_persist.cc:425
#1  0x0000000001803dbe in Gtid_state::save (this=0x2ff8bb0, gtid_set=0x7ffff03595a0) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid_state.cc:796
#2  0x0000000001803f62 in Gtid_state::save_gtids_of_last_binlog_into_table (this=0x2ff8bb0, on_rotation=true)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid_state.cc:835
#3  0x000000000185266d in MYSQL_BIN_LOG::new_file_impl (this=0x2dffc80, need_lock_log=false, extra_description_event=0x0)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:6751
#4  0x00000000018520a7 in MYSQL_BIN_LOG::new_file_without_locking (this=0x2dffc80, extra_description_event=0x0)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:6636
#5  0x0000000001853e67 in MYSQL_BIN_LOG::rotate (this=0x2dffc80, force_rotate=true, check_purge=0x7ffff0359c4b)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:7292

其主要逻辑在Gtid_state::save_gtids_of_last_binlog_into_table 中我们在随后的部分讨论这个函数逻辑。

  • gtid_executed变量修改时机

如前文所述ordered_commit flush阶段生成Gtid，在commit阶段才计入gtid_executed变量，它是实时更新的。
栈帧如下：

#0  Gtid_set::_add_gtid (this=0x2ff8d38, sidno=1, gno=16) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid.h:1135
#1  0x0000000001804576 in Gtid_set::_add_gtid (this=0x2ff8d38, gtid=...) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid.h:1166
#2  0x00000000018024ba in Gtid_state::update_gtids_impl (this=0x2ff8bb0, thd=0x7fff2c000b70, is_commit=true)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid_state.cc:304
#3  0x00000000018020df in Gtid_state::update_on_commit (this=0x2ff8bb0, thd=0x7fff2c000b70) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid_state.cc:148
#4  0x00000000018573d4 in MYSQL_BIN_LOG::process_commit_stage_queue (this=0x2dffc80, thd=0x7fff2c000b70, first=0x7fff2c000b70)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:8646
#5  0x0000000001858b51 in MYSQL_BIN_LOG::ordered_commit (this=0x2dffc80, thd=0x7fff2c000b70, all=false, skip_commit=false)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:9304

其主要逻辑在Gtid_state::update_gtids_impl中我们在随后的部分讨论这个函数逻辑。

  • gtid_purged变量修改时机

在Mysql触发的清理binlog的情况下，比如purge binary logs to或者超过参数expire_logs_days设置的天数后自动删除，需要将丢失的Gtid计入这个变量中。
栈帧如下:

#0  MYSQL_BIN_LOG::init_gtid_sets (this=0x2e00280, all_gtids=0x0, lost_gtids=0x2fcaee8, verify_checksum=false, need_lock=false, trx_parser=0x0, gtid_partial_trx=0x0, is_server_starting=false)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:4333
#1  0x0000000001850b8e in MYSQL_BIN_LOG::purge_logs (this=0x2e00280, to_log=0x7fff57a74ad0 "/root/mysql5.7.14/percona-server-5.7.14-7/mysql-test/var/mysqld.1/test.000202", included=false, need_lock_index=true, 
    need_update_threads=true, decrease_log_space=0x0, auto_purge=false) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:6036
#2  0x0000000001848ecf in purge_master_logs (thd=0x7fff49200dc0, to_log=0x7fff492051a8 "test.000202") at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:2815

其主要逻辑在MYSQL_BIN_LOG::purge_logs中，我们随后查看其代码片段，同时MYSQL_BIN_LOG::init_gtid_sets函数是一个及其重要的函数，主要用在：

  • Mysql启动时候初始化整个Gtid_state中的各种Gtid_set。
  • Mysql删除binlog(如purge binary logfiles或者超过expire_logs_days设置)后需要确认gtid_purged变量(及Gtid_state.lost_gtids)的值的时候。

随后我会单独一节来讲解Mysql Gtid模块的初始化还会讲解这个函数。

二、主库修改时机源码函数分析

这里就对上面提到的主要逻辑函数进行分析

  • Gtid_state::save_gtids_of_last_binlog_into_table函数逻辑
logged_gtids_last_binlog.add_interval_memory(PREALLOCATED_INTERVAL_COUNT, iv); //这里构建一个logged_gtids_last_binlog集合来保存切换后需要写入表和previous_gtids_logged的Gtid
  /*
    logged_gtids_last_binlog= executed_gtids - previous_gtids_logged -
                              gtids_only_in_table
  */
  global_sid_lock->wrlock();//
  ret= (logged_gtids_last_binlog.add_gtid_set(&executed_gtids) !=  //将当前执行过的Gtid全部加入logged_gtids_last_binlog 列如:executed_gtids start=1, end=27 
        RETURN_STATUS_OK);
  if (!ret)
  {
    logged_gtids_last_binlog.remove_gtid_set(&previous_gtids_logged); //获得上一个binlog文件包含的全部Gtid，并且做一个差集 列如:previous_gtids_logged 为start=1, end=25
                                                                      //做完差集后logged_gtids_last_binlog为start=26, end=27
    logged_gtids_last_binlog.remove_gtid_set(&gtids_only_in_table);//此处主库一定为空，除非异常情况
    if (!logged_gtids_last_binlog.is_empty()) 
    {
      /* Prepare previous_gtids_logged for next binlog on binlog rotation */
      if (on_rotation)
        ret= previous_gtids_logged.add_gtid_set(&logged_gtids_last_binlog);//将这个start=26, end=27的Gtid集合加入到previous_gtids_logged中，这样previous_gtids_logged也完整了
      global_sid_lock->unlock();
      /* Save set of GTIDs of the last binlog into gtid_executed table */
      if (!ret)
        ret= save(&logged_gtids_last_binlog);//将这个start=26, end=27的Gtid集合写入到表mysql.gtid_executed表中
    }
  • Gtid_state::update_gtids_impl函数代码片段
while (g.sidno != 0)
    {
      if (g.sidno != prev_sidno)
        sid_locks.lock(g.sidno);
      owned_gtids.remove_gtid(g); //从owned_gtid中去掉
      git.next();
      g= git.get();
      if (is_commit)
        executed_gtids._add_gtid(g);//将这个Gtid加入到executed_gtids
    }
  • MYSQL_BIN_LOG::purge_logs函数代码片段
if (!is_relay_log)
  {
    global_sid_lock->wrlock();
    error= init_gtid_sets(NULL,
                          const_cast<Gtid_set *>(gtid_state->get_lost_gtids()),
                          opt_master_verify_checksum,
                          false/*false=don't need lock*/,
                          NULL/*trx_parser*/, NULL/*gtid_partial_trx*/);//这里我看到将gtid_state->lost_gtids直接传入给了init_gtid_sets
                                                                        //init_gtid_sets会做正向查找获得gtid_state->lost_gtids这个函数稍后
                                                                        //详细讨论
    global_sid_lock->unlock();
    if (error)
      goto err;
  }

三、从库修改时机

(1) binlog关闭或者binlog开启参数log_slave_updates关闭的情况

将他们放到一起因为他们的表现完全一样。

  • mysql.gtid_executed表修改时机

前面已经说过这种情况下从库没有办法通过binlog来持久化sql_thread执行过的Gtid事务，只能通过实时更新mysql.gtid_executed表来保存，所以必须要要实时将Gtid持久化到mysql.gtid_executed表中。实际上实时保存mysql.gtid_executed发生在commit的preper阶段之前，也就是最开始。但是对于主库来讲由于还没有生成Gtid，那么则不能写入
栈帧如下：

#0  commit_owned_gtids (thd=0x7fffec000970, all=false, need_clear_owned_gtid_ptr=0x7ffff08bf2cb) at /mysql/mysql-5.7.17/sql/handler.cc:1571
#1  0x0000000000f465c3 in ha_commit_trans (thd=0x7fffec000970, all=false, ignore_global_read_lock=false) at /mysql/mysql-5.7.17/sql/handler.cc:1669
#2  0x0000000001686f0d in trans_commit_stmt (thd=0x7fffec000970) at /mysql/mysql-5.7.17/sql/transaction.cc:458
#3  0x000000000180fb16 in rows_event_stmt_cleanup (rli=0x3937d30, thd=0x7fffec000970) at /mysql/mysql-5.7.17/sql/log_event.cc:11124
#4  0x000000000180f801 in Rows_log_event::do_apply_event (this=0x7fffec018020, rli=0x3937d30) at /mysql/mysql-5.7.17/sql/log_event.cc:11026
#5  0x00000000017f7b7b in Log_event::apply_event (this=0x7fffec018020, rli=0x3937d30) at /mysql/mysql-5.7.17/sql/log_event.cc:3324
#6  0x00000000018690a6 in apply_event_and_update_pos (ptr_ev=0x7ffff08bf830, thd=0x7fffec000970, rli=0x3937d30) at /mysql/mysql-5.7.17/sql/rpl_slave.cc:4702
#7  0x000000000186a75e in exec_relay_log_event (thd=0x7fffec000970, rli=0x3937d30) at /mysql/mysql-5.7.17/sql/rpl_slave.cc:5212
#8  0x0000000001870d07 in handle_slave_sql (arg=0x38cc1c0) at /mysql/mysql-5.7.17/sql/rpl_slave.cc:7320

其主要逻辑包含在commit_owned_gtids中。

  • gtid_executed变量修改时机

这个和主库一样实时更新，不做讨论。

  • gtid_purged变量修改时机

由于压根没有binlog来记录已经执行过的Gtid事务，所以gtid_purged变量实时更新
其更改处于整个ha_commit_trans的结尾如下：

if (need_clear_owned_gtid)
  {
    thd->server_status&= ~SERVER_STATUS_IN_TRANS;
    /*
      Release the owned GTID when binlog is disabled, or binlog is
      enabled and log_slave_updates is disabled with slave SQL thread
      or slave worker thread.
    */
    if (error)
      gtid_state->update_on_rollback(thd);
    else
      gtid_state->update_on_commit(thd);
  }

栈帧如下(这个栈帧取值5.7.17)：

#0  Gtid_set::_add_gtid (this=0x2f9ef40, sidno=2, gno=33083) at /mysql/mysql-5.7.17/sql/rpl_gtid.h:1136
#1  0x00000000017e9990 in Gtid_set::_add_gtid (this=0x2f9ef40, gtid=...) at /mysql/mysql-5.7.17/sql/rpl_gtid.h:1167
#2  0x00000000017e906e in Gtid_state::update_gtids_impl_own_gtid (this=0x2f9eca0, thd=0x7fffec000970, is_commit=true) at /mysql/mysql-5.7.17/sql/rpl_gtid_state.cc:939
#3  0x00000000017e6f3f in Gtid_state::update_gtids_impl (this=0x2f9eca0, thd=0x7fffec000970, is_commit=true) at /mysql/mysql-5.7.17/sql/rpl_gtid_state.cc:240
#4  0x00000000017e6d25 in Gtid_state::update_on_commit (this=0x2f9eca0, thd=0x7fffec000970) at /mysql/mysql-5.7.17/sql/rpl_gtid_state.cc:201
#5  0x0000000000f46d46 in ha_commit_trans (thd=0x7fffec000970, all=true, ignore_global_read_lock=false) at /mysql/mysql-5.7.17/sql/handler.cc:1846
#6  0x000000000168676b in trans_commit (thd=0x7fffec000970) at /mysql/mysql-5.7.17/sql/transaction.cc:239
#7  0x0000000001802aaa in Xid_log_event::do_commit (this=0x7fffec013c60, thd_arg=0x7fffec000970) at /mysql/mysql-5.7.17/sql/log_event.cc:6824
#8  0x00000000018034d7 in Xid_apply_log_event::do_apply_event (this=0x7fffec013ca8, rli=0x3937d30) at /mysql/mysql-5.7.17/sql/log_event.cc:7049

当然其处理逻辑在Gtid_state::update_gtids_impl_own_gtid中。

(2)binlog开启同时参数log_slave_updates开启的情况

这种情况sql_thread执行过的Gtid事务可以通过binlog进行维护，所以mysql.gtid_executed表和gtid_purged变量不需要实时更新。

  • mysql.gtid_executed表修改时机

和主库一致。及在进行日志切换的时候进行更新，不做讨论

  • gtid_executed变量修改时机

和主库一样实时更新，不做讨论

  • gtid_purged变量修改时机

和主库一致，binlog删除时更新，不做讨论

四、从库修改时机源码函数分析

  • commit_owned_gtids函数逻辑：
//如果 binlog 没有开启包括(log_bin=0 和 sql_log_bin =0 )或者 开启了binlog 但是slave线程并且slave update 没有开启,都会记录gtid到表
//但是这里要注意一点在主库上如果binlog不开启那么thd->owned_gtid.sidno ==0 因为这个时候Gtid都没有生成,生成阶段为order_commit的commit阶段
  if ((!opt_bin_log || (thd->slave_thread && !opt_log_slave_updates)) && 
      (all || !thd->in_multi_stmt_transaction_mode()) && //all 代表是否是显示begin 事务in_multi_stmt_transaction_mode则相反
      !thd->is_operating_gtid_table_implicitly && //是否是GTID_NEXT方式 flase
      !thd->is_operating_substatement_implicitly)//是否是子语句 flase
  {
    /*
      If the binary log is disabled for this thread (either by
      log_bin=0 or sql_log_bin=0 or by log_slave_updates=0 for a
      slave thread), then the statement will not be written to
      the binary log. In this case, we should save its GTID into
      mysql.gtid_executed table and @@GLOBAL.GTID_EXECUTED as it
      did when binlog is enabled.
    */
    if (thd->owned_gtid.sidno > 0)
    {
      error= gtid_state->save(thd);//就是这里进行了mysql.gtid_executed表的实时更新
      *need_clear_owned_gtid_ptr= true;
    }
    else if (thd->owned_gtid.sidno == THD::OWNED_SIDNO_ANONYMOUS)
      *need_clear_owned_gtid_ptr= true;
  }
  • Gtid_state::update_gtids_impl_own_gtid 函数逻辑片段
    这个函数是5.7.17的，5.7.14没有逻辑放到了Gtid_state::update_gtids_impl中
if (is_commit)
  {
    DBUG_EXECUTE_IF(
      "rpl_gtid_update_on_commit_simulate_out_of_memory",
      DBUG_SET("+d,rpl_gtid_get_free_interval_simulate_out_of_memory"););
    /*
      Any session adds transaction owned GTID into global executed_gtids.

      If binlog is disabled, we report @@GLOBAL.GTID_PURGED from
      executed_gtids, since @@GLOBAL.GTID_PURGED and @@GLOBAL.GTID_EXECUTED
      are always same, so we did not save gtid into lost_gtids for every
      transaction for improving performance.

      If binlog is enabled and log_slave_updates is disabled, slave
      SQL thread or slave worker thread adds transaction owned GTID
      into global executed_gtids, lost_gtids and gtids_only_in_table.
    */
    executed_gtids._add_gtid(thd->owned_gtid); //加入executed_gtids集合
    thd->rpl_thd_ctx.session_gtids_ctx().
      notify_after_gtid_executed_update(thd);
    if (thd->slave_thread && opt_bin_log && !opt_log_slave_updates)//如果是slave线程同时binlog开启了并且log_slave_updates关闭了
                                                                   //如果binlog关闭则使用 executed_gtids这样提高性能前面的注释说了
    {
      lost_gtids._add_gtid(thd->owned_gtid);  //写入lost_gtids也就是更新参数gtid_purged变量
      gtids_only_in_table._add_gtid(thd->owned_gtid);
    }
  }

五、通用更改时机

mysql.gtid_executed表修改时机
  • 在reset master的时候清空本表
    栈帧如下：
#0  Gtid_table_persistor::delete_all (this=0x2f9f9c0, table=0x7fff2c0116a0) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid_persist.cc:795
#1  0x000000000180a4ef in Gtid_table_persistor::reset (this=0x2f9f9c0, thd=0x7fff2c000b70) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid_persist.cc:689
#2  0x0000000001801f2e in Gtid_state::clear (this=0x2ff8bb0, thd=0x7fff2c000b70) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid_state.cc:36
#3  0x000000000184fee6 in MYSQL_BIN_LOG::reset_logs (this=0x2dffe80, thd=0x7fff2c000b70, delete_only=false)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:5586
#4  0x0000000001872308 in reset_master (thd=0x7fff2c000b70) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_master.cc:587

其主要逻辑在Gtid_state::clear中。

  • 在set global gitd_purged的时候，设置本表
    栈帧如下：
#0  Gtid_table_persistor::save (this=0x2f9f9c0, gtid_set=0x7ffff0359a70) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid_persist.cc:425
#1  0x000000000180400a in Gtid_state::save (this=0x2ff8bb0, gtid_set=0x7ffff0359a70) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid_state.cc:796
#2  0x0000000001803c25 in Gtid_state::add_lost_gtids (this=0x2ff8bb0, gtid_set=0x7ffff0359a70) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid_state.cc:737
#3  0x00000000016778f3 in Sys_var_gtid_purged::global_update (this=0x2de9fe0, thd=0x7fff2c000b70, var=0x7fff2c006630)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sys_vars.cc:5888
#4  0x00000000014d5cd1 in sys_var::update (this=0x2de9fe0, thd=0x7fff2c000b70, var=0x7fff2c006630) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/set_var.cc:184
#5  0x00000000014d74ee in set_var::update (this=0x7fff2c006630, thd=0x7fff2c000b70) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/set_var.cc:812
#6  0x00000000014d6d1a in sql_set_variables (thd=0x7fff2c000b70, var_list=0x7fff2c003528) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/set_var.cc:669

其主要逻辑在Gtid_state::add_lost_gtids中。

gtid_executed变量修改时机
  • 在reset master的时候清空本变量
    栈帧同上
  • 在set global gitd_purged的时候，设置本变量
    栈帧同上
  • 在mysql启动的时候初始化设置gtid_executed变量，这个将在后面章节详细描述描述步骤。
gtid_purged变量修改时机
  • 在reset master的时候清空本变量
    栈帧同上
  • 在set global gitd_purged的时候，设置本变量
    栈帧同上
  • 在mysql启动的时候初始化设置gtid_executed变量，这个将在后面章节详细描述描述步骤。

六、通用更改时机源码函数分析

  • Gtid_state::clear函数逻辑
int Gtid_state::clear(THD *thd)
{
 ....
  // the wrlock implies that no other thread can hold any of the mutexes
  sid_lock->assert_some_wrlock();
  lost_gtids.clear();//此处清空gtid_purged变量
  executed_gtids.clear();//此处清空gtid_executed变量
  gtids_only_in_table.clear();//清空only in table Gtid set
  previous_gtids_logged.clear();//清空 previous gtids logged Gtid set
  /* Reset gtid_executed table. */
  if ((ret= gtid_table_persistor->reset(thd)) == 1)//此处清空mysql.gtid_executed表
  {
    /*
      Gtid table is not ready to be used, so failed to
      open it. Ignore the error.
    */
    thd->clear_error();
    ret= 0;
  }
  next_free_gno= 1;
  DBUG_RETURN(ret);
}
  • Gtid_state::add_lost_gtids函数逻辑
enum_return_status Gtid_state::add_lost_gtids(const Gtid_set *gtid_set)
{
  ......
  if (save(gtid_set)) //此处将set gtid_purge的值加入到mysql.gtid_executed表中
    RETURN_REPORTED_ERROR;
  PROPAGATE_REPORTED_ERROR(gtids_only_in_table.add_gtid_set(gtid_set));
  PROPAGATE_REPORTED_ERROR(lost_gtids.add_gtid_set(gtid_set));//此处将set gtid_purge的值加入到gtid_purge变量中
  PROPAGATE_REPORTED_ERROR(executed_gtids.add_gtid_set(gtid_set));//此处将set gtid_purge的值加入到gtid_executed变量中
  lock_sidnos(gtid_set);
  broadcast_sidnos(gtid_set);
  unlock_sidnos(gtid_set);
  DBUG_RETURN(RETURN_STATUS_OK);
}

七、本节小结

为了方便这里将上面的重点文字描述进行提取，去掉源码部分，方便大家阅读

主库修改时机

(1) binlog关闭

不生成Gtid,mysql.gtid_executed表/gtid_executed变量/gtid_purged变量均不更新。

(2) binlog打开
  • mysql.gtid_executed表修改时机
    在binlog发生切换(rotate)的时候保存直到上一个binlog文件执行过的全部Gtid，它不是实时更新的。
  • gtid_executed变量修改时机
    如前文所述ordered_commit flush阶段生成Gtid，在commit阶段才计入gtid_executed变量，它是实时更新的。
  • gtid_purged变量修改时机
    在Mysql触发的清理binlog的情况下，比如purge binary logs to或者超过参数expire_logs_days设置的天数后自动删除，需要将丢失的Gtid计入这个变量中。

从库修改时机

(1) binlog关闭或者binlog开启参数log_slave_updates关闭的情况
  • mysql.gtid_executed表修改时机
    实时将Gtid持久化到mysql.gtid_executed表中。
  • gtid_executed变量修改时机
    它是实时更新的。
  • gtid_purged变量修改时机
    由于压根没有binlog来记录已经执行过的Gtid事务，所以gtid_purged变量实时更新
(2) binlog开启同时参数log_slave_updates开启的情况
  • mysql.gtid_executed表修改时机
    进行日志切换的时候进行更新，同主库。
  • gtid_executed变量修改时机
    实时更新，同主库。
  • gtid_purged变量修改时机
    binlog删除时更新，同主库。

通用修改时机

  • mysql.gtid_executed表修改时机
    1、在reset master的时候清空本表。
    2、在set global gitd_purged的时候，设置本表。

  • gtid_executed变量修改时机
    1、在reset master的时候清空本变量。
    2、在set global gitd_purged的时候，设置本变量。
    3、在mysql启动的时候初始化设置gtid_executed变量。

  • gtid_purged变量修改时机
    1、在reset master的时候清空本变量。
    2、在set global gitd_purged的时候，设置本变量。
    3、在mysql启动的时候初始化设置gtid_executed变量。

此外reset master命令除了完整上述功能还会清理binlog，重新初始化binlog从序号1开始。而set global gitd_purged参数一般只有在reset master后使用，用于搭建Gtid从库或者处理Gtid从库故障。

学习完本节至少能学习到：

  • 1、主库和从库对于mysql.gtid_executed表，gtid_executed变量，gitd_purged变量
    在各种情况下的修改时机
  • 2、reset master做了什么关于Gtid相关的工作
  • 3、set global gitd_purged做了什么关于Gtid相关的工作

作者微信：


270
微信.jpg
文章标签：
云数据库 RDS MySQL 版
关系型数据库
SQL
MySQL
关键词：
云数据库 RDS MySQL 版表
云数据库 RDS MySQL 版学习
学习云数据库 RDS MySQL 版
云数据库 RDS MySQL 版gtid
云数据库 RDS MySQL 版变量
相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境，其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心，利用清洁计算为万物互联的新世界提供源源不断的能源动力，目前开服的区域包括中国（华北、华东、华南、香港）、新加坡、美国（美东、美西）、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程，来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品：云服务器ECS 云服务器 ECS（Elastic Compute Service）是一种弹性可伸缩的计算服务，助您降低 IT 成本，提升运维效率，使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
重庆八怪
目录
相关文章
Cool架构
|
存储 关系型数据库 MySQL
MySQL学习（五）
MySQL学习
Cool架构
91 0
起飞的风筝
|
Oracle 关系型数据库 MySQL
【mysql】—— 表的内连和外连
【mysql】—— 表的内连和外连
起飞的风筝
37 0
起飞的风筝
|
1月前
|
存储 关系型数据库 MySQL
【mysql】—— 表的增删改查
【mysql】—— 表的增删改查
起飞的风筝
40 0
哈茶真的c
|
23天前
|
存储 SQL 关系型数据库
【MySQL】4. 表的操作
【MySQL】4. 表的操作
哈茶真的c
21 0
Cool架构
|
存储 关系型数据库 MySQL
MySQL学习（七）
MySQL学习
Cool架构
83 0
追逐时光者
|
17天前
|
SQL 存储 关系型数据库
6本值得推荐的MySQL学习书籍
本文是关于MySQL学习书籍的推荐，作者在DotNetGuide技术社区和微信公众号收到读者请求后，精选了6本值得阅读的MySQL书籍，包括《SQL学习指南（第3版）》、《MySQL是怎样使用的：快速入门MySQL》、《MySQL是怎样运行的：从根儿上理解MySQL》、《深入浅出MySQL：数据库开发、优化与管理维护（第3版）》以及《高性能MySQL（第4版）》和《MySQL技术内幕InnoDB存储引擎(第2版)》。此外，还有12本免费书籍的赠送活动，涵盖《SQL学习指南》、《MySQL是怎样使用的》等，赠书活动有效期至2024年4月9日。
追逐时光者
37 0
技术蜜糖罐
|
22天前
|
SQL 关系型数据库 MySQL
轻松入门MySQL：深入学习数据库表管理，创建、修改、约束、建议与性能优化（3）
轻松入门MySQL：深入学习数据库表管理，创建、修改、约束、建议与性能优化（3）
技术蜜糖罐
36 0
技术蜜糖罐
|
22天前
|
存储 关系型数据库 MySQL
MySQL数据库性能大揭秘：表设计优化的高效策略（优化数据类型、增加冗余字段、拆分表以及使用非空约束）
MySQL数据库性能大揭秘：表设计优化的高效策略（优化数据类型、增加冗余字段、拆分表以及使用非空约束）
技术蜜糖罐
33 0
技术蜜糖罐
|
22天前
|
缓存 关系型数据库 MySQL
MySQL 查询优化：提速查询效率的13大秘籍（索引设计、查询优化、缓存策略、子查询优化以及定期表分析和优化）（中）
MySQL 查询优化：提速查询效率的13大秘籍（索引设计、查询优化、缓存策略、子查询优化以及定期表分析和优化）（中）
技术蜜糖罐
37 0
JavaBuild
|
2天前
|
存储 SQL 关系型数据库
MySQL学习手册（第一部分）
mysql日常使用记录
JavaBuild
59 0

热门文章

最新文章

  • 1
    超1/3中国500强企业都在用的「汇联易」，为什么选用阿里云RDS？
  • 2
    MySQL全局库表查询准确定位字段
  • 3
    MySQL学习（三）
  • 4
    安装Docker&镜像容器操作&使用Docker安装部署MySQL，Redis，RabbitMQ，Nacos，Seata，Minio
  • 5
    在Python Web开发过程中：数据库与缓存，MySQL和NoSQL数据库的主要差异是什么？
  • 6
    轻松入门MySQL：深入探究MySQL的ER模型，数据库设计的利器与挑战（22）
  • 7
    【MySQL技术专题】「问题实战系列」深入探索和分析MySQL数据库的数据备份和恢复实战开发指南（8.0版本升级篇）
  • 8
    MySQL数据库，可以使用二进制日志（binary log）进行时间点恢复
  • 9
    MySQL学习（五）
  • 10
    MySQL学习（七）
  • 1
    [MySQL]事务原理之redo log,undo log
    45
  • 2
    [MySQL]SQL优化之索引的使用规则
    35
  • 3
    [MySQL] SQL优化之性能分析
    30
  • 4
    【mysql】—— 用户管理
    31
  • 5
    【mysql】—— 视图
    30
  • 6
    【mysql】—— 函数的基本介绍
    25
  • 7
    【mysql】—— 表的增删改查
    40
  • 8
    【mysql】—— 表的约束
    31
  • 9
    【MYSQL】—— MySQL 在 Centos 7环境安装
    50
  • 10
    MySQL模糊查询二三事
    24

    • 相关课程

    更多
  • MySQL企业常见架构与调优经验分享
  • 云数据库MySQL版快速上手教程
  • 阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
  • MySQL实战进阶
  • 数据库及SQL/MySQL基础
  • 云数据库MySQL快速入门

    • 相关电子书

    更多
  • 搭建电商项目架构连接MySQL
  • 搭建4层电商项目架构，实战连接MySQL
  • PolarDB MySQL引擎重磅功能及产品能力盛大发布

    • 相关实验场景

    更多
  • 极致弹性的PolarDB Serverless确保数据业务持续在线
  • 云端MySQL的安装及应用
  • 体验PolarDB MySQL多主集群
  • 基于ECS+RDS的在线留言系统
  • 如何通过RDS MySQL数据库内网访问
  • RDS MySQL Serverless资源与负载自适应

    • 推荐镜像

    更多
  • mysql
  • postgresql
  • mariadb
    • 下一篇
    部署LAMP环境（Alibaba Cloud Linux 3）