GAQ

从库 MTS 多线程并行回放(二)

会有一股神秘感。 提交于 2020-03-04 15:25:28
本文作者:高鹏,欢迎订阅他的简书专栏 本节包含一个笔记,链接如下: https://www.jianshu.com/p/e920a6d33005 这一节会先描述 MTS 的工作线程执行 Event 的大概流程。然后重点描述一下 MTS 中检查点的概念。在后面的第 25 节我们可以看到,MTS 的异常恢复很多情况下需要依赖这个检查点,从检查点位置开始扫描 relay log 做恢复操作,但是在 GTID AUTO_POSITION MODE 模式且设置了 recovery_relay_log=1 的情况下这种依赖将会弱化。 一、工作线程执行 Event 前面我们已经讨论了协调线程分发 Event 的规则,实际上协调线程只是将 Event 分发到了工作线程的执行队列中。那么工作线程执行 Event 就需要从执行队列中拿出这些 Event,然后进行执行。整个过程可以参考函数 slave_worker_exec_job_group。因为这个流程比较简单,因此就不需要画图了,但是我们需要关注一些点如下: (1)从执行队列中读取 Event。注意这里如果执行队列中没有 Event 那么就进入空闲等待,也就是工作线程处于无事可做的状态,等待状态为 ‘Waiting for an event from Coordinator’。 (2)如果执行到 XID_EVENT

技术分享 | 从库 MTS 多线程并行回放(一)

巧了我就是萌 提交于 2020-02-26 06:03:32
作者:高鹏(八怪) 本节包含分发调用流程请参考链接: https://www.jianshu.com/p/8706d7422d89 一、综述 与单 SQL 线程的回放不同,MTS 包含多个工作线程,原有的 SQL 线程蜕变为协调线程。SQL 协调线程同时还承担了检查点的工作。我们知道并行回放的方式有两种,包含 LOGICAL_CLOCK 和 DATABASE,体现在判定哪些事物能够并行回放的规则不同。实际上源码对应两个不同的类: Mts_submode_logical_clock Mts_submode_database 这里只准备讨论基于 LOGICAL_CLOCK 的并发方式,而不会讨论老的基于 DATABASE 的方式,下面是我设置的参数: slave_parallel_type:LOGICAL_CLOCK slave_parallel_workers :4 注意 slave_parallel_workers 设置的是工作线程的个数,且不包协调线程,因此如果不想使用 MTS 应该将这个参数设置为 0,然后 ‘stop slave;start slave’ 才能生效。因为工作线程在启动的时候已经初始化完毕了。 因为我们知道在 5.7 中即便不开启 GTID 也包含的匿名的 GTID Event,它携带了 last commit 和 seq number,因此即便关闭 GTID

技术分享 | 从库 MTS 多线程并行回放(二)

梦想的初衷 提交于 2020-02-25 18:28:49
作者:高鹏 本节包含一个笔记如下: https://www.jianshu.com/p/e920a6d33005 这一节会先描述 MTS 的工作线程执行 Event 的大概流程。然后重点描述一下 MTS 中检查点的概念。在后面的第 25 节我们可以看到,MTS 的异常恢复很多情况下需要依赖这个检查点,从检查点位置开始扫描 relay log 做恢复操作,但是在 GTID AUTO_POSITION MODE 模式且设置了 recovery_relay_log=1 的情况下这种依赖将会弱化。 一、工作线程执行 Event 前面我们已经讨论了协调线程分发 Event 的规则,实际上协调线程只是将 Event 分发到了工作线程的执行队列中。那么工作线程执行 Event 就需要从执行队列中拿出这些 Event,然后进行执行。整个过程可以参考函数 slave_worker_exec_job_group。因为这个流程比较简单,因此就不需要画图了,但是我们需要关注一些点如下: (1)从执行队列中读取 Event。注意这里如果执行队列中没有 Event 那么就进入空闲等待,也就是工作线程处于无事可做的状态,等待状态为 ‘Waiting for an event from Coordinator’。 (2)如果执行到 XID_EVENT 那么说明事务已经结束了那么需要完成内存信息更新操作。可参考

前端工程师做事的三重境界:我的进阶之路

南笙酒味 提交于 2019-11-29 04:02:50
本文转载于: 猿2048 网站 前端工程师做事的三重境界:我的进阶之路 ![v2-fd52450adf6c98b518618bdc74f1520e_r.png](//upload-images.jianshu.io/upload_images/8373224-e56f02b3d4e813e2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240) 写作本文的目的:构建自己关于前端工程师成长过程的认知模型,从自己的视角来分析 Programmer、Developer、Enginner 的能力结构与工程师成长过程的关联,并分享出来给大家,期望能对入门的前端同学有所借鉴和启发。需要提前说明的是,文中用到的工程师的不同叫法并不是要给工程师分类或者贴标签,因为工程师的成长过程是连续的,喜欢钻牛角尖的同学请自行绕路。 ## 程序员 or 工程师 圈内对从事软件开发的同学有很多叫法,如程序员(Programmer)、开发者(Developer)、工程师(Engineer),甚至是码农,“码农”是圈内人用来自嘲的,那其他几个名词呢?表面上看起来都是做软件开发,叫什么真的重要么? 不得不说,叫什么并不重要,不论是自称还是他称,什么学历、几年工作经验也不重要,真正重要的是人所具备的能力。那么既然名称不重要?为什么还要谈论它