MySQL内核月报 2014.11-MySQL·　捉虫动态·SIGHUP 导致 binlog 写错

bug描述

这是5.6中和gtid相关的一个bug，当 mysqld 收到 sighup 信号 （比如 kill -1） 的时候，会 flush binlog，但是新生成binlog开头没写 Previous_gtids_log_event，这会导致下面 2 个问题：

这个时候 mysqld 重启的话，会发现再也起不来了，error log 里有这样的错

The binary log file mysql/mysql-bin.000020 is logically corrupted: The first global transaction identifier was read, but no other information regarding identifiers existing on the previous log files was found.

这个时候主库继续更新，然后从库来拉取 binlog 的时候，io 线程会停下来

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: Error reading header of binary log while looking for the oldest binary log that contains any GTID that is not in the given gtid set

bug 分析

mysqld 在收到 sighup 信号后，signal_hand 线程会调用 reload_acl_and_cache 函数 (sql_reload.cc)，最终会调用 MYSQL_BIN_LOG::open_binlog，open_binlog 有这段逻辑:

signal_hand 没有调用 store_globals 设置 THR_THD 这个key，所以这个时候 current_thd 得到的值是空的，因此prev_gtids_event 也就不会写进新binlog中的。

2个问题的分析

mysqld 重启不起来的原因：

mysqld 在启动的时候会通过 mysql_bin_log.init_gtid_sets 来初始化 gtid_executed 和 gtid_purged 2个set，初使化 gtid_executed 时，会读最新的binlog，将文件开头 Previous_gtids_log_event 的 gtid set 和文件里所有的 gtid_event 加起来，放进 gtid_executed，在读文件过程中，如果发现没有 Previous_gtids_log_event ，就报错，程序退出。

备库的错误信息解释：

在gtid协议下，主库向备库发 binlog 是用 com_binlog_dump_gtid 函数，这个函数会调到 MYSQL_BIN_LOG::find_first_log_not_in_gtid_set()，这个函数的作用是找到备库需要的第一个 binlog 文件，逻辑是这样的，从编号最大的binlog 往前找，对每个binlog，读取 Previous_gtids_log_event，如果发现这个集合是备库的发来的 gtid_set 的子集，就停止，当前这个binlog文件就是备库需要的第一个binlog文件。找的过程中，如果发现没有 Previous_gtids_log_event，就把错误信息 ER_MASTER_FATAL_ERROR_READING_BINLOG 发给备库。

对server 起不来的，只能手动删所有 binlog 文件了，同时还要清空 binlog.index 文件，有备库的话要重搭备库。 对于主备场景下，备库停掉的，purge 主库的binlog，如果主备不致的话，比如主库sighup后又有新的更新，这时候需要重做备库，因为binlog已经没了，只能拿主库的数据来重新做一个。

bug 修复

这个bug官方已经修复，具体可以参考 revno: 5908。

修复方法类似reload_acl_and_cache 中 REFRESH_GRANT 的逻辑，生成一个临时的 THD 作为 current_thd，在flush logs 完后释放掉。

Mysql误删,恢复数据,binlog闪回,宝塔面板 binlog是二进制日志文件，用来记录Mysql内部对数据库的改动（只记录对数据的修改操作），主要用于数据库的主从复制以及增量恢复。 当我们搭建mysql主从复制的时候，两个实例之间也是通过binlog来完成数据的备份同步。 所以有这种根据binlog得到执行sql语句、闪回sql语句，我们只需要利用根据分析binlog，然后就可以找到准确的数据改动sql，并得到闪回sql，检查无误后执行就可以恢复数据了
MySQL 日志之 binlog 格式 → 关于 MySQL 默认隔离级别的探讨 背景问题 再讲 binlog 之前，我们先来回顾下主流关系型数据库的默认隔离级别，是默认隔离级别，不是事务有哪几种隔离级别，别会错题意了 1、Oracle、SQL Server 的默认隔离级别是什么，MySQL 的呢 ？ 2、为什么 MySQL 的默认隔离级别是 RR ？
mysql中的undo log、redo log 、binlog大致概要 undo log（回滚日志）、redo log（重做日志） 、binlog （归档日志）undo log，事务的原子性，用于事务回滚和MVCC（存储层，记录查询类）redo log，事务的持久性，用于服务器宕机故障恢复（存储层，记录查询类）binlog，用于数据备份和主从复制（服务层，记录更新修改类）日志区别undo log事务开始前的数据值redo log事务完成后的数据值。
db匠 rds内核团队秘密研发的全自动卖萌机. 追加特效: 发数据库内核月报. 月报传送: http://mysql.taobao.org/monthly/