论组提交技术在 MySQL中的阅读与思考
发布时间：2023-06-12 13:23:34 所属栏目：MySql教程 来源：
导读：组提交难点
一.给leader进程带来了不公平
二.兼顾redo和binlog顺序的对应
三.事务redo与binlog的写流程与fsync时机（没有引进组提交时的流程）
四.为什么要组提交？（简单组提交下的弊病，硬件资源速度的不
一.给leader进程带来了不公平
二.兼顾redo和binlog顺序的对应
三.事务redo与binlog的写流程与fsync时机（没有引进组提交时的流程）
四.为什么要组提交？（简单组提交下的弊病，硬件资源速度的不
|
组提交难点 一.给leader进程带来了不公平 二.兼顾redo和binlog顺序的对应 三.事务redo与binlog的写流程与fsync时机（没有引进组提交时的流程） 四.为什么要组提交？（简单组提交下的弊病，硬件资源速度的不一致性，带来的优势） 关键参数与流程 flush阶段 将binlog写入内存,(好像没有binlog buffer的说法，直接写入内存，内存写入条带文件)。 binlog_max_flush_queue_time 每多少秒去写入一次binlog到内存（官方）。flush阶段中一批事务等待的时间。类似于检票处一次用Bodycheck牌挡住一定数量的人。默认0,这个参数已经废弃 sync->commit阶段，主要是在sync，sync(刷盘binlog)。若sync_binlog不为1，多个组应该卡在这儿。岂不是导致commit ack变慢？不对，只是加速 binlog_group_commit_sync_delay 应该是用来控制leader进度的，也就是发车间隔时间。这个是导致leader不公平的主要原因。单位微妙。微妙级别的话，相对于刷盘的时间，leader的不公平看起来微乎其微。 binlog_group_commit_sync_no_delay_count 最低发车座位数， 类似于定员流水发车大巴，车上的人到达一定的数量后，直接发车，不在等待一个最小发车间隔 commit阶段 redo log buffer刷盘 sync_binlog的含义就变了，假定设为1000，表示的不是1000个事务后做一次fsync，而是1000个事务组。默认1的话就是，1个事务组提交一次fsync binlog 也就是说，比如， 1-1000个事务，前面999个都没有sync，默认是sync成功的。第1000个事务时进行真正的binlog sync 。若中间挂了，没有sync成功，那么1-1000事务的binlog 都没有被记录 第一次等待的时间可能不太好理解，，应该是第一次分批限流。比方说，保证流入sync阶段的都是按时间分段的，而不是离散的算是预分组吧。找不到很合适的例子说明 总结 在读写IO相对于内存的速度有很大差距的情况下，把单次离散写，合并成批量连续写。硬盘的寻道时间要比顺序写硬盘的时间要慢很多。尽量少寻道，也是一种思路 （编辑：驾考网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
推荐文章
站长推荐
