在数据库上成功TAC要求具有哪些底层才干

数据库高可用是企业级用户在关键业务系统中对数据库的基本要求，在高可用方面，怎样提高才干都不为过。也正是由于高可用的疑问，很多金融企业在选用外围系统数据库的时刻，都自愿选用散布式数据库。由于目前国产集中式数据库在高可用切换方面与散布式数据库相比还存在较大的差距。前段期间在一个会议上，有一家券商就对某个国产集中式数据库厂商提出了高可用的需求，问他们有没有才干在证券买卖系统上成功对Oracle的代替。

成功智能切换，RPO为零，RTO越低越好是关键业务系统给国产数据库厂商出的一道考题。在这方面Oracle用TAC给出了一个近乎完美的答案。在Oracle RAC集群中，假设某个节点缺点，运行系统的衔接可以极速的以秒级的速度切换到存活的节点，SELECT查问以及绝大少数DML/DDL也可以间接切过去继续口头。这象征着一个建表操作或许一个数百万数据写入的事务可以在用户无感知的状况下在一个实例缺点时成功透明切换。顶多最终用户会觉得某笔买卖的延时长了一点点。在23C中，TAC不只仅允许RAC，还允许ADG，当ADG SWITCHOVER的时刻，或许是ADG是驳回同步形式的时刻，主库缺点或许切换的的时刻，运行可以经过TAC切换到ADG备库。

看起来如同这特性能也不算太难成功，不过为了这特性能，Oracle从98那年的TAF推出到成功TAC FOR JAVA整整花了20年期间，而推出比拟片面的TAC性能，要到明年了。Oracle花了25年成功的反派性的性能优化，其面前究竟有什么秘密呢？

一个在行来看数据库产品的时刻，往往觉得某些性能似乎很便捷，似乎只需开发人员代码写得好一点，成功起来很容易。其实有些看似很便捷的性能的面前有着十分复杂的逻辑。就像大家不时吐槽的XID64，十多年过去了，在PG 16里依然跳票了，只管这特性能关于PG来说很必要，但是要想真正领有这特性能没那么便捷。TAC或许不必定有XID 64复杂，但是曾经足够复杂了。当RAC某个节点缺点的时刻，运行的客户端感知RAC节点缺点，智能重连到备用实例，假设是只读事务，则依据PGA中的CURSOR数据以及SELECT动员时的SCN在新实例上继续成功没有成功的SQL PLAN余下的操作。假设是写操作事务，事务守护模块在新的衔接中重放没有成功的事务，成功无感知的智能切换。咱们看下面的形容似乎成功起来并不难，实践上要想成功TAC性能，有很多基础才干要求具有。

首先是数据库产品必需领有一个RPO为0的备机方案，这是确保TAC切换能顺利成功绕不过去的技术点。业务系统高可用全智能极速切换中很关键的一点是数据0失落。共享存储多读多写，共享存储强分歧性读写分别、同步备机等都是可以成功RPO为0的备节点处置方案。假设是同步备机，普通而言可以选用FAR-SYNC方案来防止备机对主库发生的性能影响。

其次是高可用切换的备节点选用疑问，在多节点RAC上，假设某个节点缺点时，无方案，无战略的轻易切换会带来很多无法知的疑问，加大集群自研灵活REMASTER的开支，重大时甚至会引发集群性能疑问。Oracle在这方面设计了SERVICE HA，要求做TAC的运行必需衔接到某个设定好的SERVICE NAME，而每个要求TAC切换的SERVICE成功都曾经性能好了HA切换战略。经过正当的SERVICE HA战略，可以确保切换的有序性。在这里，就要求数据库产品有SERVICE和SERVICE HA的才干。

数据库外围具有了上述才干后，还要求客户端能够极速切换的才干。在TAF里，是客户端感知到主机端的意外后，被动采取的切换举措，由于网络超时、数据库访问超时等的判别有必定的TIMEOUT限度，以及RETRY的需求，因此这样的切换往往是分钟级的，存在较大的 延时。为了更快的切换，必需采取其余的方案。Oracle为了成功极速切换，在服务端引入了一个服务—Oracle Notify Service（ONS），当某个数据库实例缺点时，ONS会很快发现，并经过Fast Application Notification（FAN）极速通知到每个衔接到这个数据库实例的会话。而每个BackEnd也都必需有接受FAN信息，并且依据FAN信息智能决策的才干。

当会话智能切换到新的数据库实例上的时刻，关于存在写操作的会话，还要求能够正在启动中的写操作的才干。Oracle是经过Transaction Guard(TG)来成功的 ，TG经过会话正在启动的事务的成功状况智能成功未成功的事务。为了成功这特性能，Oracle引入了LTXID。LTXID的全称是Logical Transaction ID，即逻辑事务ID。LTXID由以下四个局部组成：分支限定符（branch qualifier），用于标识事务的分支；全局事务ID（global transaction ID），用于标识事务的全局范围；事务分支号（transaction branch number），用于标识事务的分支序号；事务序列号（transaction sequence number），用于标识事务的序列号。在TG中，把一个本地事务模拟成一个散布式事务，并将这个逻辑散布式事务的 ID与一个实在的本地事务做关联。本地事务的变动也会同步到TG中的逻辑映射中，当出现缺点切换时，TG可以依据操作的形态（Prepared、committed、rolled back、complete、unknown等）采取不同的 智能化举措，成功写操作的智能切换。假设事务的形态是未知（unknown），事务协调器会从新查问各个分支的形态，并依据少数派准则（majority rule）选择事务的最终形态，并选用回滚还是提交。

似乎到这里TAC所要求的性能基本上都列举了，不过还没完，还有很多很关键的小中央的革新。比如判别数据库切换时出现的哪些失误是可以复原的，哪些失误是无法复原的。比如事务中存在一个数据库无法复原的失误，那么再去尝试无损切换是不正当的，此时最好的方法是向客户端报个措，让运行程序去处置这个缺点。Oracle的处置方式是对每个缺点参与了一个OracleException.IsRecoverable属性，来标记缺点能否可复原，关于可复原的缺点才采取TAC无损切换，否则立马向客户端报错。

前几天我写了一篇关于Oracle TAC的文章，过后就有好几个国产数据库厂商的好友和我沟通，说他们想在自己的数据库产品中成功TAC，从而更好的改善用户体验。我过后就和他们说，TAC对用户来说是个十分棒的性能，但是要成功TAC其实并不容易。过后我承诺有空了再写篇详细一点的文章来引见一些TAC的成功细节，这个周末正好想起了了，于是开局构思，今早约好了10点去访问一家国产数据库厂家，因此早上的期间比拟富余，就写了下面的内容。

实践上关于成功TAC来说，还有最后一个难关，那就是Oracle在TAC上的专利壁垒。作为介入环球化竞争的中国数据库企业，遵守国内规定，尊重常识产权是必要求做的事情。在TAC成功门路上，Oracle曾经领有了少量的专利，因此咱们的国产厂商间接照着Oracle一顿猛抄必需是不行的。首先咱们要去钻研明确在这方面哪些是Oracle的专利，必需在成功中对这些启动规避。