MySQL purge log简单吗？
简单: purge log的功能很简单，purge master logs to 指定一个binlog，然后删除之前的文件系统上的binlog文件，并更新binlog.index文件。
复杂: 需要保证purge的原子操作吗, 怎么保证, 有崩溃恢复吗？
之前没有读过代码，想到代码实现上会遇到的问题：
问题1: 如果删除文件比较多，怎么平衡加锁的时间？
问题2: 怎么保证os文件删除和index文件的同步？
问题3: 怎么保证index文件写入是完整的？
问题4: 如果index更新了，文件没有删除，或者相反的情形发生会怎么样？
问题5: 最后如何清理index文件的前面n个字节，然后更改文件大小？
总体来说，也就是，在没有使用事务引擎来保证的一系列操作（purge log包括了多步操作），如何保证ACID或者进行了什么取舍？
1. purge log的测试:
purge master logs to 'binlog.000012';
2. 主要的数据结构：
typedef struct st_log_info
{
char log_file_name[FN_REFLEN];
my_off_t index_file_offset, index_file_start_offset;
my_off_t pos;
bool fatal;
mysql_mutex_t lock;
}
3. purge的简略步骤:
step 1: 为命令行输入的binlog.000012补充目录成一个绝对路径文件。
函数: MYSQL_BIN_LOG::make_log_name
根据当前的log_file_name, 计算目录的长度，最后生成完整的to_log.
step 2: 在binlog.index文件中查找binlog.000012文件。
函数: find_log_pos: 如果没有找到这个文件，就报错。比如文本文件格式不对，就无法删除。
step 3: 初始化index 文件的io cache。最终找到binlog.000012在index的位置。
step 4: 创建purge index临时文件
创建binlog.~rec~ 保存要删除的binlog文件。
step 5: 重新init index_file, 从开始位置读取。匹配每一个binlog，写入到purge index file。
step 6: 写入purge index file，并刷新
1. 先flush io把在内存中的数据写入文件系统标准IO缓存。
2. sync purge_index_file， 使用fdatasync。持久化到磁盘上。
step 7: 更新index文件。
1. mysql_file_seek，
2. mysql_file_read，
3. mysql_file_seek，
4. mysql_file_write
使用 1->2->3->4的时序删除文件的前n个字节。
5. ftruncate改变index文件的大小
step 8: 删除os上的文件，并删除purge index log临时文件
4. 现在再来看看这些问题：
问题1:
binlog.index文件是share的，purge的整个过程如果一直锁住，那主库这时要flush log就无法获取锁。
所以使用类似copy on write的策略，释放锁后，异步慢慢删除os上的文件。
即保证了index文件的加锁完整写入，又没有长时间影响主库切换binlog日志。
问题2:
因为异步化了os文件删除动作，这里无法保证index文件记录删除和os文件删除的同步。这里依赖purge index file
来完成同步和崩溃恢复。
问题3: index文件的写入是无法保证一行是一个完整的binlog文件，这个依赖文件系统。
但index文件是文本文件，当purge解析出错的时候，运维是可以修改这个文件来修复的。
注：如果是二进制文件，这样取舍可行吗，恐怕要使用事务引擎来保证了。
问题4:
1. 如果index文件更新了，os文件没有删除
当MySQL crash恢复的时候，会读取purge index file继续删除
2. 如果文件删除，index文件没有更新
从上面的步骤上看，不允许这中情况发生
问题5:
文件删除前面n字节的问题，本身可以使用另外一种策略，新建一个表，copy数据，rename。
但binlog.index是share的，不允许在线rename，所以使用步骤7的过程，在一个file handler上完成。
取舍： index file作为MySQL binlog文件的数据字典，首先要保证其数据的一致性，而os的文件是否能够删除可以进行取舍。
不知道实现的时候觉得命令很简单。
在想那些实现问题的时候，觉得又有点复杂。
看了源码后，觉得是自己又想复杂了。
