快速,持续,稳定,傻瓜式
支持Mysql,Sqlserver数据同步

从TencentDB for MySQL到CynosDB的演进

在线QQ客服:1922638

专业的SQL Server、MySQL数据库同步软件

随着腾讯云业务的快速发展和MySQL生态的发展,用于MySQL的TencentDB迎来了增长最快的时代。通过参与开源协作,用于MySQL的TencentDB团队具有服务,管理,控制,内核和体系结构等多个维度。 ,持续巩固稳定性,降低成本,丰富DBaaS产品功能,并为公司的自主开发业务和腾讯云客户提供MySQL生态数据库产品服务的持续改进。

1

第一部分在最美丽的时代遇到的最大挑战

随着性能和稳定性的不断提高,腾讯云数据库TencentDB?For?MySQL在过去两年中发展迅速。实例的数量,行业覆盖范围和商业信誉也得到了迅速的迭代。其中,TencentDB?For?MySQL内核TXSQL为了满足TencentDB?For?MySQL?的自身发展,其性能也在迅速发展。优化,企业级功能,稳定性和强一致性,但是尽管内核已经做了很多事情,但是仍然存在两个问题:

(1)在线运维压力由不安造成随着实例数量,存储规模和行业覆盖范围的迅速增加,用户对数据库的合理使用逐渐显示出来。

(2)在线资源的销售不能充分利用机器资源,造成一定程度的资源浪费。

我们从TencentDB的常见操作中分析云数据库的运维和优化中存在的问题?对于? MySQL:

1.数据库备份和恢复

TencentDB?对于? MySQL(TXSQL)数据库备份分为物理备份和逻辑备份,我们分别描述它们的过程:

(1)物理备份

总体上说,有两个线程被打开以复制重做日志? \单独的数据文件。数据文件复制完成后,应用全局读取锁定,阻止写操作并获取binlog站点,备份非innodb表数据,并在重做日志复制完成后将其释放。读取锁并结束复制。 FTWRL将在执行期间关闭表。如果在FTWRL期间存在大量查询,则将导致FTWRL等待,这将导致更长的DML拥塞。如果并发性继续增加,则很可能导致实例的可用连接数。完成后,严重时将导致实例挂起;

(2)逻辑备份

逻辑备份是以SQL语句的形式备份数据,其过程简单描述为:执行全局读取锁定(FTWRL),备份非innodb数据文件,获取全局binlog站点,将事务隔离级别设置为RR并启用快照读取(执行该语句将立即创建与该事务相对应的读取视图,所有后续读取均基于某些读取View快照读取,此时创建的读取视图与获取的binlog站点相对应),释放锁并备份innodb数据,并且在完成innodb表数据的备份之后完成备份。

从物理备份和逻辑备份的过程中不难看出。过多的实例数据会导致备份时间过长,并且在备份过程中会占用大量IO,CPU,内存和其他资源。

2.主备数据同步

逻辑日志binlog用于MySQL主备数据库之间的数据同步。完成主数据库事务后,将生成的binlog发送到备用数据库和备用数据库IO。线程将接收到的binlog写入磁盘,然后通过SQL线程或分发线程将其执行到工作线程,以便确保主备之间的数据一致,但是基于binlog的逻辑复制存在以下问题:

(1)主备数据延迟,即由主备数据引起的延迟binlog执行性能。在执行binlog期间,需要完整的B +树遍历过程,并且在执行过程中会生成重做日志。当主库的压力在一定程度上很大时,由于并发性,备用数据库的性能将无法跟上主库的执行。速度,最终导致延迟问题;

(2)数据不一致,binlog中的内部错误将导致主数据库和备份之间的数据不一致,例如由存储库不一致引起的替换导致的主数据库和备份的auto_increment不一致主数据和备份数据之间的差异,由于插入…选择等导致的主数据和备份之间的不一致;

(3)大事务问题,在事务完成后将binlog发送到备用数据库,并执行备用数据库与主库相同的逻辑,执行时间基本上与主库相同。主库或更多(行模式不更新主楼等),因此没有办法解决大公司造成的延迟问题。

尽管MySQL-5.6和更高版本具有并行复制功能,例如基于数据库的并行复制,逻辑时钟或写入集,以提高备用数据库的性能,但由于容量过大,它们尚未完全解决问题事务或主数据库上的压力。复制延迟造成的问题很大。

3.数据库升级和降级?

由于业务本身的发展,当前的实例配置对CPU,内存和磁盘空间有新的要求,并且现有计算机可能无法满足实例的资源。此时,您需要迁移实例。迁移本身是通过备份+增量数据(binlog)实现的。整个过程可以描述为:使用逻辑备份或物理备份创建新实例,然后创建该实例。然后,使用change master命令以备用数据库的形式连接到master数据库,并提取备份记录的binlog。当主服务器和备用服务器没有延迟或延迟很小时,请将原始实例设置为只读,以确保无延迟后将VIP切换到。新实例在上方,从而完成了迁移操作。

当主库压力恒定或有延迟时,迁移时间将持续较长时间,从而影响用户体验或数据安全性。

4.数据库崩溃恢复

MySQL崩溃恢复过程简要描述为:从最后一个检查点开始,执行重做日志,扫描最后一个binlog文件,并xid收集此文件中的事务集合,根据回滚段重新构建读写事务列表(有关详细信息:trx_list_init_at_db_start),根据事务的状态,对尚未启动的事务以及对未执行的事务执行回滚操作。处于准备中的事务,如果收集的xid集包含事务的xid,则提交Transaction,否则回滚该事务;

当写入压力较高时,崩溃恢复过程将花费很长时间,从而导致RTO较长,从而影响可用性;另外,备份的备份还需要应用重做日志,当重做日志量很大时,会影响RTO。

5.数据库性能优化

就写性能而言,MySQL先写重做日志,然后写binlog,最后在提交事务时提交事务。事务提交涉及多个IO(例如重做日志,binlog,dirty等),binlog是序列化提交,按顺序写入binlog,尽管binlog的组提交(刷新binlog阶段,sync binlog阶段,commit trx阶段,特定参考) ::ordered_commit),但很容易成为瓶颈,从而影响整体性能; TXSQL性能优化在重做日志,脏日志,二进制日志中做了很多工作,例如重做日志组提交,并行写入重做日志,异步笔刷重做日志,独立的脏线程,拥有的gtid的预分配优化,二进制日志旋转优化算法完成这项工作后,尽管系统性能已远远超过官方,但仍无法充分利用系统资源,因此单机写入性能也有上限。

就读取性能而言,备用计算机基于逻辑日志(binlog)的复制,无法深入存储层以执行更多性能优化。在大事务回放的情况下,它将产生高延迟;同时,逻辑复制读写数据库。模型是:用户读取数据,回放线程写入数据,但是innodb层中的事务无法意识到这一点。读写事务之间的冲突与主机一样严重,性能瓶颈很明显,并且基于逻辑日志的回放会限制性能。

从以上分析可以看出,传统的云数据库存在以下问题:

(1)弹性扩展能力弱,严重浪费资源

当业务需要扩展只读节点时,只能通过备用数据库+附加binlog进行扩展。时间长短取决于数据量,增量binlog的数量以及备用数据库回放binlog的速度。另一方面,大多数企业对磁盘中的CPU,内存和磁盘有大量需求,导致磁盘销售完成后会占用更多的CPU内存资源,这不利于整体资源的销售,从而导致问题资源浪费。

(2)稳定性较弱,RTO和RPO不可控制

MySQL通过逻辑日志binlog实现数据同步,当主库压力很大或发生大事务时,备用数据库很容易出现延迟,当主库出现问题并且备份清单延迟时,它将导致实例不可用并影响实例的可用性。

(3)一次执行多个IO操作,例如binlog,重做日志,异步脏操作和其他IO操作,并且Binlog的串行写入也是系统的一大瓶颈。

从以上分析可以看出,本地磁盘容量限制\\备用库回放binlog的速度是影响RTO \\ RPO \\ RPO扩展能力和资源销售的关键。为了彻底解决磁盘空间\\ binlog回放速度问题,TEG云家平与CSIG云产品部数据库的联合团队实现了云原生自主开发的CynosDB数据库。

1

第二部分cynosDB的产生

为了解决传统数据库领域的许多问题并增强其竞争力。云数据库产品CynosDB经过千锤百炼。

CynosDB是基于日志的云原生分布式数据库产品,它是由TEG云家平和CSIG云产品数据库联合团队自行开发的数据库共享磁盘。日志是数据库是CynosDB的典型功能。 CynosDB的主要目标如下:

(1)资源池化,有效提高公共云销售比例;

(2)提高稳定性,彻底解决RTO和RPO问题;

(3)按需计费,最终的灵活性和扩展性;

(4)极端的性能和功能体验,提高产品性价比;

简单换句话说,CynosDB分为计算层和存储层两部分,并通过重做日志通信相应的消息协议协议以共同提供计算服务。计算层没有状态,可以线性扩展。它最多支持备用数据库的15个只读节点。存储层的最大存储空间为128T,可以满足大多数企业的需求。

本文主要从计算层的角度分析CynosDB如何解决传统数据库的问题以及CynosDB计算层(TXSQL)内部实现的细节。

?CynosDB总体架构

CynosDB分为计算层和存储层。该计算层具有以下特征:

(1 )计算层没有本地数据文件,临时表文件,表定义文件和重做日志文件,即,卸载本地IO;

(2)计算层不再仅生成binlog。重做以获取数据同步日志,并将重做日志发送到存储层储备数据库;

(3)计算层接收并处理用户请求并返回语句p处理结果给客户;

(4)计算层不再执行检查点,不需要刷脏,因此不存在由重做日志引起的同步检查点,异步检查点,同步刷脏,异步刷脏等动作;

(5)计算在崩溃恢复期间,该层不需要应用重做日志部分,它只需要回滚未完成的事务;

(6)备用计算机仅在同步过程中会收到重做日志,而在应用过程中不会收到重做日志;

(7)主库的清除和备用库的MVCC行为已更改。

存储层的主要特征是:

(1)存储层接收备用数据库下推的重做日志,并且可以将重做日志应用于其中的相应页面平行;

(2)存储层根据计算层请求页面时指定的LSN返回页面的不同版本(LSN),即页面多版本功能;

(3)存储层负责数据持久性;

(4)存储层根据计算层下达的回收利用来管理数据空间。

计算层分为主节点和备用节点。主节点接收读取和写入请求。备份节点仅接收读取请求。备用数据库不会生成重做日志。它仅接收主数据库生成的重做日志。同步使用缓冲池\\全局读取视图\\ DDL。

1.CynosDB如何解决传统数据库中存在的问题

(1)弹性扩展和资源的充分利用

CynosDB使计算与本地存储脱钩。计算层负责执行SQL语句。存储层负责数据页的存储以及多种版本数据的读取操作。计算节点使用CPU和内存资源。存储的销售与存储资源的销售是分开的,后者可以充分利用独立资源,用户可以按需购买。在传统的云数据库中不会浪费资源。

(2)高可用性和高可靠性,大大缩短了RTO和RPO

CynosDB主数据库和备份数据同步,文件备份以及数据恢复均基于重做日志进行处理。重做日志直接操作数据页面,没有查询B +树定位数据的过程,并发性高,回放速度快,因此可以解决由于主库的压力过大。在整个过程中不会生成重做日志\\ bin00,也就是说,不会生成任何本地IO。与binlog生成不同,重做日志是在执行时生成的,无需等待事务结束将其发送,因此它可以完全解决由大事务和DDL延迟准备导致的主要问题。

(3)重做日志复制,性能大大提高

通过计算存储的解耦,CynosDB摆脱了binlog,并将复制协议从逻辑日志升级为物理日志(redolog),就写入性能而言,由逻辑日志(binlog)引起的性能瓶颈不再存在。而是针对内核中的相关锁资源进行了优化。经过内核团队的相关优化后,本地CynosDB的纯写入性能是打开binlog性能的大约两倍,极大地提高了独立性能。在读取性能方面,已对备用计算机的事务模型进行了重组和优化,并且完成了许多索引优化。备用计算机的读取性能已大大提高。读取性能已接近数据库只读模式(只读),而主数据库和备用数据库之间的延迟减少到毫秒级别,完全摆脱了大事务和主数据库与备用数据库之间的较大延迟的问题

2.TXSQL的辛苦过程

CynosDB主要由计算层和存储层组成,由于篇幅所限,本文主要阐述了部分过程

2.1)CynosDB-卸载本地文件系统

卸载本地文件系统主要是指将本地数据存储在网络云磁盘中,这是通过增量方式实现的。数据重做日志\原始数据对于数据存储,为了实现此目的,数据库内核团队已执行以下操作:

(1)将本地异步AIO转换为网络异步RIO以实现网络异步RIO相关接口;

(2)metada的转换信息,添加其他数据字典表,将frm,trigger,view,opt,directory和其他文件下推到innodb进行存储,从而删除本地数据字典信息文件;

(3)数据文件的持久性,计算层不会对非临时表进行脏操作,并且不存在双写缓冲区(双写缓冲区的行为是为了防止部分写操作,根本原因是MySQL的重做日志不全是物理上的,是逻辑上的组合(当然是物理上的,没有检查点相关的操作)。提交事务后,您只需发送重做日志到存储端,存储端将重做应用于数据文件,然后构造数据页并存储;

(4)处理本地临时表。用户线程或系统线程在执行过程中,并且在操作重做日志时不会生成临时表,TXSQL在临时表操作期间将数据文件直接推送到临时表空间进行存储,不涉及重做日志的应用,临时表在系统重启期间将重新构建步调;

(5)建立索引的过程,MySQL-5.7在添加二级索引的过程中使用了新算法。当算法建立一个B时+树,B +树是自下而上构建的,为了提高效率,不生成重做日志,为了实现单独的计算和存储架构,TXSQL for CynosDB版本添加了由创建的重做日志页面,从而确保数据的完整性;

(6)……

2.2)CynosDB-活动和备用内存同步

在CynosDB中,备用数据库没有自己的数据库独立数据,并且相同数据与主数据库一起使用。重做日志用于在活动数据库和备用数据库之间同步缓冲池。详细信息可以参考下图:

备用数据库根据收到的space_no \\ page_no分配给不同的应用线程。 Apply线程将应用重做日志。当重做日志在内存页面中时,请应用否则,重做日志将被丢弃,并且整个过程是一个相对复杂的过程,因为必须解决以下问题:

(1)在提高应用速度的同时,如何确保系统线程不会阻塞用户线程的读取;

(2)应用过程可能涉及B +树的Split操作,如何确保在读取B +树的过程中用户线程读取的数据页是有效的,即物理一致阅读;

(3)当用户线程正在读取数据时,当要读取的数据为数据页不在缓冲池中时,您需要从TXStore读取相关版本的数据版本。此时,{space_no,page_no,LSN}将被下推到存储侧,并且存储侧将返回相应版本的数据。重做日志适用于批处理适用,则LSN读取的是从这些重做日志开始或结束于批处理end_lsn的批处理start_lsn。如果使用批处理start_lsn进行读取,则存在丢失重做日志的问题。如果按批处理end_lsn来读取该页面,则不会丢失该更新,但是必须确保预先在buf中读取的页面不应在该批处理中应用重做日志;否则,请执行以下操作:

(4)由于存在MVCC,如何确保相关修改的撤消日志在修订之前?先执行生成的重做日志,然后首先执行系统撤消,然后再执行数据页的重做日志已执行,但是这样的批量应用对用户读取线程具有一定的阻止行为,这将导致用户线程等待撤消日志完成释放数据页面,然后导致TXStore中重做日志的累积并影响稳定性。

其他问题未一一列出。 TXSQL在应用线程的过程中使用了双缓冲区,无锁技术,页面寄存器,索引拆分算法等技术,并不断进行分析和调试。在此过程中,逐步解决了各种问题,极大地提高了应用速度,彻底解决了主从延迟的问题。

2.3)CynosDB-MVCC

MVCC是多版本并发控制的缩写。有关MVCC的详细原理,请参阅此公共帐户之前共享的文章” InnoDB MVCC详细说明”。 MVCC的本质是读写交易的链表,即产生交易ID的交易。仅对于写入事务,才有多个版本的数据。在CynosDB中,主库接收读写事务请求,而备用数据库接收只读请求。主库MVCC在实施过程中不需要更改实施。备用数据库的MVCC需要依靠主库生成的事务日志来构造备用数据库的readview,然后将计算出的全局读取视图分配给用户线程。用户线程根据其自己的读取视图来判断数据版本的可见性。下图可以描述主库MVCC和备用数据库MVCC之间的关系:

在实现过程中,需要确保库日志启动\提交与主库生成的顺序严格一致,否则将导致读取脏数据和读取清除数据的问题。

2.4)CynosDB-Purge

Purge用于回收空间,即从撤消日志中找到并删除带有删除标记的数据,然后回收撤消日志空间本身,此操作将仅删除无法使用的数据,因此清除操作将从读取视图列表中找到最旧的读取视图,并根据读取视图的low_limit_no判断是否可以删除该数据。在CynosDB中,主库和备用数据库使用相同的数据,因此清除不仅取决于主库的最旧读取视图,而且还取决于所有备用数据库的最旧读取视图。仅主库执行清除操作,而备用数据库不执行清除操作。

2.5)CynosDB性能优化

数据库内核团队在向CynosDB计算层编写优化过程中遇到以下问题:

(1)CynosDB中数据页的读写操作所生成的重做日志全部是网络IO。与本地IO相比,网络延迟高出一到两个数量级,RT增加,并且性能不如预期。/p>

(2)关闭binlog之后,系统瓶颈直接进入了全局事务系统,即trx_sys-> Mutex;

(3)在主库执行DDL的同时,备用库具有以下功能:如果可以保证备用数据库的读取有效性,则可以访问主库中免费存储的数据页;

(4)其他问题。

为了解决上述问题并执行相应的读取优化,内核团队进行了以下优化:

(1)?线程池的异步组提交以提高每单位时间的吞吐量。

(2)并行复制重做日志,减少了所占用log_sys-\的锁定时间。互斥,提高并发性;

(3)?交易系统优化,解决trx_sys->互斥瓶颈问题;

(4)?异步DDL,以确保DDL在主数据库中运行时不影响备用数据库的读取操作;

(5)?其他优化,例如用于异步唤醒操作的无锁队列,异步重做日志刷新以及备用数据库的读取视图。

完成上述优化后,独立CynosDB的写入性能可以突破25W左右。在一个主站和一个从站的读取版本中,备用库oltp_read_only达到100W +。

2.6)CynosDB正确性验证

CynosDB日志是数据,计算层将重做日志下推到存储层(TXStore),TXStore应用这些重做日志,然后进行数据存储,计算节点不需要变脏,没有检查点等相关操作,备用数据库使用重做日志来同步内存,以查看视图锁定相关信息,那么如何处理以下两个问题:/p>

(1)如何确保IO的正确性,即计算层中的数据与TXStore应用后的数据相同;以及读取操作的正确性。

为了解决数据一致性问题,内核团队对页面和重做日志进行了特殊处理,并将页面的校验和,lsn和其他信息下推到存储层。存储层将在日志对应比较之后应用日志,以确保数据的可靠性。为了验证备用数据库读取的有效性和正确性,数据库内核团队做了以下三件事:

(1)tpcc事务验证逻辑提取到CynosDB的测试过程中进行验证备用数据库读取的有效性;

(2)根据数据库隔离级别,自定义lua脚本,原则上保证备用数据库读取数据的判断逻辑的正确性;

(3)从内核进行测试,以确保备用数据库中主库的任何SQL语句的执行结果与主库的执行结果相同。 ?

2.7)CynosDB添加的只读节点

CynosDB中的活动节点和备用节点共享一条数据。添加只读节点所需的时间约为秒。详细过程如下所示:

1

部分? Ⅲ加入我们

数据库这是一个非常有吸引力的领域。数据库内核的开发与算法,操作系统,文件系统,体系结构等有许多联系。如果您对数据库有浓厚兴趣,则数据库的原理相对清晰,并且有更好的C或C基础。 C ++,最重要的是,您有勇气挑战各种困难和强烈的责任感,那么您就是我们要找的人。关注”腾讯云数据库”的公共帐户,然后回复”招聘”以查看招聘信息。

DBbrain诊断日?

第二个DBbrain诊断日即将到来~~ 1月12日(本星期日)20:00,编辑器将在共享组中共享” 数据库数据库表”与数据相关的详细设计案例在MySQL操作和维护操作中,每个人都倾向于关注如何优化慢速SQL和如何设计数据库体系结构,并且数据库表的设计通常比较随意。实际上,好的数据库逻辑设计和物理设计是高性能的基石,在架构设计中,每个人都应同时注意整体情况和细节,通过这种共享,您将能够从新的角度审视MySQL知识系统。 ,您将在名人信息中发现一些错误,避免在工作中重复同样的错误,并使用DBbrain解决数据库操作和维护方面的难题。

尚未加入小组的小朋友, 请 跟随下面的图片快速进入组

年底反馈?

↓↓单击此处获得更多惊喜优惠

相关推荐

 
QQ在线咨询
售前咨询热线
QQ1922638