静态网站 插件,手机号交易网站源码,手机商城模板,电子商务概论知识点简介#xff1a; 近几年#xff0c;随着分布式数据库系统的兴起#xff0c;特别是基于MySQL分布式数据库系统#xff0c;会用到XA来保证全局事务的一致性。众所周知#xff0c;MySQL对XA事务的支持是比较弱的#xff0c;存在很多问题。为了满足分布式数据库系统对XA事务的…简介 近几年随着分布式数据库系统的兴起特别是基于MySQL分布式数据库系统会用到XA来保证全局事务的一致性。众所周知MySQL对XA事务的支持是比较弱的存在很多问题。为了满足分布式数据库系统对XA事务的要求阿里做了大量的工作。 本篇内容将从两部分介绍第一部分介绍在AliSQL分支上做的一些实用功能第二部分介绍XA Crash Safe问题的根源和在5.7和8.0版本上的实现原理。
一、阿里云RDS MySQLAliSQL
AliSQL是MySQL的分支阿里在这个分支上做了很多深度的定制以充分挖掘MySQL的潜力。AliSQL支撑了阿里集团电商业务十余年其稳定性、安全性和高性能是经过了极其严苛实践检验的。除此之外AliSQL做了很多实用性的功能以提高MySQL的易用性和使用效率。下图是AliSQL上重要的功能的列表。 二、RDS定制化功能介绍
1. 实用性SQL Outline 在线固化SQL执行计划
我们使用MySQL的时候时常会碰到一种情况即业务跑着的时候有个SQL执行会变慢分析之后发现是这个SQL执行计划发生了变化。这种变化有很多原因比如bug或是版本升级了等等。
MySQL就提供了hint功能它可以使我们在SQL语句里增加一些提示以保证SQL在生成执行计划的时候是按照提示来工作的。但这只是比较理想化的状态实际情况中这样是很不方便的因为业务已经在线上运行了这个时候即使能够改变业务的SQL也需要一个很漫长的时间和过程。
为了解决这个问题就有了SQL Outline的功能。这个功能不需要改变应用的SQL语句只需要在server端告诉RDS碰到哪种类型的特定的SQL可以给它定制一个hint然后按照用户指定的方式执行。
2. 实用性Performance Agent可诊断、可度量
我们在实例的监控上也做了大量的工作从而可以很容易的分析数据库中的一些问题。首先就是实例级别的统计信息它包括了操作系统层面、server层和InnoDB等共计55个指标。然后把它放到一个Performance表中每秒钟进行一次统计。通过这些统计的信息可以分析系统出现问题的原因。
3. 实用性Performance Insight可诊断、可度量
这个是对象级别性能度量的指标包括表和索引。这些统计可以支持业务数据模型的优化和变更。 还有语句级别的统计信息。MySQL本身具有语句级别统计信息但是它的统计信息不够丰富因此在这个基础上我们又增加了更多实用性的统计信息比如CPU的使用时间加锁消耗的时间等。 MySQL里用了大量的Mutex来保证多线程之间的数据访问我们加了对于Mutex加锁时消耗时间的统计方便对数据库热点的分析。
这些统计信息提供了更充分的数据依据帮助我们做快速的问题定位。
4. 稳定性Buffer Pool优化
在稳定性方面我们也做了大量的工作。首先是Buffer Pool的优化。
云上用户会有临时变配的需求。举个例子在业务高峰时若希望实例临时规格变大过了高峰之后再把规格降下来。MySQL是支持线上的resize但是它的稳定性不够好。在做Online resize对性能的影响还是比较大的。AliSQL针对这个做了优化后可以看到下图蓝色线条是动态变配的波动曲线稳定性好很多。 5. 稳定性Concurrency Control 并发控制
用户常常会碰到几个SQL过来一下子就把实例的CPU打满的情况或者是内存耗光等类似的情况。Concurrency Control并发控制这个功能可以让用户根据实际使用情况对SQL限制执行个数以提高实例整体运行的稳定性。 6. 安全性TDE支持国密SM4
企业级用户对于安全性的要求越来越高对于各种各样的加密、密码强度、生命周期等要求也越来越多。AliSQL在安全这块做了更全面的支持比如对于加密来讲除了支持TDE这种AES的加密算法还支持国密加密算法SM4对于有涉密要求的用户可以用SM4的加密算法来保证数据的安全性。
7. 安全性Recycle Bin防止误删除
当用户在做删除表或是Truncate表的时候使用这个回收站功能并不会把数据文件直接删除掉而是会把这些表放到一个回收站里这样就避免了用户在误删之后数据丢失的风险误删除后还能通过回收站把删除的数据快速找回。
8. 安全性Flashback Query
不仅是表级的误删除当我们对某一些数据更新的范围错误了之后使用Flashback机制可以恢复到更新前的历史版本。同时用户还可以自定义查询某个时间戳的某个数据。
所以Flashback Query对误操作删除恢复或是回档需求是很有效的方法。
9. 高性能Binlog In Redo
对比原生MySQLAliSQL的性能提升很多。首先介绍的是Binlog In Redo功能。众所周知在MySQL里面事务提交的时候需要持久化两次因为要执行两阶段的事务提交过程。这里面做了一个改进即可以把Binlog写到Redo里面这样的话就只需要持久化一次RedologBinlog可以异步刷盘。
通过这种方式用户事务在提交的时候就只需要一次刷盘动作因此时延会降低吞吐量会增大。 上图是基于两个Binlog in Redo版本的测试结果。通过左侧第二个版本的数据我们发现性能会提高很多。对于Update non index来讲可以有大概38%的性能提升。对于write only来讲也可以达到25%的性能提升。
10. 高性能Fast Query Cache
AliSQL针对Query Cache在并发控制、内存管理和缓存机制等等做了大量的优化。
优化之后它的性能提升非常明显。在point select的场景下性能提升甚至可以达到100%以上。通过测试发现在rewrite模式命中率比较低的情况下几乎没有任何性能损失。所以用户在读比较多的场景就可以把Query Cache打开可以保持稳定高效的状态。
11. 高性能DDL Optimization
围绕DDL我们做了大量优化。
用户在使用DDL的时候会发现如果表特别大需要做rebuild或更新数据等操作的时候效率非常低。主要是因为DDL利用Buffer Pool的模型是效率低下的模型。优化之后对于rebuild表的这种操作效率会高很多对于其他SQL语句的影响也会降低很多。
下图是针对Create Index和Optimize Table的测试可以看到优化之后操作都会有10倍以上的性能提升。 三、XA Crash Safe 介绍
1. XA Crash Safe背景
抛开XA Crash Safe本身MySQL本身也有Crash Safe机制。为什么会需要这样的机制呢因为在MySQL里同时包括Binlog和数据两个部分可以理解为存了两份一模一样的数据。为了保证这两份数据的一致性MySQL Crash Safe实现了两阶段提交机制。为了保证Binlog和数据的一致性任何用户的事务都会被转化成为两阶段的事务首先就是进行prepare然后再写Binlog并持久化最后做事务的提交。所以在这两个阶段的提交过程中Prepare、刷Redo、写Binlog和刷Binlog的执行顺序是保持不变的。
如何保证Crash Safe呢这要看它恢复的处理过程。在实际的事务执行过程中只要是Binlog有这个事务一定是Prepare的状态。那么利用这个原则在MySQL Crash重启的时候它会取出所有已经prepare的事务把它们的XID取出来扫描最后一个Binlog文件然后确认XID所对应的事务是否已经存储到Binlog里了。如果已经存储过了就直接提交即可如果还没有存储就回滚掉。通过这个Crash Recovery机制后Binlog里的数据就和引擎里面的数据保持一致了。
对于普通用户事务可以用两阶段来保证Crash Safe那么对于用户的XA事务怎么处理呢
在Binlog里会把这个事务分为独立的两部分当用户执行XA Prepare的时候会写Binlog文件然后把这个Prepare状态执行到引擎里这是完全独立的。用户在XA Commit里可以在任何时间执行当用户在执行XA Commit之后会被再记录一次Binlog所以这两者是完全脱离的。
对于普通的用户事务执行过程只记录一次Binlog而且整个事务是一个基本的单元存在Binlog中的对于XA事务这就是分开的。而且它整个过程是先写Binlog然后才去把状态持久化到引擎中做引擎的prepare。对于MySQL来讲不能保证外部XA事务数据和Binlog的一致性。
也就是说当写完Binlog还没有在引擎中执行prepare和commit这个时候就Crash了那么它起来之后就变成Binlog里有事务记录而在引擎里却丢失了也许只以prepare的状态停留在那里这就没有被提交。
2. XA Crash Safe基于MySQL 5.7的修复
1调整执行顺序
为了更好的支持分布式数据库系统在MySQL 5.7的时候阿里就做过对于XA Crash Safe的修复。这个修复是把执行顺序做了颠倒即先执行引擎的Prepare再写Binlog这样它就跟普通事务的过程一样了。在Prepare之后做Crash如果用户的XA事务做了Prepare之后没有记Binlog那么数据就会被回滚掉。但是由于XA事务跟普通事务不太一样需要更多处理来支持回滚而且它也不是一个完善的方案。因为用户具有多样性比如用户执行了一个事务但是并没有记Binlog这个时候就没法区分是否记录了Binlog。另外XA事务的Prepare和Commit是分开的当用户将Prepare事务记录到很久以前的Binlog里了也不能区分用户是否记录了Binlog。
这种情况下就需要一个解决方案即在做Binlog rotation时候要把所有Prepare事务的XID记录到Binlog中。这样我们就可以通过最后一个Binlog去了解所有Prepare状态的XID然后就可以通过Rollback的方式保持Binlog和数据的一致性。
2调整Recovery逻辑
Commit执行了另外一种逻辑即先执行Binlog在执行后发现事务是Prepare状态且在Binlog中记录了Commit或Rollback那么执行Commit或Rollback。
这就是MySQL 5.7上XA Crash Safe的修复的过程。
3. XA Crash SafeMySQL 8.0 Gtid和事务的一致性
MySQL 8.0采用了另外一种方法。介绍这个方法之前首先介绍下MySQL 8.0 Gtid和事务的一致性。在MySQL8.0.17的时候引入克隆功能这个功能可以把Gtid记到事务的undo里。记到Undo里的过程也很简单在Prepare的时候还是先记Binlog然后引擎里做事务Prepare的时候去监测这个事务是否有Gtid。如果有在修改事务状态时会连通Gtid一起写到Undo里。如果Crash之后Prepare丢了那么Gtid一定也是不存在的反之亦然。在Commit的时候也同理。这样做克隆的时候用户使用起来就会非常简单。
但是Rollback是个特例尤其是对于XA事务来说。Rollback也会记录一个Gtid。Rollback在引擎里的做法是把事务状态改成active之后就会自然回滚所以在active的时候它也会记一个Gtid所以XA Rollback会记录Binlog也会产生Gtid。整个操作也是原子的。
Gtid最终会持久化到Gtid_executed表里。之所以要做汇总是因为Undo本身需要Purge否则会越来越大而且检索效率也非常低。所以虽然在Prepare后会放进Undo里但是实际上最后都会汇总到Gti_executed表中然后会有一个单独的Gtid Flush的线程它会周期性的把Gtid list里的Gtid写到Gtid_executd表中。写到表后只需要持续化整个表后undo就可以丢掉了这样始终会有一个完整的Gtid集合。 对于外部XA事务会记录两个Gtid一个是Prepare的时候一个是Commit的时候。最初实现这个功能的时候只会记录一个Gtid也就是说在commit的时候会把prepare的给覆盖了。这就要求在Commit之前需要把Prepare的Gtid持久化到Gtid executed表里效率非常低。后来官方优化成将两个Gtid分别存在两个位置这就大大提高了效率。
经过以上的优化之后我们可以看到Gtid和事务数据之间的关系是Gtid Executed表中的Gtid代表了InnoDB中已经执行了的事务的Gtid。这两者之间是原子对应的关系。
通过这样的对应关系我们可以在系统启动的时候做Apply Binlog这样的操作来保证外部XA事务的Crash Safe。 根据Gtid Executed表中的Gtid就可以知道哪些事务在引擎里存在然后通重放Binlog里的事务将引擎里的数据补齐。通过这样的方式不需要修改过添加Binlog Event原来的recover过程也不需要变化。只需要在recover之后检查Gtid Executed的表然后对比Binlog。将缺少的事务重新Apply一下就可以了这样就可以保证XA事务的Crash Safe。
原文链接 本文为阿里云原创内容未经允许不得转载。
