一、栈帧
#0 my_delete (name=0x7ffff0fa0490 "./binlog.000005", MyFlags=0) at /root/softm/percona-server-5.7.22-22/mysys/my_delete.c:25
#1 0x000000000186416f in inline_mysql_file_delete (key=2, src_file=0x2293340 "/root/softm/percona-server-5.7.22-22/sql/binlog.cc", src_line=6735,
name=0x7ffff0fa0490 "./binlog.000005", flags=0) at /root/softm/percona-server-5.7.22-22/include/mysql/psi/mysql_file.h:1331
#2 0x0000000001871497 in MYSQL_BIN_LOG::purge_index_entry (this=0x2e39c40, thd=0x7fffa4000b70, decrease_log_space=0x0, need_lock_index=false)
at /root/softm/percona-server-5.7.22-22/sql/binlog.cc:6735
#3 0x0000000001870b35 in MYSQL_BIN_LOG::purge_logs (this=0x2e39c40, to_log=0x7ffff0fa0a80 "./binlog.000007", included=false, need_lock_index=true,
need_update_threads=true, decrease_log_space=0x0, auto_purge=false) at /root/softm/percona-server-5.7.22-22/sql/binlog.cc:6495
#4 0x0000000001868839 in purge_master_logs (thd=0x7fffa4000b70, to_log=0x7fffa4006570 "binlog.000007") at /root/softm/percona-server-5.7.22-22/sql/binlog.cc:3127
#5 0x00000000015b7874 in mysql_execute_command (thd=0x7fffa4000b70, first_level=true) at /root/softm/percona-server-5.7.22-22/sql/sql_parse.cc:2989
#6 0x00000000015c0362 in mysql_parse (thd=0x7fffa4000b70, parser_state=0x7ffff0fa2600) at /root/softm/percona-server-5.7.22-22/sql/sql_parse.cc:5901
#7 0x00000000015b3ef6 in dispatch_command (thd=0x7fffa4000b70, com_data=0x7ffff0fa2d70, command=COM_QUERY)
at /root/softm/percona-server-5.7.22-22/sql/sql_parse.cc:1490
#8 0x00000000015b2c83 in do_command (thd=0x7fffa4000b70) at /root/softm/percona-server-5.7.22-22/sql/sql_parse.cc:1021
#9 0x00000000016fb8fc in handle_connection (arg=0x38f2910) at /root/softm/percona-server-5.7.22-22/sql/conn_handler/connection_handler_per_thread.cc:312
#10 0x0000000001932112 in pfs_spawn_thread (arg=0x3860a50) at /root/softm/percona-server-5.7.22-22/storage/perfschema/pfs.cc:2190
#11 0x00007ffff7bc6aa1 in start_thread () from /lib64/libpthread.so.0
#12 0x00007ffff6719bcd in clone () from /lib64/libc.so.6二、大概过程
整个删除过程大概是：
- 先提取需要删除的binary log 记录到一个 临时的index文件binlog.~rec~中。
- 将需要保留的binary log文件存放到一个叫做binlog.index_crash_safe的文件中。
- 将原有的binlog.index进行删除，将binlog.index_crash_safe重新命名为binlog.index。
下面是中间时刻的文件列表。
-rw-r----- 1 root root 80 Jun 26 10:25 binlog.index
-rw-r----- 1 root root 32 Jun 26 10:38 binlog.~rec~
-rw-r----- 1 root root 48 Jun 26 10:39 binlog.index_crash_safe- 然后就删除binlog.~rec~记录中的binary log文件。
- 最后删除binlog.~rec~文件。整个过程集中在。
函数MYSQL_BIN_LOG::purge_logs中，我们可以将断点设置在my_delete函数上很容易看出这种过程。
下面是我的debug中的一部分：
(gdb) p purge_index_file->file
$6 = 61
OS中我们可以看到这个文件描述符为
61 -> /root/softm/percona-server-5.7.22-22/mysql-test/var/mysqld.1/data/binlog.~rec~
三、innodb_flush_method = O_DIRECT不会影响REDO
innodb_flush_method = O_DIRECT不会影响REDO
os_file_create_func
/* We disable OS caching (O_DIRECT) only on data files */
if (!read_only
&& *success
&& (type != OS_LOG_FILE && type != OS_DATA_TEMP_FILE)
&& (srv_unix_file_flush_method == SRV_UNIX_O_DIRECT
|| srv_unix_file_flush_method == SRV_UNIX_O_DIRECT_NO_FSYNC)) {
os_file_set_nocache(file.m_file, name, mode_str);
} else if (!srv_read_only_mode
&& *success
&& srv_unix_file_flush_method == SRV_UNIX_ALL_O_DIRECT) {
/* Do fsync() on log and files when setting O_DIRECT fails.
See log_io_complete() */
if (!os_file_set_nocache(file.m_file, name, mode_str)) {
srv_unix_file_flush_method = SRV_UNIX_O_DIRECT;
}
4、O_DIRECT只影响datafille不影响redo
