首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >【 腾讯云的1001种玩法 】腾讯云数据库优化最佳实战:以 TXSQL 为例

【 腾讯云的1001种玩法 】腾讯云数据库优化最佳实战:以 TXSQL 为例

原创
作者头像
musazhang
修改于 2017-09-11 03:27:27
修改于 2017-09-11 03:27:27
4K20
代码可运行
举报
文章被收录于专栏:musazhang的专栏musazhang的专栏
运行总次数:0
代码可运行

引言

TXSQL-Tencent MySQL 自从2016年5月份正式立项,在近一年的时间里对 MySQL 的读写性能、强同步、大并发量访问和稳定性等方面做了大量工作,读写性能在并发上升到一定程度时具有1倍以上的性能提升,同时在 TXSQL 的版本发展过程中修复了多个影响线上稳定性的 bug(如 redo 死锁,实例异常关闭、字符集引起的主备异常等),在保证了内核稳定的同时,对腾讯云的稳定性提供了有力的保障。 TXSQL 不仅提升了实例性能与稳定性,而且在发展的过程中积极和社区进行交流,在 DBAPlus 等社区发表了多篇具有影响力的文章,并作为演讲嘉宾,多次参与 ACMUG、DTCC、DBAPlus、开源中国和 InfoQ 全球架构师峰会等社区会议,大大提升了腾讯云在业界的影响力,赢得了客户的信任与口碑。

什么是 TXSQL,为什么要做 TXSQL ?

TXSQL 是 Tencent MySQL 的简称,是 TEG 基础架构部CDB (Cloud DataBase) 团队在近十年发展过程中衍生出来的一个对 MySQL 内核源码深度定制、对官方 MySQL 版本进行二次开发的项目。其主要目的是在保证线上稳定性的同时,满足业务对数据库的各种需求。TXSQL 的服务对象是公司内部用户和腾讯云上小至数G大至数百T的外部客户。TXSQL 是支撑这些业务平稳运行的关键基石,在服务用户的同时,以打造腾讯自己的MySQL分支为己任。

MySQL 作为最受欢迎的开源数据库,也是云上使用最多的数据库,不同的业务场景对数据库有不同的功能需求与性能需求,这样就决定了数据库本身的多样化需求,同时 MySQL 在不同使用场景下所衍生出来的各种问题,也影响着线上的稳定性,TXSQL 主要包括以下工作:

  • 数据库性能调优;
  • 对内核进行深度改造,满足应用需要的性能要求,在活动促销时需要保证数据库的平稳;
  • 提供业务需要的各种功能需求;
  • 实现资源管理需要内核支持的功能;
  • MySQL DBA 在运维过程中需要的诊断相关的功能;
  • MySQL 在运行过程中存在的问题定位并修复影响系统运行的 Kernel Bug;
  • 保证数据库系统的安全,保证云上用户数据的安全;

做为云上客户的服务者,我们必须有及时响应用户并解决各种问题的能力,也应该满足用户的各种合理要求,对内支持业务的快速发展,满足业务要求;对外为腾讯云提供强有力的竟争力,这就是 TXSQL 存在与发展的目的。

TXSQL 做了哪些事情

版本选择

其基准开发版本为 5.6.28, 选择 5.6.28 做为基准版本主要有以下原因:

  • 5.6.28 是当时大版本 5.6 中的最新版本,自 5.6.10 GA (General Availability) 以来,版本已经相当稳定;
  • 5.7 版本刚刚 GA, 但从官方 buglist 上来看有相当多的 serious bugs,因此未被采用,在现在看来选择 5.6.28 也是正确的,因为从 5.7 版本的 release notes 来看,除了 Group replication 是新加入的功能,其它内容基本是 bugfix 相关;虽然 5.7 存在着各种问题,但其新添加的功能 & 卓越的性能都会是未来 2-3 年的主流选择,我们也计划在今年对 5.7 进行支持,并且会对 5.7 新添加的功能 & 性能改进进行详细的源码级别的介绍。
  • 5.6 版本是接受程度最高的 MySQL 版本,也是用户使用最多的数据库版本;

    综合以上原因,我们选择了 5.6.28 做为 TXSQL 开发的基准版本。

性能改进

read view 优化

read view 又称读视图,用于存储事务创建时的活跃事务集合。当事务创建时,线程会对 trx_sys 上全局锁,然后遍历当前活跃事务列表,将当前活跃事务的ID存储在数组中的同时,记录最大事务 low_limit_id & 最小事务 high_limit_id & 最小序列化事务 low_limit_no。 当事务执行时,凡是大于low_limit_id 的数据对于事务是不可见的,凡是事务小于 high_limit_id 的数据都是可见的,事务 ID 是 read_view 数组中的某一个时也是不可见的;Purge thread 在执行 Purge 操作时,凡是小于 low_limit_no 的数据,都是可以被 Purge 的,read view 是 MySQL MVCC 实现的基础;

由于read_view 的创建和销毁都需要获取 trx_sys->mutex, 当并发量很大的时候,事务链表会比较长,又由于遍历本身也是一个费时的工作,所以此处便成为了性能瓶颈,详情可以参考 bug#49169,为了解决这个问题 TXSQL 做了以下事情:

  • 在 trx_sys下维护一个全局的事务ID的有序集合,事务的 创建 & 销毁 的同时将事务的 ID 从这个集合中移除;
  • 在 trx_sys下维护一个有序的已分配序列号的事务列表,已记录拥有最小序列号的事务,供 purge 时使用;
  • 减少不必要的内存分配,为每一个 trx_t 缓存一个 read_view,read_view 数组的大小根据创建时的活跃全局事务 ID 集合做必要的调整;
  • 参照 5.7 的实现,在 5.6 中将 ro_trx_list 移除,减少只读视图的长度;

经过上述修改,读写性能都有很大的提升,详情可以参考文章 畅游数据库性能优化过程简析

redo log group commit

MySQL 有两种很重要的 Log,分别为 redo log & binlog,前者是保证事务原子性操作所产生的日志,后者是主备数据同步所产生的同步日志。 其中 binlog 在 ordered_commit 时进行 group commit, 而 redo log 则是在事务提交的时候分别调用 trx_prepare 使 redo log 落地,导致 log_sys->mutex 竟争较为严重;从 crash recovery 的逻辑来看,只要 redo log 早于 binlog 落地,就不会有数据问题,因此在 ordered_commit 的第一阶段时,TXSQL 会收集各种引擎的最大的 redo log LSN,然后将小于该 LSN 的 redo log 落盘,从而提升写性能。更详细的分析与测试,可以参考 bug#73202

redo log 双缓冲区

MySQL redo log 是一个顺序写的单缓冲区,log_sys->mutex 锁资源竟争激烈,在事务落盘的过程中对 LSN 相关的读、写都被阻塞,为了解决 log_sys->mutex 的锁竟争问题,引入双缓冲区机制 & w_mutex 锁,在 flush redo log 的过程中释放 log_sys->mutex,继续持有 log_sys->w_mutex,从而阻塞写,不阻塞 LSN 相关的读操作,flush 完成后释放 w_mutex;从而提升并发性,提升性能。

adaptive hash index 锁拆分

MySQL 一次定位 cursor 的过程是从根结点到叶子结点的路径,时间复杂度为:height(index) + [CPU cost time],上述的两个优化过程无法省略定位 cursor 的中间结点,因此需要引入一种可以从 search info 定位到叶子结点的方法,从而省略根结点到叶子结点的路径上所消耗的时间,而这种方法即是 自适应索引(Adaptive hash index, AHI)。查询语句使用 AHI 的时候有以下优点:

  • 可以直接通过从查询条件直接定位到叶子结点,减少一次定位所需要的时间;
  • 在 buffer pool 不足的情况下,可以只针对热点数据页建立缓存,从而避免数据页频繁的 LRU;

AHI 的 btr_search_latch (bug#62018) & index lock 是 MySQL 中两个比较大的锁,详情可以参考 Index lock and adaptive search – next two biggest InnoDB problems,5.7 通过对 AHI 锁拆分 (5.7 commit id: ab17ab91) 以及引入不同的索引锁协议 (WL#6326) 解决了这两个问题。但是 AHI 并不总能提升性能,在多表Join & 模糊查询 & 查询条件经常变化的情况下,此时系统监控 AHI 使用的资源大于上述的好处时,不仅不能发挥 AHI 的优点,还会为系统带来额外的 CPU 消耗,此时需要将 AHI 关闭来避免不必要的系统资源浪费,关于 AHI 的适应场景可以参考:mysql_adaptive_hash_index_implementation

TXSQL 则是和 5.7 的解决思路类似,只是使用的分区算法不同,关于自适应索引的详细说明可以参考:MySQL AHI 实现解析

当然,以上这些只是我们所做优化的一部分,还有其它一些优化如 GTID 优化、强同步优化、针对业务所做的特殊优化等,这些优化都在线上发挥了不可小觑的作用,以后再以文章的方式一一给大家进行介绍。

功能添加

TXSQL 支持多种工作模式

TXSQL 根据配置的不同,支持不同的工作模式,分别为只读、读写、不可服务,在不同的模式下实例表现形式不同:

  • 只读模式:实例只接受读请求,不接受非管理用户的写请求操作;
  • 读写模式:实例可以接受读写请求,但系统管理的相关权限被禁用;
  • 不可服务模式:此模式下,MySQL 正常运行但不接受除管理账号以外的其它操作;

    OSS 在实现跨园区容灾的时候会根据结点的角色设置不同的工作模式,从而避免双写的问题;

alter table ... nowait 功能

DDL 在执行过程中需要获取对应的表锁,然后进行操作,如果此时有事务获取表锁,则会造成此语句的阻塞,而后绪操作此表的请求也会被此 DDL 阻塞,因此我们引入了 Oracle 中的 alter table 超时失败的功能,即 alter table .... [nowait | wait for n] 的功能以降低 DDL 对线上的影响,oracle 中 select for update [nowait|wait for n] 则可以通过设置参数 innodb_lock_wait_timeout 来实现;

TXSQL 锁系统的扩展

MySQL 锁系统有两个特征:

  • MYSQL 中的锁与连接强依赖,在连接断开之后便会释放其占有的锁资源,包括 server 层 & engine 层的所有锁资源;
  • 用户线程获取锁之后,如果没有显示释放锁资源,连接没有断开亦或事物没有提交,则会一直占有锁资源;

TXSQL 对 MySQL的锁系统进行了扩展,实现了一种跨事务的、与连接无关的租约读写锁,用于应用层实现分布式事务,提供接口 cdb_lock, cdb_unlock 用于上锁与解锁请求,从而满足业务需求,详细接口介绍如下:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
int cdb_lock(string key, int type, uint64_t wait_timeout, uint64_t hold_timeout);
  多用户对同一个锁对象key加锁,会在加锁超时前等待。直到获取到锁或者超时返回。
  锁类型目前支持两种,共享锁和排它锁。共享锁是读锁,允许多个客户端对锁key加共享锁。排它锁是写锁,同一时刻只允许一个请求占有排它锁,其他请求需要等待锁释放。排它锁比共享锁有更高优先级,防止过多的共享锁等待情况下,排它锁长时间无法获取。
  同一个锁持有者对同一锁key发起多次加锁,会认为重复加锁,相同锁发起者同一时刻只能对同一锁key成功发起一次。
  获取的锁,不会因为连接断开而释放。锁持有时间是有指定的,超过持有时间以后锁会自动释放。

int cdb_unlock(string key);
  主动锁释放。会对指定锁key的持有者释放锁,只有在锁持有情况下才会成功。

基于 semi-sync 的强同步

原生 semi-sync 存在着以下问题:

  • semi-sync 在时间超过 rpl_semi_sync_master_timeout 会退化为异步;
  • 采用 select 进行监听,当句柄值大于 1024 时则会出现异常,详情可参考 bug#79865;
  • 在 after commit 后等待 ACK 容易出现幻读的问题;
  • ...

为了解决上面的问题并对强同步进行优化及显示状态信息,TXSQL 做了以下事情:

  • 优化半同步,增加ack线程,收发并行化;
  • 修正select时fd超过1024导致异常的bug,改为poll;
  • 优化dump线程判断自身是否为半同步的方法:在线程自身变量上记录;
  • 在半同步基础上实现强同步,一直hold住直到收到ack;
  • 修改同步方式时,唤醒正在等待的用户线程,继续等待或者退出;
  • 增加一些状态,用于展示当前等待的情况(正在等待的binlog位点,已等待时间);

这些只是我们暂时做的,在以后的版本中,我们将会引入 thread pool、更完善的审记、防火墙等内部用户 & 云用户都需要的功能,随着时间的积累与版本的推移,TXSQL的功能将会越来越丰富。

稳定性改进与测试

稳定性是数据库服务首先要解决的问题,原生 MySQL 在稳定性方面存在着以下问题:

  • 在压力持续增大的过程时,会存在着内存分配的问题,原生 GCC 在内存分配的过程中会调用 __lll_lock_wait_private,在并发量加大且线程数量变化较大时,内存分配会造成系统性能的抖动,详情可以参考: Impact of memory allocators on MySQL performance MySQL performance: Impact of memory allocators (Part 2);
  • 随着并发的加大,由于原生 MySQL 没有流量控制或者 Server 层线程调度的功能,导致线程之间资源争夺比较剧烈,直接导致 MySQL 性能的不稳定,性能曲线先升后降;
  • innodb buffer pool 刷脏算法在 IO bound 类型时,很容易成为瓶颈;
  • 主备同步时备库性能过低导致的延迟问题等;
  • MySQL 各个版本在实现的过程中存在的 bug, 如 redo log 死锁, 典型的字符集问题、MySQLD normal shutdown 等;
  • ...

TXSQL 在服务业务的过程中不断的自我完善和发展,解决在发展过程中遇到的各种问题,如:

  • 解决在线上遇到的各种 内核bug;
  • 引入 jemalloc 解决内存分配的效率问题;
  • 对复制线程进行改进,减缓主备延迟;
  • 引入 thread pool 在 server 层进行线程高度,从而避免过多资源浪费在资源争夺等(内测中...);
  • 实现 OSS 需要的功能,结合 zookeeper 实现强一致功能等;
  • ...

为了保证版本稳定性,TXSQL 对每一个 Patch 都有对应的 testcase 文件和覆盖率测试,对于比较重要的改动,不仅要有理有据,还会邀请 Oracle 官方人员进行必要的 Code Review; 每个小版本发布之前,都会进行回归测试、覆盖率测试、稳定性测试、性能测试以及压力测试,然后才会进行灰度发布;当然,对于每一次的版本发布,都有详细的 release notes 以供参考。

金融业务支持

数据的可靠性是金融业务必然的需求,由于 MySQL 自身存在的问题,很难保证数据的强一致性,这些问题包括:

  • MySQL 是典型的两段提交,在 Crash 的过程中依赖 binlog 是否存在 决定事务的 commit 或 rollback,对于已经写 binlog 的事务,一定会提交事务,这样在主备切换后容易出现双写的问题;
  • 当 rpl_semi_sync_master_wait_point=after_commit 时,主备切换时存在着幻读问题,当 rpl_semi_sync_master_wait_point=after_sync,如果用户线程在等待备库 ACK 的过程中被 kill, 那么其它用户线程可以看到被 kill 线程的提交,此时主备切换,仍然存在着幻读问题;
  • 当 rpl_semi_sync_master_wait_point=after_sync 时,用户线程在 binlog 切换时容易出现死锁问题 (bug#68250), 详情如下:
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
T1  (user thread)                    .........   rotate(holding Lock_log, waiting for xids decrease to be zero)                
T2  (user thread)                    .........   after_sync, wait for ACK from slave
T3  (binlog sender thread)           .........   requesting for Lock log to send binlog

为了解决上述问题并实现主备数据的强一致,TXSQL 结合 CDB 管控平台针对金融业务的需求,实现了以下特性:

  • 为了规避幻读,强同步插件在线程等待 ack 的过程中,禁止用户 kill 线程,同时本地 agent 会通过实例状态变量 rpl_semi_sync_master_tx_cur_wait_time 监控是否出现长时间 hang 问题,触发告警和 HA 操作,减少 hang 住对实例的影响;
  • 本地 agent 在主库 crash 后,会向 OSS 获取故障切换时的 binlog 位点信息,并以这个位点启动实例,TXSQL 将截断多余的 binlog,并回滚相应事务,与新主库建立主从,确保可以快速补充节点;
  • 跨园区高可用的支持。MySQL 是常见的 HA 架构:由本地 agent 负责监听 MySQL 实例,如果实例出现故障,则上报总控节点 scheduler,scheduler 选择拥有最多数据的 slave,将其提升为 master,并更新接入层的 RS 为新 master。在跨园区环境中,如果主库所在园区故障,OSS HA 时可能无法更新该园区的接入层,而该园区的 client 依然能够操作原主库,导致出现双写的问题,为了规避网络分区情下的双写问题,TXSQL实现了租约功能,租约过期的实例将拒绝服务。本地 agent 只有成功向 scheduler 续租后,才会更新实例的租约,确保实例的租约小于scheduler,从而解决双写问题;
  • 对主库 Lock_log 进行拆分,解决死锁的同时提升主库写性能;

除了数据强一制的支持,TXSQL 还实现了一套与连接无关的分布式锁来支持业务部门实现分布式事务,后绪随着对业务的深入,更多更好的金融特性将会在 TXSQL 中一 一实现,比如热点更新等;

版本表现

TXSQL 的首要发展目标是解决线上存在的问题并支持业务的稳健发展,同时在解决问题的过程中推动 TXSQL 自身的发展。

在近一年的发展过程中 TXSQL 共发布了 3 个版本,分别为 TXSQL_20160730、TXSQL_20160902 以及 TXSQL_20161130 版本,每个版本包含若干 issue,每个 issue 的紧迫程度决定其优先级,每一次版本发布都会对新版本的实例做严密的监控,以保证新版本的稳定性。下面我们从版本在线上的表现以及与官方数据的性能对比来对 TXSQL 做简单的介绍。

线上业务表现

  • TXSQL_0730 引入业界先进思想并 Fix bug#49169,成功解决了业务在高并发下的性能下降问题,并支持业务在大压力下的稳定运行,详情可参考之前的文章:[ 畅游数据库性能优化过程简析
  • TXSQL_0902 版本对 redo log 做了必要的优化并对写 redo log 的代码 (log_write_up_to) 进行了重构,使写性能得到了一定的提交,在与竟品的性能测试 & 压力测试 (长时间的进行压力测试且数据不能出现抖动) 的对比过程中脱颖而出,对 B 站在腾讯云上的最终落户起到了一定的积极作用;同时通过租约控制 TXSQL 的在线/离线模式,规避双写,满足跨园区需求;
  • TXSQL_1130 版本除了必要的优化外,Fix 了影响较为广泛的字符集问题、MySQL normal shutdown 问题,使得线上的稳定性得到提升;
  • ...

TXSQL 与官方性能测试对比

TXSQL_0228 版本目前处于开发状态,所以我们选取了 TXSQL_20161130 版本与 TXSQL 的基准版本 MySQL 5.6.28、MySQL 5.6 的最新版本 5.6.35 以及 MySQL 5.7 的最新版本 5.7.17 做了性能对比,测试机器为 ts85, 测试详情如下:

测试说明

测试概况:测试结果为 sysbench 端统计出来的数据,其中 select.lua & update_index.lua 为单语句事务, oltp.lua 中包含10 个SQL语句,配置文件为:my.cnf,测试数据为 100个表,每张表 10000条数据;

TXSQL 与各版本 select.lua 性能对比

TXSQL 与各版本 update_index.lua 性能对比

TXSQL 与各版本 oltp.lua 性能对比

从测试的过程与测试结果来看,TXSQL 不仅拥有更好的性能,还拥有更好的稳定性,在新的 ideas 不断实现的基础上,我们对 TXSQL 的表现拥有更多的期待。

TXSQL 的发展必然也应该是开放的,其特性来源并服务于用户,当版本内容丰富到一定程度时,我们会把 TXSQL 中不影响线上安全 & 非专利部分的代码进行开源,在没有开源之前,可以将安装包提供给公司内部有兴趣的同学进行对比测试,以增加大家对 TXSQL 的了解与支持。

关于 TXSQL 5.7

MySQL 5.7 自 GA 以来已经有1年有余,社区 & 用户的呼声也越来越高,TXSQL 会在今年上半年增加对 5.7 的支持,同时会对 5.7 的特性进行详细的分析以飨大家,另外在阅读代码 & 文档的过程中,笔者做了一些整理,希望对大家理解 5.7 有帮助;

其实,我们在 TXSQL 5.6 中做了很多 5.7 的事情,如 redo log 优化、read view 创建优化等,在新的 TXSQL 5.7 中,我们会有更多可以做的事情,比如执行计划缓存、比如写优化、再比如基于于 Group Replication 服务等等,我们相信 TXSQL 5.7 会是一个不俗的版本。

TXSQL 未来的发展发向

TXSQL 的发展只是刚刚起步,相比 percona, facebook 等这样的公司我们做的还远远不够,还有很多需要改进的空间,但路总是一步步走出来的,我们的差距也在讯速的缩小,在未来的发展过程中 TXSQL 仍然会以云用户为导向从以下方面不断的进行改进:

  • 功能开发,以业务需求为出发点,实现业务所需要的各种功能,如审记、防火墙等;
  • 性能优化,在保证稳定性的前提下不断提升单机性能,并根据业务特性有针对性的进行优化,如热点更新、多语句提交等;
  • 提高内核的抗风险能力,提升对烂SQL、索引异常、流量异常等异常的防范能力,在不修改应用的前提下,保证系统的稳定运行;
  • 兼容并包,不断加强与开源社区的联系,并引入 TXSQL 需要的功能或性能 patch,并将有价值的 Patch 提交至官方;
  • 以线上稳定为基础,不断提升内核能力的同时,实现运维需要的各种功能,方便运维兄弟;

所以,大家在使用数据库的过程中如果有好的想法或者需求也可以和我们联系,我们会尽最大的努力来满足大家的需求,支持业务的发展。

最后打个广告,数据库是一个很有吸引力的领域,数据库内核研发和算法、操作系统、文件系统、体系结构等有着很多的联系,如果你对数据库有着浓厚的兴趣、对数据库的原理比较清楚、又有着比较好的 C 或 C++ 的基础,最重要的,你有挑战各种困难的勇气,那么你就是我们要找的人,没有专业限制、没有条条框框,我们将会一起努力,见证 TXSQL 在云上的魅力!

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
2 条评论
热度
最新
对TXSQL的初学者来说很有帮助。
对TXSQL的初学者来说很有帮助。
回复回复点赞举报
作者对TXSQL的解释十分到位 ,可是看作是 TXSQL 的功能操作指南
作者对TXSQL的解释十分到位 ,可是看作是 TXSQL 的功能操作指南
回复回复点赞举报
推荐阅读
编辑精选文章
换一批
从TencentDB for MySQL到CynosDB的演进
随着腾讯云业务高速发展以及 MySQL 生态的演进,TencentDB for MySQL迎来了最快增速的时代,通过参与开源协同,TencentDB for MySQL 团队从服务、管控、内核和架构等几个维度,不断夯实稳定性、降低成本、丰富 DBaaS 产品功能,为公司自研业务和腾讯云客户提供不断进步的 MySQL 生态数据库产品服务。 1 PartⅠ 最美年代遇到的最大挑战 随着性能与稳定性的不断提高,腾讯云数据库 TencentDB for MySQL 在近两年得到了快速发展,实例个数、行业覆盖率、业
腾讯云数据库 TencentDB
2020/01/13
1.1K0
从TencentDB for MySQL到CynosDB的演进
张青林:TXSQL是什么?云计算时代数据库核弹头
腾讯MySQL内核研发专家张青林在腾讯“云+未来”峰会的「开发者专场」做了主题为“TXSQL:云计算时代数据库核弹头”的技术内容分享,本次分享从五个方面介绍TXSQL:
腾讯云开发者社区
2018/05/25
2.7K2
张青林:TXSQL是什么?云计算时代数据库核弹头
MySQL实战45讲 笔记
不要小看一条 update 语句,在生产机上使用不当可能会导致业务停滞,甚至崩溃。
OwenZhang
2021/12/08
7460
MySQL实战45讲 笔记
mysql如何保证redolog和binlog的一致性,安全性,效率。
http://dwchaoyue.blog.51cto.com/2826417/1784509
保持热爱奔赴山海
2019/09/17
1.4K0
MySQL内核大牛解密腾讯数据库关键技术点
本文嘉宾:赖铮,腾讯TEG基础架构部数据库团队专家工程师,负责腾讯TXSQL数据库内核的研发,数据库系统开发老将,专注数据库内核开发十余年,先后就职于达梦、Teradata、北大方正以及MySQL InnoDB存储引擎团队,是达梦数据库内核、方正XML数据库以及InnoDB的GIS支持,加密功能的主要开发者,并获得多项数据库领域的专利。 本文是腾讯TEG基础架构部数据库团队专家工程师赖铮在腾讯云与3306π联合举办的数据库技术沙龙上的演讲实录。 ---- 今天分享时长四十分钟左右,详细解释腾讯云数据库内
腾讯云数据库 TencentDB
2019/10/30
1.9K0
MySQL内核大牛解密腾讯数据库关键技术点
腾讯研发专家:TXSQL如何成为云计算时代数据库核弹头?
背景:5月23-24日,以“焕启”为主题的腾讯“云+未来”峰会在广州召开,广东省各级政府机构领导、海内外业内学术专家、行业大咖及技术大牛等在现场共议云计算与数字化产业创新发展。 腾讯MySQL内核研发
腾讯技术工程官方号
2018/05/30
1.2K3
腾讯云 CDB 内核特性与优化实践
腾讯云开发者社区
2017/05/03
3.2K0
半同步复制after_sync模式下的一则客户端断开问题分析
众所周知,MySQL5.7对于半同步增强的其中一个部分是对ack确认动作的改进。在5.6下的半同步的ack确认是在storage commit之后,这就带来了两个问题
用户1278550
2019/08/16
1.3K1
【阿里年薪百万数据库面试】MySQL会丢数据吗?
WAL机制保证只要redo log和binlog保证持久化到磁盘,就能确保MySQL异常重启后,数据可以恢复。
JavaEdge
2021/12/07
2.9K0
【阿里年薪百万数据库面试】MySQL会丢数据吗?
腾讯黑科技:删大表不抖动,自动补充虚拟隐藏主键
☆  点击▲关注 腾讯云数据库 ☆ ---- 2019年9月,腾讯云数据库正式按地域发布TXSQL 5.7-201908版本,该版本主要实现写性能提升,新增功能特性和内核参数,为MySQL提供更稳定、高效的性能和服务能力。其中,新增特性包括DROP大表操作异步化、GTID复制功能扩展、隐藏主键功能、非 Super 权限用户 Kill 链接的功能等。另外,在最新的TXSQL内核版本中,可以通过内核参数来指定事务调度算法。下面将为大家详细解读。 TXSQL的演进之路 相信大家对腾讯云数据库Tence
腾讯云数据库 TencentDB
2019/09/10
1.6K0
腾讯黑科技:删大表不抖动,自动补充虚拟隐藏主键
畅游数据库性能优化过程简析(下)
该文总结了近期技术社区内出现的一些问题及解决方案,包括数据库选型、引擎优化、事务隔离级别、高可用架构设计等方面。此外,文章还对未来的一些技术方向进行了展望。
musazhang
2017/06/19
1.9K0
备库为什么会延迟好几个小时?
之前的文章谈到的事故原因,不论是偶发性的查询压力,还是备份,对备库延迟的影响一般是分钟级的,而且在备库恢复正常以后都能够追上来。
JavaEdge
2021/10/18
4620
mysql 谈谈innodb存储引擎
5.7版本引入了模式自动转换的功能,但该语法依然保留了。 另外一个有趣的点是,在5.7版本中,你可以通过设置session_track_transaction_info变量来跟踪事务的状态,这货主要用于官方的分布式套件(例如fabric),例如在一个负载均衡系统中,你需要知道哪些 statement 开启或处于一个事务中,哪些 statement 允许连接分配器调度到另外一个 connection。只读事务是一种特殊的事务状态,因此也需要记录到线程的Transaction_state_tracker中。 关于Session tracker,可以参阅官方WL#6631。 START TRANSACTION READ WRITE 和上述相反,该SQL用于开启读写事务,这也是默认的事务模式。但有一点不同的是,如果当前实例的 read_only 打开了且当前连接不是超级账户,则显示开启读写事务会报错。 同样的事务状态TX_READ_WRITE也要加入到Session Tracker中。另外包括上述几种显式开启的事务,其标记TX_EXPLICIT也加入到session tracker中。 读写事务并不意味着一定在引擎层就被认定为读写事务了,5.7版本InnoDB里总是默认一个事务开启时的状态为只读的。举个简单的例子,如果你事务的第一条SQL是只读查询,那么在InnoDB层,它的事务状态就是只读的,如果第二条SQL是更新操作,就将事务转换成读写模式。 START TRANSACTION WITH CONSISTENT SNAPSHOT 和上面几种方式不同的是,在开启事务时还会顺便创建一个视图(Read View),在InnoDB中,视图用于描述一个事务的可见性范围,也是多版本特性的重要组成部分。 这里会进入InnoDB层,调用函数innobase_start_trx_and_assign_read_view,注意只有你的隔离级别设置成REPEATABLE READ(可重复读)时,才会显式开启一个Read View,否则会抛出一个warning。 使用这种方式开启事务时,事务状态已经被设置成ACTIVE的。 状态变量TX_WITH_SNAPSHOT会加入到Session Tracker中。 AUTOCOMMIT = 0 当autocommit设置成0时,就无需显式开启事务,如果你执行多条SQL但不显式的调用COMMIT(或者执行会引起隐式提交的SQL)进行提交,事务将一直存在。通常我们不建议将该变量设置成0,因为很容易由于程序逻辑或使用习惯造成事务长时间不提交。而事务长时间不提交,在MySQL里简直就是噩梦,各种诡异的问题都会纷纷出现。一种典型的场景就是,你开启了一条查询,但由于未提交,导致后续对该表的DDL堵塞住,进而导致随后的所有SQL全部堵塞,简直就是灾难性的后果。 另外一种情况是,如果你长时间不提交一个已经构建Read View的事务,purge线程就无法清理一些已经提交的事务锁产生的undo日志,进而导致undo空间膨胀,具体的表现为ibdata文件疯狂膨胀。我们曾在线上观察到好几百G的Ibdata文件。 TIPS:所幸的是从5.7版本开始提供了可以在线truncate undo log的功能,前提是开启了独立的undo表空间,并保留了足够的 undo 回滚段配置(默认128个),至少需要35个回滚段。其truncate 原理也比较简单:当purge线程发现一个undo文件超过某个定义的阀值时,如果没有活跃事务引用这个undo文件,就将其设置成不可分配,并直接物理truncate文件。 事务提交 事务的提交分为两种方式,一种是隐式提交,一种是显式提交。 当你显式开启一个新的事务,或者执行一条非临时表的DDL语句时,就会隐式的将上一个事务提交掉。另外一种就是显式的执行“COMMIT” 语句来提交事务。 然而,在不同的场景下,MySQL在提交时进行的动作并不相同,这主要是因为 MySQL 是一种服务器层-引擎层的架构,并存在两套日志系统:Binary log及引擎事务日志。MySQL支持两种XA事务方式:隐式XA和显式XA;当然如果关闭binlog,并且仅使用一种事务引擎,就没有XA可言了。 关于隐式XA的控制对象,在实例启动时决定使用何种XA模式,如下代码段: if (total_ha_2pc > 1 || (1 == total_ha_2pc && opt_bin_log)) { if (opt_bin_log) tc_log= &mysql_bin_log; else tc_log= &tc_log_mmap; }
Java架构师历程
2018/09/26
1.8K0
mysql 谈谈innodb存储引擎
数据库原理——主从复制
同时处于执行状态的所有事务,是否可以并行? 不可以。因为多个执行中的事务是由可能出现锁冲突的,锁冲突之后会产生锁等待问题。
全栈程序员站长
2021/05/21
7730
数据库原理——主从复制
Percona server与腾讯云cdb热点更新性能压测
鉴于有赞业务迅速发展,对于秒杀场景有比较强烈的需求,当前我们的自建数据库使用Percona Server 5.7.22 版本,在应对快手直播以及秒杀场景下,单行更新性能有点吃紧。因此我对比有赞自建数据库和腾讯 cdb在热点秒杀单行更新场景下的性能差异。
用户1278550
2019/11/14
1.7K0
Percona server与腾讯云cdb热点更新性能压测
数据库高可用架构浅析
数据库作为信息系统重要的基础设施,一直承担着压舱石的角色。互联网应用的高并发、海量数据使得数据库的负载越来越重,这在数据大集中的情况下愈发明显。而数据库作为信息系统唯一的“单点”,稳定性、可用性是首先要保证的目标。这里的单点并不是指数据库没有高可用方案,而是因为数据库只要涉及到数据的复制就一定是有状态的,有状态的应用更加难以运维,并且在遭遇异常时并不能做到真正意义上的无缝切换。
数据库架构之美
2019/12/18
1.1K0
数据库高可用架构浅析
腾讯数据库内核团队资深架构师:TXSQL Internals @2018
在ODF2018开源数据库论坛暨首届MariaDB中国用户者大会上,来自腾讯技术工程事业群TEG基础架构部数据库内核团队资深架构师王少华,做了主题为「TXSQL Internals@2018」的分享。 我们同步了嘉宾现场沙龙分享视频,请点击下方「腾讯技术课小程序」卡片即可查看: 同时附上整理好的演讲稿: CDB作为公司规模最大的关系型数据库服务平台,为公司内部业务和腾讯云提供native MySQL服务。从最初重点支持社交、游戏等场景业务,到今天覆盖了游戏、移动互联网和金融等全场景业务,CDB在
腾讯技术工程官方号
2018/10/09
9270
腾讯数据库内核团队资深架构师:TXSQL Internals @2018
载誉而归 | 腾讯云原生数据库 TDSQL-C荣获“云原生卓越技术提供商”奖项
TDSQL-C再创佳绩 9月16日,Distributed Cloud|2021全球分布式云大会在上海召开,腾讯云原生数据库TDSQL-C荣获“云原生卓越技术提供商”奖项,TDSQL-C 是腾讯自研的云原生分布式数据库(原CynosDB), 基于共享存储,实现了强大的扩展能力和超百万级QPS的高吞吐性能,深度定制的数据库内核TXSQL是支撑关键业务平稳运行的基石。 (云原生卓越技术提供商奖项) TDSQL-C的总体架构是基于共享存储,存储和计算分离的架构。 (传统的MySQL主备架构和TDSQL
腾讯云数据库 TencentDB
2021/09/28
9590
三款云数据库性能测试,谁表现最好?
MySQL性能压测或者基准测试看起来很简单,使用sysbench,tpcc工具跑跑拿到数据就好,其实压测是一个技术活儿,尤其是涉及到性能对比的测试,因为不同场景/不同厂商的产品的参数设置不同,测试的结果也不一样。如果不阐明具体的参数配置差异,直接给出压测结果可能给其他人带来误导。
用户1278550
2020/04/08
3.3K0
三款云数据库性能测试,谁表现最好?
青铜到王者,看看你的MySQL数据库是什么段位,如何提升?
作者 | 张甦, 数据库领域的专家和知名人士、图书《MySQL王者晋级之路》作者,51CTO 专家博主。近10年互联网线上处理及培训经验,专注于 MySQL 数据库,对 MongoDB、Redis 等 NoSQL 数据库以及 Hadoop 生态圈相关技术有深入研究,具备非常丰富的理论与实战经验。
数据和云
2018/07/27
1.1K0
青铜到王者,看看你的MySQL数据库是什么段位,如何提升?
推荐阅读
相关推荐
从TencentDB for MySQL到CynosDB的演进
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档