当前位置: 首页 >> 技术文章 >> Oracle 19c: RAC 集群技术的坚持与放弃(含PPT下载)
Oracle 19c: RAC 集群技术的坚持与放弃(含PPT下载)
发布时间:2018-11-29 发布人:盖国强 153


在 OOW 上发布出来关于 Oracle RAC 集群的几篇文章,可以让我们一睹 Oracle RAC集群技术的发展路线。

(关注数据和云公众号,回复 2018OOW 在 RAC 目录下是本文参考的3个PPT)


首先我们再次明确一下 Oracle 的版本策略,18c 等同于 12.2.0.2 ,19c 则等同于 12.2.0.3 ,19c 将是 12c 的最终版本,2020年 Oracle 数据库将发布 20c 。


19c 将于 2019年 1季度 发布,所以毫无疑问,很可能没有人会采用 18c 这个版本了。


1543461941583070492.jpg


关注 Oracle RAC的变化,我总结了一下,大约可以分为 3 个部分,分别是:

增强:这是渐进式的,Oracle 在不断改进;

放弃:不支持的,或者说尝试过觉得无用不受欢迎被放弃的特性;

革新:属于坚定向前,重点发展的特性。


首先,Oracle 的RAC技术从 9i 开始( OPS 时代没有被记入),经历了 20 年的革新演进,很多新的特性不断被引入到数据库当中,在 18c 中增加的新特性主要包括:RAC Sharding,Continuous Application Avaliablity 和 Scalable Sequences。


这几个特性我们之前都介绍过,Scalable Sequences 通过对于序列的改造,优化了跨实例主键方面的冲突,这是 RWP 团队在实践中总结出来的方法,被通过新特性方式实现了,虽然这不是专门针对 RAC 设计的,但是对 RAC 的问题解决有重要作用。


1543461976286065076.jpg


RAC 团队的产品经理总结,开发主要聚焦在三个领域:大规模部署的有效性、更好的扩展性和性能、更高的可用性。在这三个方向 RAC 在18c做出了一些显著的改变。


1543461986400097426.jpg


革新,在我看来,Oracle RAC 集群中,最重要的一个变化就是 Cluster Domain - 集群域,这是自 Oracle 12.2 引入的新特性,目标是将 RAC 中的各种资源服务化,解耦合,从而实现更好的扩展性、几种管理和维护诊断。


通过 Cluster Domain 的改造和扩展,Oracle 将 Application 等都融合起来,进行统一的集群管理。


1543461996815049712.jpg


这一模型是相当清晰和优雅的,但是唯一的问题是,用户有多大意愿构建这样一套复杂的架构,尤其是核心业务场景下的挑战。


所以下一步 Cluster Domain 的方向是推进用户的改变并持续提高可用性和性能。


1543462006318064368.jpg


在 Cluster 的变革中,Flex Cluster 是一个基础的核心技术,从 Flex ASM 到 Flex Cluster,集群技术做出了有益的改进。但是从 18c 开始,有一些可能我们还从未用过的技术,被放弃了。


1543462019023019555.jpg


Oracle Flex Cluster 经过了几个版本的变革,走到今天,我们来回顾一下:

Flex Cluster 是随着 Oracle Clusterware 12c第1版(12.1.0.1)中引入

  • 目标是管理同一集群中的应用程序和数据库;

  • 数据库应托管在HUB节点上,Leaf节点上只能部署应用程序


在 Oracle Clusterware 12.2 引入了另外两个特性:

  • “Massive Parallel Query Oracle RAC” ;

  • Oracle RAC Reader节点;


在 Oracle Clusterware 18c 的改变:

  • Flex Cluster 中的 叶节点 不再支持;

  • “Massive Parallel Query Oracle RAC” 特性不再支持;

  • “Oracle RAC Reader Nodes” 仍然存在,将在HUB节点上支持;


放弃,在 Oracle 19c 中,将彻底去除对于 Leaf Node 的所有特性支持。这是一个回退,说明当初的功能设计没有找到足够的用户支持。


谈完了放弃的特性,增强的特性主要包括,在连续性方面的改进。


在这个方向,Oracle 突出的是,持续减小集群重配置对于可用性的影响,在12c中,较11g做出了4倍的改进,而 18c 则又做出了 1.5 的重配置增强。


1543462029794064779.jpg


在2节点实例的测试场景中,18c 通过 8个LMS进程,在 25GB Buffer Cache下,重配置时间是 3 秒,100GB Buffer Cache的重配置时间是 8.3 秒,而在 32 个 LMS 进程配置下,重配置时间缩短到 3.6 秒:


1543462038848012460.jpg


所以,其实 RAC 的改进,在不断通过多进程的并行,增加各种核心功能的速度,以下列举了 3 个主要的改进,第一个功能是 Remaster 的 Salve 进程,每个 LMS 配置一个Salve进程促进 Remaster 过程中的 Cache Fusion 速度,第二个是自12.2支持 100 个 LMS 进程,第三个是 自适应的 DRM 的改进(这是 19c 中的计划了)。


1543462050812062784.jpg


当然,Oracle 还有很多增强,但是只针对 Exadata,例如 Undo Block 的 RDMA读取,Commit Cache,如果这些特性不下放,那么在普通的RAC环境中是无法借鉴到的:


1543462061470057014.jpg


详情推荐一览我参考的两个PPT文档。