首页   注册   登录
 monsterxx03 最近的时间轴更新

monsterxx03

V2EX 第 13118 号会员,加入于 2011-10-30 20:35:18 +08:00
今日活跃度排名 9752
monsterxx03 最近回复了
26 天前
回复了 xutao881 创建的主题 电影 《蜘蛛侠:平行世界》为啥这么难看?
我反而觉得是漫威改编里最棒的一部, 这部的确比较粉丝向.
39 天前
回复了 1747479654 创建的主题 知乎 听说逼乎在裁员, 真还是假?
你业务代码 /db 慢和 nginx/apache 有啥关系...
用过 airflow, 但后来发现内部 task 的依赖关系没那么复杂, 也没分布式和可视化的需求, 想维护成本少点, 最后还是自己写了个简单的. 业务复杂的话 airflow 挺够用的.
还有目前的 binlog 并不能实现断电恢复, binlog 可以做 point-in-time recovery 这个一般是写坏数据了用来修数据的.
有点钻牛角尖了额, 你先做了个假设: 把 binlog 提前到 commit 之前写,然后就能用 binlog 来做 crash recover.

问题是目前 binlog 和 redo log 的实现格式完全不同(binlog 根据你需求可选三种呢). 刷盘机制也完全不同. 虽然我不了解这块代码的实现, 但工程上硬用 binlog 来实现 crash recovery 感觉是不行的.(你想想还有 semi sync 的同步方式呢, 同步这块相当复杂)

binlog 的设计目的是为了让外部系统获取数据库内的数据变更,可以理解成一个 expose 的接口.

redo 是 innodb 为了达成 acid, crash recovery 的一种内部实现手段.

存储引擎的确不能控制 binlog, 也不应该关心 binlog, 这不算妥协, 是 by design.
@cc959798 大概明白你的意思了, MySQL 支持不只一种存储引擎, 各种不同的存储引擎都能开 binlog (用于获取 ongoing change, master/slave), 但 redo/undo log 是 innodb 专属的. 它们工作在不同层面上.

如果设计一个 innodb 专属的 MySQL, 的确可以只保留一种 log, 比如 aws 的 aurora db, master/slave 之间就是通过 redo log 同步的( 当然 binlog 也可以开)
楼主应该是认为 MySQL 每次写入数据的时候直接写入磁盘(ibd 文件), 但实际上写的是 WAL(write ahead log), 然后客户端就收到成功的返回了, 因为数据真正落地是随机写, 写 WAL 是顺序写, 要快得多. binlog 的生成应该在数据正真落地之后.

crash 重启后, ibd 文件不一定是最新的, 需要用 WAL 里的 redo log 来恢复数据.
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2209 人在线   最高记录 4236   ·  
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.3 · 8ms · UTC 11:27 · PVG 19:27 · LAX 03:27 · JFK 06:27
♥ Do have faith in what you're doing.
沪ICP备16043287号-1