InnoDB的log写入策略及主从同步
ib_logfile是InnoDB的事务日志文件。ib_logfile与bin-log共同控制事务恢复。本文简要说明其写入时机、写入策略， 以及分析系统异常对主从数据一致性的影响。1、 基本概念
a) ib_logfile文件个数由innodb_log_files_in_group配置决定，若为2，则在datadir目录下有两个文件，命令从0开始，分别为ib_logfile0和ib_logfile1.
b) 文件为顺序写入，当达到最后一个文件末尾时，会从第一个文件开始顺序复用。
c) lsn: Log Sequence Number，是一个递增的整数。 Ib_logfile中的每次写入操作都包含至少1个log，每个log都带有一个lsn。在内存page修复过程中，只有大于page_lsn的log才会被使用。
d) lsn的保存在全局变量log_sys中。递增数值等于每个log的实际内容长度。即如果新增的一个log长度是len，则log_sys->lsn += len.
e) ib_logfile每次写入以512（OS_FILE_LOG_BLOCK_SIZE）字节为单位。实际写入函数 log_group_write_buf (log/log0log.c)
f) 每次写盘后是否flush，由参数innodb_flush_log_at_trx_commit控制。
2、 log_sys介绍
log_sys是一个全局内存结构。以下说明几个成员的意义。
3、相关更新
用一个简单的更新语句来说明log_sys以及ib_logfile的更新内容的过程。假设我们的更新只涉及到非索引的固定长度字段。
a) 在log_sys->buf中写入undo log。 对于一个单一的语句，需要先创建一个undolog头。
b) 在log_sys->buf中写入undo log的实际内容。
c) 在log_sys->buf中写入buffer page的更新内容。此处保存了更新的完整信息。
d) 在log_sys->buf中写入启动事务（trx_prepare）的日志
e) 将a～d的所有log内容写入ib_logfile中。
f) 写bin-log
g) 在log_sys->buf中写入事务结束(trx_commit)的日志
h) 将f步骤的log内容写入ib_logfile中。
4、 流程说明
1) 完成上述所有操作时，数据文件还没有更新。
2) 每次写入log_sys->buf时同时更新lsn和buf_free。 每次写ib_logfile时同时更新written_to_all_lsn和buf_next_to_write；
3) 每次写ib_logfile时以512字节为对齐，如需写入600字节，则实际写入1k。写到最后一个文件末尾则从第一个文件重复使用。
4) 若涉及到索引更新，在步骤c之后会增加索引更新的log。由于索引可能有merge过程，因此在merge过程中会另外增加写入一个log。但事务完全提交仍在步骤g中。索引的更新由于已经写盘，并不会因此丢失。
5、 日志策略与数据安全
ib_logfile和bin-log的作用之一是保证系统异常时的数据安全，可以分析一下上述流程过程中出现数据库异常关闭时数据安全性。从上述流程看到：
1) 在a～d过程中若出现异常关闭，由于没有写入到磁盘中，因此整个事务放弃；
2) 若在e刚完成时出现异常关闭，虽然事务内容已经写盘，但没有提交。在重启恢复的时候，发现这个事务还没有提交，逻辑上整个事务放弃。 （重启日志中会有Found 1 prepared transaction(s) in InnoDB, rollback xid…字样）。
3) 在f或g完成后出现异常关闭，bin-log写入成功后，则异常重启后能够根据bin-log恢复事务的修改。（重启日志中会有Found 1 prepared transaction(s) in InnoDB, commit xid…字样）。
4) 在h完成后出现异常关闭，由于事务日志完整，因此事务能够正常恢复。
6、 日志策略与主从同步
主从同步关心的问题是
1) 会不会由于主库能够根据ib_logfile恢复数据，而由于bin-log没写导致从库同步时少了这个事务？
2) 或者反之，bin-log写成功，而ib_logfile没有写完，导致从库执行事务，而主库不执行？
先来看控制log写入的主要流程
源码sql/handler.cc:
ha_commit_trans{…if ((err= ht->prepare(ht, thd, all))) —-a)
…
tc_log->log_xid(thd, xid) —–b)
…
error=ha_commit_one_phase(thd, all)—c)
…
}
说明：可以看到, InnoDB的log分成两段更新，前提是开启bin-log。（条件是有超过1个引擎需要更新日志，而bin-log也是引擎之一，因此至少两个）。
从上面的分析流程可以看到
☆ 假设在阶段a)结束之后程序异常， 此时没有写入bin-log。 则从库不会同步这个事务。 主库上，在重启之后，从恢复日志中这个事务没有trx_commit，因此会被回滚。 逻辑上主从库都不会执行这个事务。
☆ 假设在阶段b)结束后程序异常，此时bin-log已经写入，则从库会同步这个事务。 主库上，根据恢复日志和bin-log，也能够正常恢复此事务。
也就是说，若bin-log写入完成，则主从库都会正常完成事务；bin-log没有写入，则主从库都完成事务。不会出现主从不一致的问题。
7、 redo log丢失造成的主从不一致
上述的流程并不是天衣无缝的。ib_logfile的写盘是能够被设置成非实时flush的。假设在bin-log写入完成后，系统崩溃，则可能出现这样的情况：bin-log写入所以从库能够执行事务。但主库中trx_prepare的日志没有被写入到ib_logifle中，导致主库不执行事务。这样就会出现主从不一致的情况—主库没执行事务，而从库执行。
参数innodb_flush_log_at_trx_commit决定了出现这种情况的可能场景。
a) 值为0
此时事务完成后并不马上写ib_logfile。 因此在bin-log写入完成后主库异常关闭（数据库崩溃），则可能出现上述情况。
b) 值为2
此时事务完成后写ib_logfile但不flush。因此在bin-log写入完成后主库系统异常（操作系统崩溃），则可能造成上述情况。
因此比较安全的做法是设置值为1，每次事务完成都写盘并flush，代价是io负载增大。退一步设置为2，则只在操作系统崩溃时才会造成不一致。
[附]恢复代码流程（sql/handler.cc）xarecover_handlerton{ sql_print_information(“Found %d prepared transaction(s) in %s”, got, ha_resolve_storage_engine_name(hton));
foreach (trx)
{
if (found in bin-log)
{
sql_print_information(“commit xid %s”, xid_to_str(buf, info->list+i));
hton->commit_by_xid(hton, info->list+i);
}
else
{
sql_print_information(“rollback xid %s”,xid_to_str(buf, info->list+i));
hton->rollback_by_xid(hton, info->list+i);
}
}
}
页:
[1]