知识点
1 语句执行依次经过 : 连接器 , 分析器 , 优化器 ,执行器(操作引擎) , 然后进入存储引擎
2 redo log 和 bin log 的设计思路可以用到自己的程序里
3 redo log 类似粉板 , 先记账 , 不忙的时候再记到本子上(磁盘) , 因为后者还需要去一页一页翻找到对应人的记录再进行修改 , 速度慢 , 对应到磁盘就是 IO 成本高
4 粉板和账本 = Write-Ahead Logging , 先写日志再写磁盘
5 粉板空间有限 , 如果满了则需要放下手上的工作 ,先把一部分写到账本里
6 redo log 固定大小的一组文件 , 类似一个循环队列的写法 ,
7 redo log 保证了 crash safe , 因为是写在文件里的
8 binlog是 server 层的日志 , 没有 crash-safe 能力 , 为何? 我的猜测是 binlog 没有事务提交 , redo log 则有两阶段提交 , 如果崩溃了事务就回滚了 , 数据和 redo log 都保证了一致 , 而 binlog 很可能已经写入数据库,但是 binlog 没有记录
9 redo log 只有 innodb 有 , binlog 所有引擎都可以用
10 redo log 记录在数据也上做了什么修改 , binlog 记录执行语句 或 ROW(变化前和后的都会记)
11 redo 是循环写 , binlog 是一直追加写
12 先更新内存里该行的数据 , 同时写 redo log prepare , 然后写 binlog ,然后 redo log 提交
14 误删恢复 : 用全量备份恢复到某个点 , 然后取出从该点开始的 binlog 进行重放 , 然后从临时库按需恢复到线上库
13 两阶段提交 ? 目前理解为一个原子事务 , 只有binlog小弟同意并成功了,才会通知老大redo log提交
15 两阶段提交 , 我的理解是 其实就是保证了 redo log 和 binlog 写的原子性 , 保证了一致
16 扩容读库方法 : 全量+binlog
17 参数 innodb_flush_log_at_trx_commit=1 , 每次 redo log 直接写磁盘 , 保证异常重启数据不丢 sync_binlog=1 一样的道理
18 两阶段提交在日常开发中可能也用得到
19 问题: 全量备份 , 什么场景 一天一备 比 一周一备份 更有优势 ? 影响力数据库系统的哪个指标?
问题不太好 , 如果要使用到全量恢复的话 , 一天一备可以应用比较少的 binlog , 一周一备最坏情况要应用一周的 binlog
20 留言里的讨论还没看? 评论 留言可以当做测试用例 看提问自己能不能解答
