时长:大小18.15M
作者回复: 好问题, 是这样的,对于A的线程来说,就是“读文件”, 1. 如果这个文件现在还在 page cache中,那就最好了,直接读走; 2. 如果不在page cache里,就只好去磁盘读 这个行为是文件系统控制的,MySQL只是执行“读文件”这个操作
作者回复: 好问题。 一开始创建主备关系的时候, 是由备库指定的。 比如基于位点的主备关系,备库说“我要从binlog文件A的位置P”开始同步, 主库就从这个指定的位置开始往后发。 而主备复制关系搭建完成以后,是主库来决定“要发数据给备库”的。 所以主库有生成新的日志,就会发给备库。
作者回复: 好问题 一个事务的binlog日志不会被拆到两个binlog文件,所以会等到这个事务的日志写完再rotate,所以你会看见超过配置大小上限的binlog 文件
作者回复: Mysqlbinlog有个参数—stop-datetime
作者回复: 好问题, 会删除一条,但确实可能删除到之前的那条。 主要就是因为,没有主键的时候,binlog里面就不会记录主键字段。
作者回复: 是的,会
作者回复: 赞
作者回复: 一般说双M是只AB之间设置为互为主备,不过任何时刻只有一个节点在接受更新的
作者回复: 运维现在要求也挺高的 第一个问题其实我也没看懂,“高峰期丢数据”是指主备延迟查不到数据,还是真的丢了,得先问清楚下 不过你回答的第二点不太好,低峰期重做这个大家都知道要这么做,而且只是修复动作,没办法用来定位原因,面试官是要问你分析问题的方法(方向错误) 重搭从库错误日志里面什么都没有的(这个比较可惜,暴露了对字节不够了解,一般不了解的方法在面试的时候是不如不说的) 第二个问题三点都是你回答的吗?那还算回答得可以的,但是不能只讲名词,要找个你熟悉细节的方案展开一下 三方向也是对的 我估计就是第一个问题减分比较厉害
作者回复: 如果”redo没有及时刷盘,binlog刷盘了”之后瞬间数据库所在主机掉电, 主机重启,MySQL重启以后,这个事务会丢失;这里确实会引起日志和数据不一致, 这个就是我们说要默认设置为双1的原因之一哈
作者回复: 2. 流式发送,一个事务提交就会发 3. “回滚段也是先记录到内存,再记录在磁盘么?” 是的。 undolog(disk)不需要到data(disk),undo log的作用看一下08篇 5. “update时,需要记录更新前后的数据,那这样的话,chage buffer不是用不上了么” --- 不是的,binlog里面的内容用的是主键索引上的,主键索引确实用不上change buffer,但是普通索引可以
作者回复: 双写?别双写。
作者回复: 最好是换硬件,把备库的磁盘能力提上来, 可以考虑一下备库设置 innodb_flush_log_at_trx_commit 和 sync_binlog 为非双1 试试
作者回复: 是的,当然还有minimal可选,会好些😄
作者回复: 索引使用正确,不要出现全表扫描,其实OK的
作者回复: 修改的行要读入内存呀 写binlog只需要主键索引上的值 你这个语句的话,如果字段c d上都有索引,那么c用不上chsnge buffer, D可能可以同上
作者回复: 我的建议是不处理,自增主键id不连续应该作为常态,也就是说系统不要依赖于这个它必须要连续
作者回复: 1. 有用,最好保留这些信息一起执行; 2. 提升不了多少速度的,花时间主要还是在更新数据的那些日志上,那些日志又不能去掉的:) 3. 这个方案是串行恢复。你可以把全量恢复出来的库,接成线上一个从库的备库,开并行复制,
作者回复: 对,只是一个举例的
作者回复: 这个的意思是, 现在工作线程里面等待的队列太多,都已经超过上限了,要等工作线程消化掉一些事务再分 简单说,就是备库的应用日志的队列太慢了。。