MySQL连接配置合并与两阶段提交深入解析

mysql弹出这个界面怎么选择？

我看了一下，大概是MySQL工具主动请求共享其数据库连接信息。
如果您的计算机上安装了MySQLWorkbench和三个产品（MySQLforExcel、MySQLNotifier、MySQLforVisualStudio）之一，这三个产品将主动要求将其数据库连接配置文件与工作台配置文件合并。
您可以延迟此操作一段时间，或者可以永久消除提醒。
合并操作可以手动执行。
我安装了notifier1.1.7。
右键单击任务栏上的小邮件图标，然后选择操作-->选项。
您可以看到一个超宽的按钮“MigratestoredconnectionstoMySQLWorkbenchnow”并在此处执行操作。
如果未安装workbench，这三个工具将使用各自的连接配置，并且不会合并。

一个Kill不掉的MySQL会话

主从切换过程中出现不可杀死的会话。
这是为什么呢？本文由AxonDBA团队秦光飞撰写，深入分析了主从切换中的SessionKill问题。
切换过程包括主库和从库的几个关键动作。
关键是主库杀死剩余连接的时候，有时会记录警告信息：[warning]killprocesswarning:Error1094:Unknownthreadid:4。
经过研究，我们发现切换到MySQL5.7时并不会出现这个警告信息，而是将在MySQL8.0中重新稳定出现。
最后，这个“未知线程ID”被确定为事件调度程序的“连接”。
事件调度程序是MySQL中的一个特殊线程，负责执行事件调度程序创建的事件。
在MySQL5.7中，事件调度器默认关闭，但在MySQL8.0中默认打开。
这就解释了为什么切换到MySQL5.7时没有发现警告信息。
默认情况下，事件调度程序是一个后台守护进程，一直运行到MySQL服务停止为止，检查事件并启动新会话来执行事件。
它不是用户发起的接，因此不能像普通会话一样终止。
了解事件调度器后，我们发现COMMAND值为Daemon，表示后台守护进程。
此类会话由MySQL内部线程控制，无法被常规杀死。
虽然官方文档信息有限，有兴趣的读者可以查看代码进行更深入的理解。
网上有很多关于使用计划任务的信息。
如果需要使用请查看官方文档。
以一个事件为例，简单演示一下效果。
最后说一下来自Axon开源社区的SQLE，这是一款面向数据库用户和管理者的SQL审计工具，支持多场景审计、标准化在线流程、内置支持MySQL审计和可扩展的数据库类型。

深度探究MySQL中的两阶段提交场景mysql两阶段提交场景

深入了解MySQL中的两阶段提交场景。
MySQL是一种广泛使用的关系数据库。
它支持的传统事务模型是ACID（原子性、一致性、隔离性和持久性）模型，其中隔离性是指多个事务。
在利用同一资源时，必须注意确保它们不会互相干扰，即一个事务在执行过程中对其他事务不可见。
在实际应用中，为了解决分布式环境下的数据一致性问题，MySQL引入了两阶段提交协议（Two-PhaseCommit，简称2PC）。
在MySQL中，InnoDB存储引擎支持两阶段提交。
当使用两阶段提交协议时，MySQL将客户端请求的事务分为两个阶段，即准备阶段（PreparePhase）和提交阶段（CommitPhase）。
下面我们将深入探讨MySQL中两阶段提交的实现。
1.准备阶段。
在准备阶段，参与者通知事务协调者（即协调者）是否可以行指定的操作。
在MySQL中，事务协调器是执行提交操作的事务。
在实际应用中，一个事务协调者可能有多个参与者（即执行操作的事务）。
在准备阶段，参与者完成以下步骤：1.执行事务活动并创建重做和撤消日志。
重做日志记录插入、删除、更新等各种操作，用于恢复故障恢复时事务操作的影响。
undo日志记录相反方向的操作，用于撤销回滚过程中事务对数据的影响。
2.向事务协调器发送CanCommit请求。
参与者将向事务协调器发送CanCommit请求，以查看是否允许发送事务。
CanCommit消息格式为：CanCommit(TxID,{writeSet})，其中TxID是事务ID，writeSet是事务所需的操作集合。
3.等待事务协调器的响应消息。
参与者正在等待来自的回复消息事务协调员。
回复消息有两种类型：(1)是：该回复消息表示所有参与者都可以发帖并可以登录。
提交阶段。
(2)否：该响应消息表明任何参与者都被拒绝发送，整个事务必须回滚。
2.提交阶段。
如果在完成准备阶段后，事务协调器响应参与者的响应是肯定的，则进入提交阶段。
在提交阶段，参与者执行以下操作：1.写入重做日志。
参与者将重播日志写入磁盘。
2.提交DoCommit请求。
参与者将向事务协调者发送DoCommit请求，以表明他们已准备好提交。
该请求的格式与CanCommit请求类似，只是将CanCommit改为DoCommit。
3.等待事务协调器的响应消息。
事务协调器收到所有参与者的DoCommit请求后，将执行以下操作：1.写入重做日志。
事务协调器首先将自己的重做日志写入磁盘。
2.向参与者发送PreCommit请求。
事务协调器会向所有参与者发送PreCommit消息，表示已准备好提交，并询问参与者最终数据是否可以写入磁盘。
PreCommit消息的格式与CanCommit消息相同，只是消息类型改为PreCommit。
3.等待参与者的响应消息。
成员收到PreCommit请求后，会执行以下操作：1.写入重做日志。
参与者将预提交操作写入磁盘。
2.提交您的“完成”请求。
参与者收到PreCommit请求后，会向事务协调者发送Done消息，表明已经写入磁盘，可以发送。
Done请求与CanCommit、DoCommit请求类似，只是消息类型改为Done。
3.等待事务协调器的确认消息。
一旦交易协调器收到所有参与者的“完成”请求，它将向所有参与者发送“确认”消息，表明交易已发送。
总结谢谢从上面的分析我们可以看到两阶段归档协议的执行过程。
其中，准备阶段的主要目的是协调所有参与者的活动，确保顺利过渡到提交阶段。
提交阶段的主要目标是就所有参与者何时写入磁盘达成一致，以便保存整个事务。
参考代码://准备阶段publicvoidpreparePhase(longtxID,Listops){//执行事务性操作并创建重做和撤消日志ListundoLogs=newArrayList();ListredoLogs=newArrayList();for(Operationop:ops){undoLogs.add(op.cancel());redoLogs.add(op.redo());}//向事务协调器发送CanCommit请求booleancanCommit=coordinator.canCommit(txID,redoLogs);//等待事务协调器的响应消息if(canCommit){//发送请求DoCommitcoordinator.doCommit(txID,redoLogs);//等待事务协调器的响应消息}else{//回滚事务for(UndoLogundoLog:undoLogs){undoLog.execute();}}}//提交阶段publicvoidcommitPhase(longtxID,Listops){//重做日志条目ListredoLogs=newArrayList();for(Operationop:ops){redoLogs.add(op.redo());}//发送请求DoCommitcoordinator.doCommit(txID,redoLogs);}//事务协调器publicbooleancanCommit(longtxID,Listlogs){//处理请求CanCommitbooleancanCommit=true;for(Participantp:participants){//相锁成员发送CanCommit请求booleanvote=p.canCommit(txID,logs);if(!vote){canCommit=false;break;}}returncanCommit;}publicvoiddoCommit(longtxID,Listlogs){//处理DoCommit请求//写入自己的重做日志ListmyLogs=newArrayList(logs);myLogs.add(newRedoLog(txID,ActionType.COMMIT));log.write(myLogs);//向所有参与者发送PreCommit请求for(Participantp:participants){p.preCommit(txID);}//等待所有参与者的Done请求for(Participantp:participants){p.wtDone(txID);}//向所有参与者发送确认消息for(Participantp:participants){p.ack(txID);}}//参与者publicbooleancanCommit(longtxID,Listlogs){//处理查询CanCommit//判断操作是否可以执行for(RedoLoglog:logs){if(canExecute(log)){returntrue;}}returnfalse;}publicvoidpreCommit(longtxID){//处理PreCommit请求//写入重做日志log.write(newRedoLog(txID,ActionType.PRE_COMMIT)));//向D发送一个请求coordinator.done(txID);}publicvoidwtDone(longtxID){//等待Done请求while(!done){//监听Done请求}}publicvoidack(longtxID){//处理确认消息//发送事务日志.write(newRedoLog(txID,ActionType.COMMIT)));}

MySQL核心模块揭秘|13期|回滚到savepoint

彻底理解MySQL，学习如何实现部分回滚操作。
本文由技术专家曹胜春撰写。
他在公众号“一树一流”上分享MySQL和OceanBase源码研究。
本文基于InnoDB存储引擎MySQL8.0.32，讲解核心模块的工作原理。
首先我们创建一个测试表并插入数据。
关键操作分为四个阶段，编号为SQL1到SQL4，其中SQL4是讨论的重点。
SQL2和SQL3分别生成undo日志0和1，当事务执行时，生成的binlog在trxcache中。
当整个事务回滚时，必须删除这些日志。
然而在实际操作中，Binlog回滚步骤看似简单，但实际上并没有进行清理，而只是为后续的InnoDB回滚做准备。
InnoDB回滚是一个重要的连接。
它基于undo协议执行反向操作，恢复受事务影响的数据。
以SQL为例，回滚是从最新的undolog开始，依次执行反向操作，包括删除记录。
回滚后，需要通过提交事务来更新事务的执行状态。
这与提交语句不同，因为回滚操作更改了数据。
即使逻辑上恢复了原始状态，更改仍然需要正式提交到InnoDB。
InnoDB回滚完成后，trxcache中的binlog日志将被删除。
这个过程涉及内存缓冲区和临时磁盘文件。
Binlog回滚步骤被推迟到这个阶段，因为在事务提交之前Binlog日志不需要写入持久存储。
总结一下，MySQL的一些回滚包括：没有任何实际动作的binlog回滚，执行InnoDB回滚恢复数据，然后提交InnoDB事务，最后清除trxcache中的临时binlog。
如果您对文章内容有任何疑问，欢迎留言沟通。
如果您需要更多SQL质量管理工具支持，可以探索SQLE，这是一个SQL管理平台，涵盖从开发到生产环境，并提供流程自动化和数据质量管理功能。