KingbaseES高可用概述.pdf

KingbaseES 高可用概述 金仓数据库管理系统 KingbaseES 文档版本：V9（V009R001C001B0024） 发布日期：2023 年 10 月 12 日 北京人大金仓信息技术股份有限公司 目 目 录 录 第 1 章 前言 1 1.1 适用读者 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 相关文档 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 术语 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.4 手册约定 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 第 2 章 高可用概述 5 2.1 什么是高可用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 可用性的重要性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 停机的代价 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4 停机原因 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5 如何实现高可用性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 第 3 章 高可用性需求分析与架构确定 10 3.1 调研高可用性需求 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 确定高可用性需求的方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1 业务影响分析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.2 停机代价 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.3 恢复时间目标（RTO） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.4 恢复点目标（RPO） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.5 管理能力目标 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.6 投资成本与回报 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3 根据需求选择适合的架构 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.1 KingbaseES 最大可用性架构 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.2 各架构的高可用性及数据保护能力 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 第 4 章 高可用架构与最大高可用性的特性 4.1 15 高可用架构介绍 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.1 KingbaseES 读写分离集群架构 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.2 KingbaseES Clusterware 共享存储集群 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1.3 Kingbase FlySync 异构数据同步架构 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1.4 高可用架构的功能对比 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 I 4.2 最大高可用性的特性介绍 目 录 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 第 5 章 KingbaseES 计划外停机高可用解决方案 22 5.1 计划外停机的类型和 KingbaseES 高可用性解决方案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2 MAA 计划外恢复能力 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 第 6 章 KingbaseES 计划内停机高可用解决方案 25 6.1 用于计划内维护的 KingbaseES 高可用性解决方案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.2 迁移的高可用性解决方案 26 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 第 7 章 最大化可用性的必备工作 28 7.1 制定可用性和性能 SLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.2 根据 SLA 选择高可用架构 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.3 搭建测试验证环境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 测试环境搭建的选择 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.4 建立变更控制流程 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.5 制定应急规划和预案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.6 执行灾难恢复演练 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.7 监控影响可用性的关键指标 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.8 参考最新的高可用最佳实践文档 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.3.1 版权声明 31 服务周期承诺 32 II 第 1 章 前言 1 第 章 前言 本文详细介绍了 KingbaseES 数据库系统高可用的概念、原理，指导用户确定高可用需求，并提供能够实现对应 高可用性需求的数据库架构。 本文介绍的 KingbaseES 高可用数据库的最佳方案，提供了高可用性相关的概述并帮助企业或个人确定高可用需 求。文档也包含为了支持高可用性而设计的 KingbaseES 产品和功能并描述了实现高可用性的主要架构。 前言部分包含以下主题： • 适用读者 • 相关文档 • 术语 • 手册约定 1.1 适用读者 KingbaseES 数据库高可用概述面向所有使用 KingbaseES 的用户，主要是数据库管理员和应用程序开发人员。 1.2 相关文档 有关高可用概述的关联技术的更多信息，请参阅以下资源： • 有关高可用应用实践的更多信息，请参阅《高可用最佳应用实践》 • 有关物理备份恢复的更多信息，请参阅《KingbaseES 物理备份恢复最佳实践》 1.3 术语 1 第 1 章 前言 术语 定义 金 仓 数 据 库 管 理 系 统 （King- 人大金仓数据库管理系统，本文指代单机服务版本，下文也被称作单机版。其成 baseES） 员可能包括数据节点（data node）、备份节点（repo node）。 金仓数据守护集群软件 金仓数据守护集群软件用于构建基于流复制技术实现数据同步的主备数据库集 （Kingbase Data Watch） 群。该类集群由主库、备库和守护进程组成，其中主库提供数据库读写服务，备 库作为主库的备份，守护进程负责检查各库及环境状态并实现自动故障转移。基 于该软件，用户可构建同机房内、同城、异地的容灾及可用性方案，确保各种故 障及灾害时的用户数据及数据库服务安全与连续。 金仓数据库读写分离集群软件 金仓数据库读写分离集群软件在金仓数据守护集群软件的基础上增加了对应用透 （KingbaseRWC） 明的读写负载均衡能力。相比数据守护集群，该类集群中所有备库均可对外提供 查询能力，从而减轻了主库的读负载压力，可实现更高的事务吞吐率；该软件支 持在多个备库间进行读负载均衡。 其成员可能包括主节点（primary node）、备节点（standby node）、辅助节点 （witness node）、备份节点（repo node）。 金仓 KingbaseRAC 集群数据 金仓 KingbaseRAC 集群数据库软件用于构建采用共享存储架构的对等多写数据 库软件（KingbaseRAC） 库集群，该软件通过缓存交换技术保持各个节点的一致性。该类集群具有对应用 透明、高可用、高性能扩展、低存储成本等特点，可满足绝大多数应用场景的功 能、性能、可用性要求。 金 仓 高 可 用 软 件 （King- 以“保障企业级关键业务不间断运行”为目标，为用户提供 Linux 平台上完整的 baseHA） 数据库高可用性解决方案，减少由计算机硬件或软件出现故障所带来的损失。当 集群中的某个节点由于软件或硬件原因发生故障时，集群系统可以把 IP 地址、 业务应用等服务资源切换到其他健康的节点上，使整个系统能连续不间断地对外 提供服务，从而为企业关键业务提供持续可靠的保障，实现系统零宕机的高可用 和可靠性。 金仓集群资源管理软件 (King- 可提供集群成员管理、故障检测、处置调度等功能。可用于构建共享存储集群冷 baseES Clusterware) 备方案，在单机已经满足性能需求的情况下，低成本的增加 KingbaseES 数据库 的可用性。同时，也是金仓 KingbaseRAC 集群数据库软件所依赖的集群管理组 件。 主节点（Primary Node） 在计算机术语中，一台服务器一般被称作一个节点（Node）。KingbaseES 的集 群服务由多台服务节点组成，其中既能在线对外提供读（Read）服务，又能提供 写（Write）服务的节点被称作主节点，英文名一般为 Primary Node，也被称作 Master Node。 备节点（Standby Node） 在计算机术语中，一台服务器一般被称作一个节点（Node）。KingbaseES 的集 群服务由多台服务节点组成，其中只在线对外提供读（Read）服务，或者仅仅用 作灾备（Backup）服务的节点被称作备节点，英文名一般为 Standby Node，也 被称作 Slave Node。 见续表 2 第 1 章 前言 表 1.3.1 – 续表 术语 定义 主数据库（主库） 简称“主库”（Primary DB），位于主节点上的数据库，该数据库对外提供读 写服务。 备用数据库（备库） 简称“备库”（Standby DB）, 位于备节点上的数据库，该节点对外提供只读服 务。 恢复时间目标，灾难发生后，信息系统或业务功能从停顿到必须恢复的时间要 RTO 求。 恢复点目标，灾难发生后，系统和数据必须恢复到的时间点要求。 RPO 1.4 手册约定 本文档中可能出现“注意、提示、警告、另请参阅”等标志，它们所代表的含义如下： 注意: 用于突出重要/关键信息、最佳实践等。 提示: 用于突出小窍门、捷径等。 警告: 用于传递设备或环境安全警示信息，若不避免，可能会导致设备损坏、数据丢失、设备性能降低或其 它不可预知的结果。 另请参阅: 用于突出参考、参阅等。 以下程序代码书写约定适用于本文档： 符号 说明 [] 表示包含一个或多个可选项。不需要输入中括号本身。 {} 表示包含两个以上（含两个）的候选，必须在其中选取一个。不需要输入花括号本身。 | 分割中括号或者花括号中的两个或两个以上选项。不需要输入“|”本身。 见续表 3 第 1 章 前言 表 1.4.1 – 续表 符号 说明 ... 表示其之前的元素可以被重复。 斜体 表示占位符或者需要提供特定值的变量。 大写 表示系统提供的元素，以便与用户定义的元素相互区分。除出现在方括号中的元素外，应当按 照顺序逐字输入。当然，部分元素在系统中是大小写不敏感的，因此用户可以根据系统说明以 小写形式输入。 小写 表示由用户提供的元素。 4 第 2 章 高可用概述 2 第 章 高可用概述 本节通过以下几个主题来描述高可用并说明高可用的重要性。 • 什么是高可用 • 可用性的重要性 • 停机的代价 • 停机原因 2.1 什么是高可用 可用性是指应用或数据库服务处于可用状态的程度。 可用性一般由应用的最终用户感知来衡量。当用户不能访问数据或应用不按他们期望工作时，我们就定义为系统 不可用。停机时间就是指系统处于不可用状态的时长。用户期望系统能够一直提供服务时就需要系统具备高可用性。 高可用系统被设计成可以在特定时间内提供不间断的服务，一般通过在一年（24×365）中可以提供不间断服务的比 例来衡量，例如具备 99.99% 可用性的系统在一年中最多会停止服务 52.56 分钟。这类高可用系统也会为维护操作提 供高可用解决方案，例如支持在系统的软硬件升级过程中仍然保持服务。 高可用解决方案有如下几个特性：可靠性，可恢复性，自动故障检测和连续服务。 特性 特性说明 可靠性 高可用解决方案应该包括可靠的硬件，以及可靠的软件（包括数据库，应用服务器，和客 户端等）。与可靠性相关的就是可扩展性，比如，通常集群就是由多个普通的硬件在集群 软件的控制下协同工作，它的整体性能并不低于价格高昂的大型服务器。另外集群的优势 还体现在即使单个节点可能故障的情况下仍能持续的对外提供服务。 可恢复性 确定在系统中可能发生什么种类的故障，以及如何尽快从这些故障中恢复对于满足业务对 于可用性的需求非常重要。例如当某个数据库的数据所在存储不可用时，应该采取何种措 施处理，系统的高可用架构是否支持在 SLA 约定的时间内从这种故障中恢复。 见续表 5 第 2 章 高可用概述 表 2.1.1 – 续表 特性 特性说明 自动故障检测 如果系统中有某个关键组件无法正常工作，系统应能够及时发现并采取相应的补救措施。 比如, 某个节点的对外网络失效，高可用故障检测软件需要在特定时间内检测到问题，并采 取切换服务到另外节点, 如果问题在发生数小时后才被发现和处理，可用性将很难保障。 连续服务 当进行系统维护且不允许暂停应用时，系统应能够提供持续的服务能力。例如移动数据库 的存储位置或者增加硬件，在高可用系统中这些操作都应该是对用户透明的。 进一步讲，高可用系统应具备以下特征： • 能够在故障发生的情况下，不间断或者极少中断对外提供的服务。 • 能够对用户透明的支持对系统，数据，或者应用的变更。 • 提供监控能力可以快速发现故障。 • 提供快速的恢复能力。 • 支持自动的检测和恢复操作。 • 实施最佳实践来管理环境。 • 最大限度减少数据丢失或避免数据丢失。 • 以最低的成本达到 SLA 中规定的可用性目标（例如 RTO 和 RPO，它们的定义见术语定义）。 2.2 可用性的重要性 可用性的重要性在不同的应用中是不一样的。互联网和数据库相结合使得人们可以跨地域的共享数据，并由此获 取收益，这就要求他们的服务必须具有高可用性。不论是小公司还是跨国大企业，它们都拥有在世界范围内随时访问 数据的用户。如果用户无法访问，交易将停止，这会严重减少公司的收入。现在，越来越多的用户渴望能够和他们的 服务提供商签署服务等级协议，这充分反应了对高可用系统的依赖性与日俱增。 企业已经通过使用蕴含信息技术的资源来提高自身的竞争力和生产效率，通过它们使自己有能力做出更迅速和准 确的判断。然而，这加剧了它们对信息技术资源的依赖性。如果关键应用变得不可用，那么企业的业务将蒙受巨大损 失。比如一个依赖 web 的电子商务系统，如果出现网站无法访问，在丢失交易额的同时，更严重的是影响了用户体 验，很多用户将选择竞争对手的网站进行购物。 研究如何保护用户的数据，以及最大限度的提高用户数据的可用性就变得非常重要。 6 第 2 章 高可用概述 2.3 停机的代价 随着企业和组织为了获得更高的竞争力而更新它们的解决方案，提高可用性的需求也随之加速。通常情况下，这 些新的解决方案都依赖对关键数据的快速访问。这些关键数据一旦不可用，它们支撑的业务处理能力也将立刻终止。 这些种停机会影响企业或组织的正常运作，影响客户的评价，严重的将导致企业或组织由此步入衰败。 停机的直接代价往往并不好评估——客户的抱怨，日常工作无法开展，新的业务无法拓展都是企业无法承受的， 但这些影响并不会在短时间内暴露。另一方面，企业无法兑现对顾客的承诺，将严重影响公司的信誉，给企业的发展 带来不可估量的负面影响。在以服务业务为主的企业里，由于停机而造成损失极其厉害。 评估停机代价时还应该关注如下两个方面： • 能承受的最长计划外停机时间。如果停机的持续时间少于几十秒，那么它将引起极少的影响甚至都不会被最终 用户察觉。但随着停机时间的延长，影响可能呈指数增长。 • 能允许的最大停机频度。频繁的停机，即使是短时间的，也会严重影响正常的业务活动。 当设计一个高可用的系统时，了解真实的停机代价是很关键的，因为这样才能清楚的知道在高可用上的改进能为 用户带来多少好处。 2.4 停机原因 在设计一个高可用的解决方案时，必须清楚的认识所有可能的停机原因。当构建一个容错性和可扩展性都良好的 信息系统基础设施时，需要考虑到所有计划内和计划外的停机原因。计划内停机对用户操作的破坏性同计划外停机是 一样的。 表 2.4.1: 计划外停机 类型 描述 举例 站点故障 站点故障会影响在该站点运行的所有服务的访 1. 站点范围的断电故障。 问，这可能影响一部分或是整个应用。站点的 2. 站点范围的网络故障。 定义在本地部署和云部署中不同，可能是： 3. 自然灾害导致站点无法运作。 1. 数据中心（data center）。 2. 地域（region）。 3. 可用区（available zone）。 集群故障 KingbaseES 数据库集群不可用。包括： 1. 集群上故障节点数超过了容错的范围。 1. 集群内节点故障。 2.clusterware 失效。 2. 集群其他组件出现失效导致的集群不可用， 3. 特定故障导致集群无法保持一致性。 KingbaseES 数据库集群无法对外提供服务。 见续表 7 第 2 章 高可用概述 表 2.4.1 – 续表 类型 描述 举例 节点故障 运行数据库的系统或系统上的数据库实例故障 1. 系统硬件故障。 导致的不可用。在使用 KingbaseES 的集群 2. 操作系统故障。 时，节点故障造成系统的一个子集故障。 3.KingbaseES 实例故障。 应用程序到数据库、数据库到存储或其他对应 1. 交换机故障。 用程序保持服务至关重要的网络通信停止或降 2. 网卡故障。 低流量带宽。 3. 网线故障。 存储着数据库部分或全部数据的存储由于故障 1. 盘或闪存驱动器故障。 导致关闭或无法正常访问。 2. 磁盘控制器故障。 网络故障 存储故障 3. 存储阵列故障。 数据损坏 存储着数据库部分或全部数据的存储由于故障 1. 操作系统或存储设备驱动程序故障。 导致关闭或坏块一般是指一个块的内容被修改 2. 磁盘控制器故障。 了, 而这个修改不是数据库预期的。坏块一般 3. 卷管理器错误导致的 I/O 故障。 分为两种：物理坏块和逻辑坏块: 物理坏块又 4. 软件或硬件缺陷。 称作介质毁坏，这种情况下会造成数据库无法 识别块，比如块的校验和无效、包含的数据全 零、块结构错误等；逻辑坏块是指块的内容在 逻辑上不一致。典型的例子包括元组内容或者 是索引节点损坏。坏块对服务中断级别的影响 不同，可能限制在数据库的一个小范围（小到 单个的数据库数据块），也可能影响到很大的 范围（导致整个数据库服务中断）。 人为错误 写丢失 误操作或是其他行为导致的数据库中数据不正 1. 误删文件。 确或不可用。人为错误在服务级别上的影响同 2. 误删数据库对象。 样范围很广，这取决于受影响的数据量和是否 3. 误操作造成的数据修改。 是关键数据。 4. 恶意数据修改。 写丢失是另一种数据损坏的形式，比起坏块更 1. 操作系统或存储的驱动故障。 难发现和修复。写丢失通常是指磁盘 I/O 子 2. 磁盘控制器故障。 系统在数据没有真正写到磁盘时，就通知上 3. 集群中共享没有禁用缓存的网络文件系统。 层调用该操作已完成。而当数据库访问该磁盘 块，读取到的将是未完成修改的旧数据，如果 数据库又使用这个旧数据去修改其它的数据， 就会破坏被修改的更多数据。 见续表 8 第 2 章 高可用概述 表 2.4.1 – 续表 类型 描述 举例 响应慢或挂起 一般发生在数据库或应用由于资源或锁竞争导 1. 死锁。 致事务无法执行时。响应慢也可能是由于资源 2. 出错的进程消耗了过多的系统资源。 缺少引起的。 3. 大量集中访问导致的资源耗尽。 1. 稳定性、安全性等修复类的小版本变更。 1. 操作系统、数据库小版本升级。 2. 为了新特性进行的大版本变更。 2. 操作系统、数据库大版本升级。 软件变更 3. 应用版本更新。 系统或数据库变 1. 替换故障的硬件。 1. 主机增加或者是移除处理器。 更 2. 增加或减少硬件资源。 2. 磁盘阵列添加或移除磁盘。 3. 数据库配置变更。 3. 集群添加或移除节点。 4. 向新环境的迁移。 4. 修改配置参数。 修改 KingbaseES 数据库对象的逻辑结构或物 1. 修改表定义。 理组织。 2. 增加或重建索引。 数据变更 3. 表分区管理。 2.5 如何实现高可用性 结合业务预算投入、业务系统连续性以及数据保护需求等，人大金仓可提供如下几种高可用性技术手段： 高可用技术项 实现能力说明 读写分离集群 提供一主一备以及一主多备的高可用集群架构，实现数据及实例级 (异地) 故障容灾。 Clusterware 集群 提供多节点并行服务，内存融合及存储共享，实现高并发性能利用最大化，结合读写分离或 备份使用同步实现数据保护最大化。 数据同步软件 提供数据实时同步服务，实现同构/异构数据实时同步。 备份恢复管理工具 提供数据备份及恢复管理服务，实现生产数据的永久保存，为数据丢失提供数据保障能力。 数据损坏检测 提供对数据库坏块的检测和修复能力。 对象在线重定义 提供在线对数据库对象进行逻辑或物理上的重组、重定义能力。 数据导出导入及数 提供并行的数据导出和导入及同/异构数据迁移能力。 据迁移 以上高可用项详细应用场景及数据保护详情可参阅KingbaseES 计划外停机高可用解决方案 和KingbaseES 计划 内停机高可用解决方案。 9 第 3 章 高可用性需求分析与架构确定 3 第 章 高可用性需求分析与架构确定 本节将提供一个可以有效评估高可用性需求进而选择合适架构的步骤，步骤包括： - 调研高可用性需求 - 确定高可用性需求的方法 - 根据需求选择适合的架构 3.1 调研高可用性需求 本节将描述如何通过业务影响分析确认计划内、计划外故障造成的停机或数据丢失带来的影响。业务分析并不限 于企业，无论是企业、政府还是非盈利组织，任何情况下数据丢失和停机都会严重影响他们对外提供服务的能力。 实现高可用性可能涉及到以下关键任务： • 报废原有系统 • 投资建设更强大的系统和设施 • 重新设计整体 IT 架构和运营方式，以适应新的高可用架构 • 修改现有应用，充分利用高可用的基础架构 • 重新设计业务流程 • 招聘和培训人员 • 充分了解现有主机和网络基础设施的能力和限制 业务分析的评估、实现不同的高可用性解决方案所需的成本和收益可以用于实现一个能同时满足业务目标和技术 目标的高可用性架构。 3.2 确定高可用性需求的方法 分析框架包括以下要素： 10 第 3 章 高可用性需求分析与架构确定 • 业务影响分析 • 停机代价分析 • 恢复时间目标（RTO） • 恢复点目标（RPO） • 管理能力目标 • 投资成本与回报 3.2.1 业务影响分析 根据与 IT 相关的停机影响的严重程度对业务流程进行分类。 完整的业务影响分析应包括： • 确定组织中的关键业务 • 评估 IT 中断造成这些关键业务流程受影响的可能性 • 概述这些中断的影响 • 考虑到必要的业务功能、人员、资源、法规以及内外部业务依赖性 • 向有经验的专家或一线工作者收集客观和主观的评价及数据 • 参考商业历史、财务报表、IT 日志等资料 3.2.2 停机代价 一个完整的业务影响分析提供了量化计划外和计划内停机时间的成本所需的预测能力。 了解并量化停机代价至关重要，这有助于各业务决策在高可用性投资的优先级，并直接影响选择的高可用技术。 有权威的发布报告记录了不同行业的停机成本。例如，每小时的信用卡销售费用为数百万美元，每小时的快递运输服 务费用为数万美元。 3.2.3 恢复时间目标（RTO） 恢复时间目标是指一个基于信息系统的商业流程失效到它开始为组织造成不可接受的影响（财产损失，客户不满 意，信誉受损等等）的时间总和。概括的讲，恢复时间目标是一个组织或者是商业流程对停机时间的容忍度。可更简 单的理解为：从系统发生故障到恢复系统之间的时间段。 11 第 3 章 高可用性需求分析与架构确定 3.2.4 恢复点目标（RPO） 恢复点目标是指基于信息系统的商业流程，在不会对组织带来任何损害的情况下所能允许丢失的最大数据量。总 的来说，它体现了组织或者业务流程对数据丢失的容忍程度。这样的数据丢失常常用时间来衡量，比如，几小时或几 天的数据丢失。 对于一些灾难来说，RPO 为零是一个挑战，但我们可以通过各种 KingbaseES 的高可用技术来实现。 3.2.5 管理能力目标 管理能力目标比 RPO 或 RTO 更主观。一般是指高可用解决方案管理的复杂程度，而这个复杂程度又是由它们 提供的管理工具决定的。和恢复时间目标和恢复点目标决定组织对停机时间和数据丢失的容忍度类似，用户的管理能 力目标考量组织对信息系统环境复杂性的容忍度。 如果用户要求操作简单的系统，那么相对于复杂的管理系统，能够达到同样高可用性的简单方法更可取，即使复 杂的系统能够提供更好的恢复时间目标和恢复点目标。理解管理能力目标将帮助组织区分什么样的部署是可能的而什 么样的部署更实用。 3.2.6 投资成本与回报 了解总投资成本 (TCO) 和投资回报率 (ROI) 对于选择一个能实现企业业务目标高可用性方案至关重要。 总投资成本包括所选择的高可用解决方案在整个生命周期里产生的所有开销（如采购、实施、系统、网络、设 施、员工、培训和支持）。同样，投资回报的计算也包含了在给定的高可用性方案所带来的所有资金收入。 例如，如果远端备用系统和存储未对其它的业务提供支撑而保持闲置状态时，它的唯一产出就是，通过备用系统 在故障切换时所减少的停机时间所挽回的损失。相对而言，如果采用备机只读部署方案，备用节点在充当备用角色 时，它的系统和存储还能对外提供服务（比如减少主节点的终端查询冲突压力的报表服务）。这时的系统产出除了因 避免停机带来的收益外，还应该包括它在担当备用角色的同时提供服务所带来的收入。 3.3 根据需求选择适合的架构 业务影响分析描述了企业已有的应用和应用对高可用性的需求。不同的应用和支撑应用的数据库对企业的重要程 度不同，对一个即使停机也不会对企业产生直接影响的应用来说，投入高成本建设高可用架构并不值得。我们推荐根 据数据库的 RTO 和 RPO 需求，从 KingbaseES 的高可用方案架构中选择能提供最接近需求的可用性的方案架构。 注意如果多个应用和支撑数据库有依赖关系，这组数据库的高可用需求应该选择其中要求最高的需求。 3.3.1 KingbaseES 最大可用性架构 KingbaseES 最大可用性架构（以下简称 MAA，Maximum Availability Architecture）定义了实现不同等级可用 性的解决方案架构，这些架构可以满足各种规模的组织使用的各类应用对可用性和数据保护的需求。 12 第 3 章 高可用性需求分析与架构确定 MAA 定义了三个保护级别： • 初级保护架构适用于对高可用需求要求不高，可通过重新启动故障组件（如数据库实例)、从备份恢复解决存储 故障等功能满足。大部分维护操作需要停机。 • 中级保护架构在初级的基础上支持在节点故障时自动切换，最小化停机时间。对于常见的计划内维护操作，如 硬件和软件更新可以实施滚动操作。在可用区级别故障发生时仍然需要从备份恢复数据库。 • 高级保护架构通过跨可用区和地域的实时复制解决灾难恢复的实时性需求，增加逻辑复制特性在线处理更多的 维护操作，适用于有高 RTO 和 RPO 的关键业务使用，对包括灾难在内各种故障引起的计划外停机、物理复制 无法实现的在线维护操作有更多支持。 表 3.3.1: 各 MAA 架构使用的高可用特性矩阵 初级 中级 高级 备份恢复管理工具（RMAN） 使用 使用 使用 数据损坏检测 使用 使用 使用 对象在线重定义 使用 使用 使用 数据导出导入，数据迁移工具 使用 使用 使用 自动重启 使用 不使用 不使用 监控工具 使用 使用 使用 读写分离集群（KingbaseRWC） 不使用 使用 使用 Clusterware 不使用 使用 使用 异构数据同步软件（Kingbase FlySync） 不使用 可选 使用 3.3.2 各架构的高可用性及数据保护能力 每个 MAA 架构都提供经大量实际项目验证的高可用性和数据保护能力。 下表总结了各架构对应的高可用性和数据保护能力。每个架构都包含了上一个架构的所有功能，并在上一个架构 的基础上处理更多的停机类型。 13 第 3 章 高可用性需求分析与架构确定 表 3.3.2: 按 MAA 架构划分高可用性和数据保护能力 MAA 计划外故障 计划内维护 数据保护 灾难恢复 单实例，通过自动重启减少数据库实例 少量在线完成大部 运行时验证和人工 从备份恢复，可能 故障造成的停机时间。通过硬件冗余部 分离线完成。 检查相结合。 丢失未完成归档备 架构 初级 署解决网络、存储等硬件故障。 中级 实例和主机故障自动切换。 份的数据。 大部分在线滚动完 运行时验证和人工 从备份恢复，可能 成， 少 量 离 线 完 检查相结合。 丢失未完成归档备 成。 高级 可用区和地域级故障切换。 份的数据。 全部滚动或在线完 运行时验证和人工 实时切换，不丢失 成。 检查相结合。 或少量数据丢失。 14 第4章 4 第 章 高可用架构与最大高可用性的特性 高可用架构与最大高可用性的特性 熟悉 MAA 解决方案中使用的高可用性特性以便基于架构进行调整。以下将对主要高可用架构进行图/文功能说 明。 • 高可用架构介绍 • 最大高可用性的特性介绍 15 第4章 4.1 高可用架构与最大高可用性的特性 高可用架构介绍 4.1.1 KingbaseES 读写分离集群架构 图 4.1.1: 读写分离集群高可用架构 功能特点： a: 多实例冗余, 支持实例级（含异地）容灾切换。 b: 节点独立存储多份数据冗余，支持数据（存储）级容灾（集群内任一存储完好均可恢复其余节点介质故障）。 c: 平衡应用读写负载，可将交易类系统指向主库，只读类系统指向备库实现读写分离均衡负载。 d: 支持坏块检测与修复。 16 第4章 高可用架构与最大高可用性的特性 4.1.2 KingbaseES Clusterware 共享存储集群 图 4.1.2: Clusterware 共享存储集群高可用架构 功能特点： a: 全局资源统一管理。 b: 支持共享存储的高可用多活。 c: 支持应用分库将压力分散到不同数据库实例。 d: 去中心化, 提供集群系统的高吞吐、高压力、高负载的承载能力。 17 第4章 高可用架构与最大高可用性的特性 4.1.3 Kingbase FlySync 异构数据同步架构 图 4.1.3: Kingbase FlySync 异构数据同步高可用架构 功能特点： a: 支持同构数据库零停机版本升级。 b: 支持异构数据库同步; 支持异地容灾。 c: 国产化替代数据平滑过渡，异构数据同步, 双轨运行，安全切换。 4.1.4 高可用架构的功能对比 • 如何选择读写分离集群和 Clusterware 表 4.1.1: 读写分离集群和 Clusterware 对比 比较项 读写分离集群 Clusterware 计划外故障处理 更多，可以处理站点故障、存储故障、设备原 存储和数据损坏依赖存储设备的高可用架构， 能力 因造成的故障损坏，详见第 5 章。 详见第 5 章。 见续表 18 第4章 高可用架构与最大高可用性的特性 表 4.1.1 – 续表 比较项 读写分离集群 Clusterware 计划内故障处理 更多，支持通过物理复制实现的迁移类维护， 详见第 6 章。 能力 详见第 6 章。 RPO 同步模式支持零丢失。 支持零丢失。 RTO 秒-分钟，故障自动检测切换。 秒-分钟，故障自动检测切换。 网络位置 集群内节点无网络限制，只受距离带来的延迟 集群内节点需要在一个子网。 限制。 运行时额外开销 同步模式会少量增加事务提交延迟，日志传输 无额外开销。 占用少量 CPU 和网络带宽。 扩展能力 备机支持读操作，支持读写分离。 支持在多个节点运行不同的数据库实例，支持 分库的负载均衡。 设备成本 相对低，存储容量上需求更大但不需要专用存 相对高，需要共享存储设备，数据库层存储容 储设备和存储网络。 量需求小, 但往往需要存储设备的冗余保障存 储可靠性。 • 如何选择读写分离集群和异构数据同步软件 表 4.1.2: 读写分离集群和异构数据同步软件对比 比较项 读写分离集群 异构数据同步软件 计划外故障处理 详见第 5 章。 支持使用异构库复制的高可用架构，例如替换 能力 过程中的双轨运行。 计划内维护处理 更倾向用于物理兼容的迁移任务、数据库或系 可通过项目服务方式实现物理不兼容迁移、应 能力 统升级维护使用。 用升级。 RPO 同步模式支持零丢失。 接近零丢失。 RTO 秒-分钟，故障自动检测切换。 秒-分钟，容灾场景更多使用自定义切换。 支持拓扑 一主多备、级联。 可实现多主。 容灾优势 维护简单、数据无坏块即表示数据一致。 支持非全库备份，减少带宽开销和延迟。 19 第4章 4.2 高可用架构与最大高可用性的特性 最大高可用性的特性介绍 • 金仓数据守护集群软件（Kingbase Data Watch）：集成化的数据高可靠性解决方案，能够预防软硬件故障、自 然灾害、人为操作等造成的数据丢失或数据库服务中断，提供 7*24 小时不间断数据库服务，满足用户对于数据 安全性和高可用性的要求。 • KingbaseES 读写分离集群（KingbaseRWC）：KingbaseES 读写分离集群通过物理复制保障企业数据的高可用 性、数据保护和灾难恢复并具备读请求的负载均衡能力。 另请参阅: 有关 KingbaseRWC 集群的更多信息请参见《KingbaseES 高可用最佳应用实践》 • KingbaseES Clusterware：KingbaseES 共享存储集群的支持组件。支撑多节点读写集群的高可用性。 另请参阅: 有关 KingbaseES Clusterware 集群的配置等更多信息请参见《KingbaseES Clusterware 配置手册》 • Kingbase 异构数据同步软件（Kingbase FlySync）：异构数据同步, 支持异构平台和异构数据库间的实时数据同 步。 另请参阅: 有关 Kingbase FlySync 的更多信息请参见官网手册地址：http://help.kingbase.com.cn/stage-api/profile/document/kfs/v1r6/html/index.html • KingbaseES 备份恢复管理工具（RMAN）：KingbaseES 的备份恢复管理工具。提供便捷可靠的备份恢复操 作。 另请参阅: 有关备份恢复管理工具的更多信息请参见《KingbaseES 备份与恢复工具手册》 • KingbaseES 数据损坏检测：通过校验技术对数据库的坏块做检测, 包括在运行态实时监测和对备份数据的检 测。 另请参阅: 有关数据损坏检测和自动修复的更多信息请参见 sys_checksums 和 支持自动块修复 • KingbaseES 对象在线重定义：KingbaseES 数据库支持在线对数据库对象进行逻辑或物理上的重组、重定义而 无需新建表结构进行导入导出。 另请参阅: 有关在线数据库对象重定义的更多信息请参见 在线数据定义变更特性 • KingbaseES 数据导出导入，数据迁移工具：KingbaseES 数据库支持并行的数据导出和导入，并支持使用迁移 工具进行同构/异构数据库的数据迁移。 另请参阅: 有关数据导出导入的更多信息请参见 sys_dump 和 sys_restore 20 第4章 高可用架构与最大高可用性的特性 有关数据迁移工具的更多信息请参见《KDTS 迁移工具使用指南》 21 第 5 章 KINGBASEES 计划外停机高可用解决方案 5 第 章 KingbaseES 计划外停机高可用解决 方案 • 计划外停机的类型和 KingbaseES 高可用性解决方案 • MAA 计划外恢复能力 5.1 计划外停机的类型和 KingbaseES 高可用性解决 方案 下表描述了如何使用最大可用性的特性来解决造成计划外停机的各种故障。 表 5.1.1: 计划外停机的类型和高可用性解决方案 故障类型 解决方案 集群或站点故障 读写分离集群 优势 • 跨站点数据复制 • 故障发生时自动切换 • 数据零丢失 异构数据同步软件 • 支持部分数据复制 • 支持双活 见续表 22 第 5 章 KINGBASEES 计划外停机高可用解决方案 表 5.1.1 – 续表 故障类型 解决方案 优势 备份恢复管理工具 • 支持本地、远程以及云存储等 多样化的物理备份存储介质 实例或主机故障 读写分离集群或 Clusterware • 故障发生时自动切换 • 数据零丢失 • 支持自动从故障中恢复 存储故障 读写分离集群 • 设备故障造成数据损坏时仍然 保有数据副本 • 故障发生时自动切换 • 数据零丢失 备份恢复管理工具 • 支持远程备份或和第三方备份 方案集成 数据损坏 数据损坏检测 读写分离集群 • 损坏检测可以发现在线数据和 备份中的坏块 • 设备故障造成数据损坏时仍然 保有数据副本 • 支持切换到副本运行 • 数据零丢失 人为错误 备份恢复管理工具 • 通过时间点恢复回滚错误 响应慢或挂起 监控工具 • 监控性能指标，及时发现性能 问题并发起告警 23 第 5 章 KINGBASEES 计划外停机高可用解决方案 5.2 MAA 计划外恢复能力 在下表中对 MAA 中各级别架构应对各类故障使用的特性和对应能力做了描述。 表 5.2.1: MAA 中各架构对计划外故障的解决方案能力矩阵 事件 MAA 解决方案 RTO RPO 实例故障 初级：自动重启 分钟 (能重启成 零丢失 功的情况) 主 机/网 络 故 障 中级、高级：故障切换 秒-分钟 零丢失 初级：修复故障后重启恢复 小时-天 零丢失 中级：读写分离集群/Clusterware ：故障切换 秒-分钟 零丢失 高级：读写分离集群故障切换 秒-分钟 零丢失 初级、中级（Clusterware）：通过备份恢复 小时-天 丢失尚未归档到备份存储 存储可用 存储故障 的数据 中级（读写分离集群）、高级：故障切换 秒-分钟 零丢失 数据损坏（设备 初级、中级（Clusterware）：坏块检测后根 小时-天 单个对象的部分数据或最 损坏造成） 据原因影响范围选择数据对象重做或从最近的 近的未损坏备份至今 完整备份恢复 人为错误 中级（读写分离集群）、高级：故障切换 秒-分钟 零丢失 所有等级 取决于发现时间 取决于具体错误，可通过 时间点恢复处理 集群故障站点故 初级、中级：通过异地备份恢复 小时-天 障 丢失尚未归档到备份存储 的数据 高级：切换到其他可用区或地域 秒-分钟 零丢失或接近零丢失取决 于同步配置 响应慢或挂起 所有等级 通过性能指标监 零丢失 控发现，取决于 后续排查和处理 速度 24 第 6 章 KINGBASEES 计划内停机高可用解决方案 6 第 章 KingbaseES 计划内停机高可用解决 方案 计划内的停机时间与计划外的停机时间一样，都会破坏系统的连续运行。使用 KingbaseES 的高可用特性以支持 在维护操作过程中保持业务的服务连续性。 • 用于计划内维护的 KingbaseES 高可用性解决方案 • 迁移的高可用性解决方案 6.1 用于计划内维护的 KingbaseES 高可用性解决方 案 KingbaseES 提供在计划内维护操作期间中保持高可用性的解决方案。 相关高可用解决方案详细操作请参考高可用最佳实践。 表 6.1.1: KingbaseES 计划维护的高可用性解决方案 维护活动 高可用解决方案 数据库配置变更 零停机时间 • 支持部分参数动态变更 • 自动内存管理调整 见续表 25 第 6 章 KINGBASEES 计划内停机高可用解决方案 表 6.1.1 – 续表 维护活动 高可用解决方案 数据库对象变更 零停机时间 • 在线对象重命名 • 在线增减表列 • 在线创建索引 操作系统软硬件更新或补丁 数秒-数分钟停机时间 • 读写分离集群/Clusterware 节点滚动升级 数据库软件小版本更新 零停机时间 • 读写分离集群/Clusterware 热替换文件 数秒-数分钟停机时间 • 读写分离集群/Clusterware 节点滚动升级 数据库软件大版本升级 数秒-数分钟停机时间 • 读写分离集群/Clusterware 节点滚动升级 升级可能包括对不兼容数据的处理 数据库集群扩容缩容（增加节点，删除节点） 零停机时间 • 读写分离集群/Clusterware 动态增加节点 零-数分钟停机时间，取决于删除节点上是否 运行服务 • 读写分离集群/Clusterware 动态删除节点 6.2 迁移的高可用性解决方案 KingbaseES 提供几种在数据库迁移中保持高可用性的解决方案。 相关高可用解决方案详细操作请参考高可用最佳实践。 26 第 6 章 KINGBASEES 计划内停机高可用解决方案 表 6.2.1: 迁移的高可用性解决方案 维护活动 高可用解决方案 迁移到不同服务器或平台 数秒-数分钟停机时间 • 读写分离集群提供同平台或部分支持的不同平台 间物理复制 迁移到数据不兼容的数据库，例如不同字符集、不同块 大小 迁移到新的存储设备 数分钟-数小时 • 使用数据导入导出工具 数秒-数分钟停机时间 • 读写分离集群提供物理复制 27 第 7 章 最大化可用性的必备工作 7 第 章 最大化可用性的必备工作 • 制定可用性和性能 SLA • 根据 SLA 选择高可用架构 • 搭建测试验证环境 • 建立变更控制流程 • 制定应急规划和预案 • 执行灾难恢复演练 • 监控影响可用性的关键指标 • 参考最新的高可用最佳实践文档 7.1 制定可用性和性能 SLA • 参考文档 1、2 节的描述，理解可能造成停机时间的因素、高可用性需要考虑的点。 • 和业务部门、上级领导、维护团队就可用性和性能需求达成一致，共同制定 SLA。 7.2 根据 SLA 选择高可用架构 • 参考高可用性和数据保护-从需求到架构一节，根据 SLA 中的需求选择适合的 MAA 架构。 • 参考计划外、计划内停机的解决方案章节，评估和 SLA 相关的故障和对应的解决方案。 • 理解解决方案中需要使用的数据库特性，根据需求对 MAA 架构做调整。 28 第 7 章 最大化可用性的必备工作 搭建测试验证环境 7.3 搭建适合的测试环境并对投产的变更做验证测试是保证生产环境稳定可用的前提条件。在测试环境中的验证测试 可以帮助我们提前发现同样的变更可能对生产环境造成的问题并提前处理。 以下的操作必须经过测试环境的验证测试： • 数据库的升级、配置或数据库对象的变更。 • 对故障的处理操作，包括对意外故障的处理操作。 • 备份、恢复、还原操作。 7.3.1 测试环境搭建的选择 建议测试环境完全按照生产环境的部署架构搭建，并在生产环境的模拟负载下做变更的功能、性能和可用性测试 验证，这样可以获得最可靠的评估：变更对生产系统的影响是否可以保持指定的性能和可用性 SLA。同时可以验证变 更的异常处理和回退方案，最大程度确保生产环境的变更在可控范围内。不建议由于成本因素取消测试环境和投产测 试，这会导致生产环境变更的不可控，影响性能和可用性 SLA 的达成并可能付出更高的成本。 如下表所示，在资源有限，测试环境不能完全模拟生产环境的情况下，测试对生产环境变更验证程度也不同。 表 7.3.1: 不同测试环境对变更验证的影响 测试环境 可验证的内容 完全复制生产环境的部署架构，数据是 数据库的升级、配置或数据库对象的变更；全部功能测试；完全模拟 生产环境的副本 生产环境压力的性能测试；全部可用性测试。 不包括可用性的部署，数据是生产环境 不包含可用性变更的升级、变更；不包含在备库上操作的功能测试； 的副本 性能测试需要充分评估不同的可用性架构影响。无法验证的内容示 例：复制参数的变更、备库上的备份、性能测试中需考虑复制带来的 网络带宽占用和延迟。 与生产系统使用不同的硬件资源 和硬件无关的升级、配置或数据库对象的变更和硬件无关的功能测试 部分资源可支撑或可以根据比例估算的性能测试 无法验证的内容示 例：针对特定芯片类型的升级、硬件相关的 fence 操作 7.4 建立变更控制流程 建立并落地执行变更管理和控制流程用于保持系统的稳定性。 流程应确保变更都在测试环境中完成验证并经过评审后才在生产环境中执行。 29 第 7 章 最大化可用性的必备工作 7.5 制定应急规划和预案 针对使用架构中可能出现的停机时间制定规划、预案，包括在故障下对应的负责人、执行团队和执行操作。 在测试环境中测试验证预案的操作并将规划和预案纳入变更控制流程。 7.6 执行灾难恢复演练 确保灾难恢复的 RTO、RPO 需求被满足需要执行灾难恢复演练。 不论系统的容灾是以数据库复制或是硬件复制等架构实现的，DBA 团队都应熟悉灾难恢复的过程，在演练过程 中 DBA 团队和相关的团队能更熟练配合启动并执行灾难恢复预案完成切换和恢复可以大大降低停机时间。 在使用读写分离集群或是异构数据同步软件用于系统的容灾备份时，建议您根据实际情况安排每 3-6 个月一次的 数据库切换演练或是整体系统的故障切换演练。 使用备份的方案中需要周期性对备份做数据校验确认备份的正确性，周期性使用备份做完整的恢复验证确认备份 的有效性。KingbaseES 的备份恢复管理工具提供备份校验功能，可以在备份策略中使用工具完成校验。 7.7 监控影响可用性的关键指标 监控影响可用性的关键指标有助于通过趋势提前发现问题避免停机时间。实现有效的监控需要： • 定义关键指标和指标的异常阈值。 – 根据业务定义业务级别的关键指标。 – 可能影响可用性的数据库性能问题需要关注的指标可以从 KingbaseES 数据库性能调优指南中的性能诊断 部分了解。 – 不同的高可用架构需要关注的指标可以从 高可用最佳应用实践中了解。 • 使用监控工具监控指标并配置异常告警。 7.8 参考最新的高可用最佳实践文档 高可用最佳实践文档中包括了 KingbaseES 高可用功能的使用建议。 文档会随着高可用功能的更新、使用环境的变化和成功的项目实践更新并发布。请从金仓社区获取最新的高可用 最佳实践文档用于参考。 30 版权声明 版权声明 北京人大金仓信息技术股份有限公司（简称：人大金仓）版权所有，并保留对本手册及本声明的一切权利。 未得到人大金仓的书面许可，任何人不得以任何方式或形式对本手册内的任何部分进行复制、摘录、备份、修 改、传播、翻译成其他语言、将其全部或部分用于商业用途。 免责声明 本手册内容依据现有信息制作，由于产品版本升级或其他原因，其内容有可能变更。人大金仓保留在没有任何通 知或者提示的情况下对手册内容进行修改的权利。 本手册仅作为使用指导，人大金仓在编写本手册时已尽力保证其内容准确可靠，但并不确保手册内容完全没有错 误或遗漏，本手册中的所有信息也不构成任何明示或暗示的担保。 技术支持 • 人大金仓官方网站：http://www.kingbase.com.cn/ • 人大金仓文档中心：http://help.kingbase.com.cn/ • 全国服务热线：400-601-1188 • 人大金仓技术支持与反馈信箱：support@kingbase.com.cn 31 服务周期承诺 服务周期承诺 由于市场需求在不断变化，技术创新和发展的进程不断加剧，产品的版本更迭不可避免。人大金仓对于产品版本 生命周期的有效管理，有助于您提前规划项目，更好地从产品服务终止上过渡。 表 1: KingbaseES 产品生命周期里程碑 关键里程碑点 定义 产品发布日期 产品正式发布版本，即 GA（general availability）版本的发布日期。 停止销售日期 正式停止销售的日期，版本停止接受订单日。该日之后，产品将不再销售。 停止功能升级日期 在该日期之后，不再提供新特性和新硬件支持。但依旧提供错误修复、安全修复、功 能维护等服务。 停止功能维护日期 在该日期之后，不再维护功能，修复问题。但依旧提供安全修复等服务 停止安全维护日期 在该日期之后，不再发布补丁版本修复中高风险漏洞，仅提供有限的支持。 产品服务终止日期 停止提供产品服务和支持的日期。包括软件维护版本，缺陷修复，以及针对该产品的 所有服务支持（包括服务热线和远程/现场支持）。 服务周期策略 金仓数据库管理系统 KingbaseES 产品确保以下的服务周期： 1）产品自发布之日起至产品停止功能升级（包含新特性、新硬件支持）之日不少于 5 年。 2）产品停止功能升级之日起至产品停止功能维护（主要包括问题修复）之日不少于 4 年。 3）产品功能维护停止之日起至产品停止安全维护（包括中高风险漏洞修复）之日不少于 2 年。 服务终止策略 金仓数据库管理系统 KingbaseES 产品确保在销售后，至少提供 6 年的服务支持。 注意: 人大金仓将会综合各方因素来确定产品服务终止日期。并将在实际产品服务终止日期之前至少 90 天，通过公 32 服务周期承诺 开方式宣布产品服务终止日期。 33