MySQL在哪些场景下不会写binlog示例详解_Mysql

背景

在 mysql 中，慢日志不仅可以记录在文件中，还可以记录在表中。具体是记录在文件还是表中是由log_output参数决定的。

该参数默认为file，即慢日志默认会记录在文件中。如果参数中包含table，则慢日志还会记录在mysql.slow_log中，而mysql.slow_log使用的是 csv 存储引擎。

最初研究这一问题，是为了确认在主从复制以及组复制（mgr）环境下，mysql.slow_log表中的慢日志是否会同步到其他节点。

随着分析的深入，发现 mysql 实际上提供了多种机制和开关，用于确保操作不会写入 binlog。

由于 row 格式 是目前最常用的 binlog 格式，本文将从 row 模式下 mysql 判断操作是否写入 binlog 的实现逻辑 入手，逐步引出相关控制开关，并分析它们各自的使用场景。

row 格式下判断操作是否写入 binlog 的实现逻辑

在 row 格式下，将数据变化记录到 binlog 的核心是在binlog_log_row函数中实现的：

int binlog_log_row(table *table, const uchar *before_record,
                   const uchar *after_record, log_func *log_func) {
  bool error = false;
  thd *const thd = table->in_use;
  // 判断当前操作是否需要写入 binlog
  if (check_table_binlog_row_based(thd, table)) {
    ...
    if (likely(!(error = write_locked_table_maps(thd)))) {
      bool const has_trans = thd->lex->sql_command == sqlcom_create_table ||
                             table->file->has_transactions();
      // 根据操作类型，将行镜像写入 binlog
      error = (*log_func)(thd, table, has_trans, before_record, after_record);
    }
  }

  return error ? ha_err_rbr_logging_failed : 0;
}

首先调用 check_table_binlog_row_based 判断当前操作是否需要写入 binlog，若需要，则会针对不同的操作类型，调用不同的函数来处理。具体来说：

insert：write_rows_log_event::binlog_row_logging_function。
update：update_rows_log_event::binlog_row_logging_function。
delete：delete_rows_log_event::binlog_row_logging_function。

接下来，重点看看check_table_binlog_row_based函数的处理逻辑。

static bool check_table_binlog_row_based(thd *thd, table *table) {
  if (table->s->cached_row_logging_check == -1) {
    int const check(table->s->tmp_table == no_tmp_table &&
                    !table->no_replicate &&
                    binlog_filter->db_ok(table->s->db.str));
    table->s->cached_row_logging_check = check;
  }

  assert(table->s->cached_row_logging_check == 0 ||
         table->s->cached_row_logging_check == 1);

  return (thd->is_current_stmt_binlog_format_row() &&
          table->s->cached_row_logging_check &&
          (thd->variables.option_bits & option_bin_log) &&
          mysql_bin_log.is_open());
}

要返回 false，只需满足以下任意一个条件：

当前 sql 语句不能以 row 格式记录到 binlog 中：thd->is_current_stmt_binlog_format_row()为 false，例如 ddl 语句。
表不允许写入 binlog：table->s->cached_row_logging_check为 false。
当前线程未启用 binlog：thd->variables.option_bits & option_bin_log为 false。
binlog 未打开：mysql_bin_log.is_open() 为 false。

因为第一个条件和第四个条件为 false 的情况并不常见，下面将重点分析table->s->cached_row_logging_check和thd->variables.option_bits & option_bin_log为 false 时的场景。

cached_row_logging_check 为 false 的场景

table->s->cached_row_logging_check的赋值逻辑如下：

  if (table->s->cached_row_logging_check == -1) {
    int const check(table->s->tmp_table == no_tmp_table &&
                    !table->no_replicate &&
                    binlog_filter->db_ok(table->s->db.str));
    table->s->cached_row_logging_check = check;
  }

要使其为 false，必须满足以下任意一个条件：

当前表是临时表： table->s->tmp_table == no_tmp_table为 false。
库名不满足 --replicate-do-db、–replicate-ignore-db 复制规则：binlog_filter->db_ok(table->s->db.str)为 false。
表设置了 no_replicate。该属性是在open_table_from_share()函数中根据表的类型和存储引擎能力标志设置的。

no_replicate 的设置逻辑如下：

  if ((share->table_category == table_category_log) ||
      (share->table_category == table_category_rpl_info) ||
      (share->table_category == table_category_gtid)) {
    outparam->no_replicate = true;
  } else if (outparam->file) {
    const handler::table_flags flags = outparam->file->ha_table_flags();
    outparam->no_replicate =
        !(flags & (ha_binlog_stmt_capable | ha_binlog_row_capable)) ||
        (flags & ha_has_own_binlogging);
  } else {
    outparam->no_replicate = false;
  }

可以看到，no_replicate 会在以下几种情况设置为 true。

一、特殊类别的表。包括：

table_category_log 类别的表，具体包括 mysql.general_log, mysql.slow_log。
table_category_rpl_info 类别的表，具体包括 mysql.slave_relay_log_info，mysql.slave_master_info，mysql.slave_worker_info。
table_category_gtid 类别的表，具体包括 mysql.gtid_executed。

二、根据存储引擎的能力标志判断。

这些标志是每个存储引擎单独设置的，一般是在m_int_table_flags或table_flags函数中定义的，主要是用来向 server 层声明：这个存储引擎的表，支持哪些能力/约束。与复制相关的标志有三个：

ha_binlog_stmt_capable：支持 statement 格式 binlog。
ha_binlog_row_capable：支持 row 格式 binlog
ha_has_own_binlogging：该引擎自己管理 binlog（如 ndb cluster）。

在 mysql 支持的存储引擎中，只有 perfschema（对应 performance_schema）和 temptable（mysql 8.0 引入的内部临时表存储引擎，主要用来替代老的 memory/myisam 内部临时表）不会设置 ha_binlog_stmt_capable 或 ha_binlog_row_capable。

所以，针对 performance_schema 表的操作不会写入 binlog。

# ls mysql-8.4.3/storage/
archive  blackhole  csv  example  federated  heap  innobase  myisam  myisammrg  ndb  perfschema  secondary_engine_mock  temptable

option_bin_log 为 false 的场景

thd->variables保存当前线程的会话级系统变量状态。其中，option_bits 是一个位图（bitmap），用于记录多个线程级选项标志，option_bin_log 则表示是否将当前线程的操作写入 binlog。

以下是几种典型场景。

一、显式关闭会话级 binlog

set session sql_log_bin = 0;

该参数对应的回调函数是fix_sql_log_bin_after_update。

当sql_log_bin = 1时，打开 option_bin_log，反之，则清除 option_bin_log。

static bool fix_sql_log_bin_after_update(sys_var *, thd *thd,
                                         enum_var_type type [[maybe_unused]]) {
  assert(type == opt_session);

  if (thd->variables.sql_log_bin)
    thd->variables.option_bits |= option_bin_log;
  else
    thd->variables.option_bits &= ~option_bin_log;

  return false;
}

二、从库未启用 log_replica_updates

当实例作为从库运行，且未开启 log_replica_updates 时，从库 sql 线程重放的操作默认不写 binlog。

void set_slave_thread_options(thd *thd) {
  ...
  ulonglong options = thd->variables.option_bits | option_big_selects;
  if (opt_log_replica_updates)
    options |= option_bin_log;
  else
    options &= ~option_bin_log;
  ...
}

三、使用disable_binlog_guard临时关闭 binlog

disable_binlog_guard用于在特定代码块内临时关闭 binlog，并在离开作用域时自动恢复原状态。

class disable_binlog_guard {
 public:
  explicit disable_binlog_guard(thd *thd)
      : m_thd(thd),
        m_binlog_disabled(thd->variables.option_bits & option_bin_log) {
    thd->variables.option_bits &= ~option_bin_log;
  }

  ~disable_binlog_guard() {
    if (m_binlog_disabled) m_thd->variables.option_bits |= option_bin_log;
  }

 private:
  thd *const m_thd;
  const bool m_binlog_disabled;
};

disable_binlog_guard 被调用的场景有：

3.1 实例初始化（--initialize）

static bool handle_bootstrap_impl(handle_bootstrap_args *args) {
  ...
  if (opt_initialize) {
    assert(thd->system_thread == system_thread_server_initialize);

    sysd::notify("status=initialization of mysql system tables in progress\n");
    
    const disable_binlog_guard disable_binlog(thd);
    const disable_sql_log_bin_guard disable_sql_log_bin(thd);

    compiled_in_command_iterator comp_iter;
    rc = process_iterator(thd, &comp_iter, true);

    thd->system_thread = system_thread_init_file;

    sysd::notify("status=initialization of mysql system tables ",
                 rc ? "unsuccessful" : "successful", "\n");

    if (rc != 0) {
      return true;
    }
  }
  ...
  return false;
}

3.2 实例升级

bool upgrade_system_schemas(thd *thd) {
  disable_autocommit_guard autocommit_guard(thd);
  bootstrap_error_handler bootstrap_error_handler;

  server_option_guard<bool> acl_guard(&opt_noacl, true);
  server_option_guard<bool> general_log_guard(&opt_general_log, false);
  server_option_guard<bool> slow_log_guard(&opt_slow_log, false);
  disable_binlog_guard disable_binlog(thd);
  disable_sql_log_bin_guard disable_sql_log_bin(thd);
  ...
  bootstrap_error_handler.set_log_error(false);
  bool err =
      fix_mysql_tables(thd) || fix_sys_schema(thd) || upgrade_help_tables(thd);
  if (!err) {
    /*
      initialize structures necessary for federated server from mysql.servers
      table.
    */
    servers_init(thd);
    err = (dbug_evaluate_if("force_fix_user_schemas", true,
                            dd::bootstrap::dd_bootstrap_ctx::instance()
                                .is_server_upgrade_from_before(
                                    bootstrap::server_version_80011))
               ? check.check_all_schemas(thd)
               : check.check_system_schemas(thd)) ||
          check.repair_tables(thd) ||
          dd::tables::dd_properties::instance().set(
              thd, "mysqld_version_upgraded", mysql_version_id);
  }
  ...
  return dd::end_transaction(thd, err);
}

3.3 create server, alter server 和 drop server 操作。

3.4 install component, uninstall component 操作。

3.5 install plugin, uninstall plugin 操作。

3.6 一些内部操作，例如 alter table 过程中创建/删除临时表、drop database 时清理数据库对象、更新数据字典表、后台线程自动更新列直方图。

除了上面介绍的这些场景，通过将 thd->lex->no_write_to_binlog 设置为true（thd->lex表示当前 sql 语句的语法解析上下文），可以在语句级别控制该语句不写入 binlog。

no_write_to_binlog 为 true 的场景

以下场景会将 no_write_to_binlog 设置为 true。

shutdown、restart 命令。
reset 系列命令，包括：reset master, reset slave, reset persist。
显式指定no_write_to_binlog或local。部分维护类 sql 命令（optimize, analyze, repair, flush）支持在语句中显式指定不写 binlog，如，

optimize no_write_to_binlog table t1;
analyze local table t1;
repair no_write_to_binlog table t1;
flush local privileges;

需要注意的是，对于flush命令，即使未显式指定no_write_to_binlog，以下命令默认也不会写入 binlog：no_write_to_binlog，flush logs、flush binary logs、flush tables with read lock、flush tables tbl_name … for export。

总结

虽然上面列举的场景较多，但实际上并不需要大家刻意去记。

简单来说，

凡是 mysql 内部自动执行的操作（即非用户手动执行的操作），通常不会写入 binlog。
典型场景包括：实例初始化与升级、mysql.slow_log表的写入、数据字典的维护、performance_schema表数据的更新等。
对 mysql 库下的表进行 dml 操作，只要不属于上面提到的特殊类别的表，基本都会写入 binlog。

但若执行的是 ddl 操作（如 truncate），基本都会写入 binlog。
对 performance_schema 中的表进行 dml、ddl 操作会提示权限不足，即便是用 root 用户执行。但部分表允许执行 truncate 操作，且 truncate 操作不会写入 binlog。

到此这篇关于mysql在哪些场景下不会写binlog的文章就介绍到这了,更多相关mysql哪些场景不会写binlog内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！