在 GitBook 上增加 DBA 进阶教程目录及容灾架构设计章节

docs/user_manual/operation_and_maintenance/disaster_recovery_architecture_design/01_high_availability_architecture_overview.md

@@ -0,0 +1,54 @@
+---
+title: 容灾架构概述
+weight: 1
+---
+
+数据库系统在应用架构中承担了数据存储和查询的功能，其对企业数据安全和保障业务连续性至关重要。高可用是数据库系统架构设计中首要考虑的因素，高可用诉求包括服务高可用和数据高可靠。本文将介绍 OceanBase 的服务高可用技术。
+
+OceanBase 数据库具备多样化的服务高可用技术，包括集群内的多副本容灾，以及集群间的物理备库容灾。
+
+## 多副本容灾
+
+![高可用](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/7726968461/p355597.jpg)
+
+如图所示，数据服务层表示一个 OceanBase 数据库集群。该集群由三个子集群（Zone）组成，一个 Zone 由多台物理机器组成，每台物理机器称之为数据节点（OBServer 节点）。OceanBase 数据库采用 Shared-Nothing 的分布式架构，每个数据节点都是对等的。
+
+OceanBase 数据库中存储的数据分布在一个 Zone 的多个数据节点上，其它 Zone 存放多个数据副本。如图所示的 OceanBase 数据库集群中的数据有三个副本，每个 Zone 存放一份。这三个 Zone 构成一个整体的数据库集群，为用户提供服务。
+
+根据部署方式的不同，OceanBase 数据库可以实现各种级别容灾能力：
+
+* 服务器（Server）级无损容灾：能够容忍单台服务器不可用，自动无损切换。
+
+* 机房（Zone）级无损容灾：能够容忍单个机房不可用，自动无损切换。
+
+* 地区（Region）级无损容灾：能够容忍某个城市整体不可用，自动无损切换。
+
+当数据库集群部署在一个机房的多台服务器时，实现服务器级别容灾。当集群的服务器在一个地区的多个机房中时，能够实现机房级别容灾。当集群的服务器在多个地区的多个机房中时，能够实现地区级别容灾。
+
+OceanBase 数据库基于 Paxos 协议实现了多副本容灾方案，对用户提供少数派故障时 RPO  = 0，RTO < 8s 的国标最高的 6 级高可用标准
+
+OceanBase 分布式集群的多台机器同时提供数据库服务，并利用多台机器提供数据库服务高可用的能力。在上图中，应用层将请求发送到代理服务（ODP，也称为 obproxy），经过代理服务的路由后，发送到实际服务数据的数据库节点（OBServer 节点），请求的结果沿着反向的路径返回给应用层。整个过程中不同的组件通过不同的方式来达到高可用的能力。
+
+在数据库节点（OBServer 节点）组成的集群中，所有的数据以分区为单位存储并提供高可用的服务能力，每个分区有多个副本。一般来说，一个分区的多个副本分散在多个不同的 Zone 里。多个副本中有且只有一个副本接受修改操作，叫做主副本（Leader），其他叫做从副本（Follower）。主从副本之间通过基于 Multi-Paxos 的分布式共识协议实现了副本之间数据的一致性。当主副本所在节点发生故障的时候，一个从节点会被选举为新的主节点并继续提供服务。
+
+选举服务是高可用的基石。不同于 OceanBase 数据库之前的版本，在 V4.x 版本中，选举服务的粒度从分区变为日志流，分区挂载在日志流上。日志流的多个副本通过选举协议选择其中一个作为主副本（Leader），在集群重新启动时或者主副本出现故障时，都会进行这样的选举。
+
+此外，在 V4.x 版本中，选举服务也不再依赖 NTP 或其他时钟同步服务来保证集群中各机器时钟的一致性，而是通过本地时钟以及经过改进的租约机制来保证一致性。选举服务由优先级机制来保证选择更优的副本作为主副本，优先级机制会考虑用户指定的 Primary Zone，以及机器的异常状态等。
+
+当主副本开始服务后，用户的操作会产生新的数据修改，所有的修改都会产生日志，并同步给其他的备副本（Follower）。OceanBase 数据库同步日志信息的协议是 Multi-Paxos 分布式共识协议。Multi-Paxos 协议保证任何需要达成共识的日志信息，在副本列表中的多数派副本持久化成功后即可保证，在任意少数派副本故障时，信息不会丢失。Multi-Paxos 协议同步的多个副本保证了在少数节点故障时系统的两个重要特性：数据不会丢失、服务不会停止。用户写入的数据可以容忍少数节点的故障，同时，在节点故障时，系统总是可以自动选择新的副本作为主副本继续数据库的服务。
+
+OceanBase 数据库每个租户还有一个全局时间戳服务（GTS），为租户内执行的所有事务提供事务的读取快照版本和提交版本，保证全局的事务顺序。如果全局时间戳服务出现异常，租户的事务相关操作都会受到影响。OceanBase 数据库使用与分区副本一致的方案保证全局时间戳服务的可靠性与可用性。租户内的全局时间戳服务实际会由一个特殊的分区来决定其服务的位置，这个特殊分区与其他分区一样也有多副本，并通过选举服务选择一个主副本，主副本所在节点就是全局时间戳服务所在节点。如果这个节点出现故障，特殊分区会选择另一个副本作为主副本继续工作，全局时间戳服务也自动转移到新的主副本所在节点继续提供服务。
+
+以上是数据库集群节点实现高可用的关键组件，代理服务（ODP，也称为 obproxy）也需要高可用能力来保证其服务。用户请求首先到达的是代理服务，如果代理服务不正常用户请求也无法被正常服务。代理服务还需要处理数据库集群节点故障，并做出相应的容错处理。
+
+代理服务不同于数据库集群，代理服务没有持久化状态，其工作依赖的所有数据库信息都来自于对数据库服务的访问，所以代理服务故障不会导致数据丢失。代理服务也是由多台节点组成集群服务，用户的请求具体会由哪个代理服务节点来执行，应由用户的F5或者其他负载均衡组件负责，同时代理服务的某台节点故障，也应由负载均衡组件自动剔除，保证之后的请求不会再发送到故障节点上。
+
+代理服务工作过程会实时监控数据库集群的状态，一方面代理服务会实时获取集群系统表，通过系统表了解每台机器的健康状态和分区的实时位置，另一方面代理服务会通过网络连接探测数据库集群节点的服务状态，遇到异常时会标记相应节点的故障状态，并进行相应的服务切换。
+
+## 物理备库容灾
+
+物理备库容灾是 OceanBase 数据库高可用解决方案的重要组成部分。
+
+物理备库容灾技术面向多个集群，多集群间传输事务日志，建立基于日志的物理热备服务。在 OceanBase 数据库 V4.2.x 及以上版本，物理备库采用独立的主备库架构，主备关系存在于租户级别，主备之间通过网络直连或第三方日志服务建立传输渠道，只传输日志。不同于以前版本的集中式架构，独立主备库架构下，各个集群是是相互独立的，用户可以更加灵活地管理集群。
+
+租户级主备由于异步同步日志，仅支持最大性能模式，不支持最大保护和最大可用模式，容灾切换时需要保证数据强一致的场景可以采用多副本容灾方案或基于仲裁的容灾方案。

docs/user_manual/operation_and_maintenance/disaster_recovery_architecture_design/02_multi_replica_solution.md

@@ -0,0 +1,70 @@
+---
+title: 基于多副本的高可用解决方案
+weight: 2
+---
+
+## 基于 Paxos 一致性协议的多副本高可用解决方案
+
+  该方案基于Paxos一致性协议实现，通常在同一个集群内通过多副本（例如，三副本或五副本）提供容灾能力。
+
+  在少数派副本不可用（三副本集群允许一个副本不可用，五副本集群允许两个副本不可用）时，数据库可以自动执行容灾切换并恢复服务，保证不丢数据（RPO = 0），故障恢复时间在 8 秒以内（RTO < 8s）。
+
+用户可以通过灵活调整集群各个 Zone 的机房和 Region 分布，以及租户副本在这些 Zone 上的分布，从而调整租户的部署模式，达到不同的容灾级别。
+
+OceanBase 数据库支持的容灾等级如下所示。
+
+|    部署模式   | 最佳副本数  |         容灾场景       |       容灾能力      |
+|-------------|------------|-----------------------|-------------------|
+| 单机房       | 三副本      | 面向不具备多机房条件的场景。同机房内三副本组成一个集群，同一份副本尽量部署在相同容灾能力的一组机器上，例如：同一个机架、同一个电源等。| 能够防范少数派节点故障。无法防范机房级故障（例如，机房网络中断、电力中断等）、城市级故障（例如，地震、海啸、台风等自然灾害等）。|
+| 同城三中心   | 三副本     | 面向具备一个城市三个机房的场景。同城三个机房组成一个集群（每个机房是一个 Zone），机房间网络延迟一般在 0.5 ~ 2 ms 之间。| 能够防范少数派节点故障。能够防范单机房故障。无法防范城市级故障。|
+| 两地三中心    | 五副本     | 面向一个城市只具备两个机房的场景。主城市与备城市组成一个 5 副本的集群，主城市 4 副本分布于两个 IDC，备城市 1 副本。任何 IDC 的故障，最多损失 2 份副本，剩余的 3 份副本依然满足多数派。| 能够防范少数派节点故障。能够防范单机房故障。无法防范主城市的故障。|
+| 三地五中心    | 五副本     | 面向需要城市级容灾能力的场景。三个城市，组成一个 5 副本的集群。两个城市各 2 份副本，第三个城市 1 份副本。任何一个机房或者城市的故障，依然构成多数派，可以确保 RPO=0。 | 能够防范少数派节点故障。能够防范少数派机房故障。能够防范少数派城市故障。|
+
+
+三种部署模式示意图如下所示：
+
+* 同城三中心部署模式
+
+  ![同城三中心](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/observer-enterprise/V4.2.1/manage/three-IDCs-in-the-same-city.jpg)
+
+* 两地三中心部署模式
+
+  ![两地三中心](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/observer-enterprise/V4.2.1/manage/three-IDCs-across-two-regions1.jpg)
+
+* 三地五中心部署模式
+
+  ![三地五中心](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/observer-enterprise/V4.2.1/manage/five-IDCs-across-three-regions1.jpg)
+
+OceanBase 数据库的部署模式通过租户级别的 Locality 属性来描述，我们在《副本管理》章节中描述了三种部署模式的 Locality 示例，通过调整租户的 Locality 属性，从而达到灵活的部署模式，进而达到不同的容灾级别。详细信息参见 [Locality 介绍](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001050183)。
+
+多副本技术的容灾架构，其核心逻辑是通过 Paxos 协议保证事务日志达成多数派提交。如果发生故障的节点小于多半数，选举协议能够保证自动恢复，且 RPO = 0。如果多于半数的节点发生故障，就需要人工介入，可以通过单副本的方式拉起服务，由于少数派可能没有包含最新的数据，因此可能会丢失最后一部分数据。
+> **注意**
+>
+> 单副本拉起操作不是常规的运维操作，是集群无法恢复时最后的应急手段，有数据丢失和双主的风险，操作需要特别谨慎，请在 OceanBase 支持同学指导下进行，本文档暂不提供操作细节。
+
+
+在金融行业里，传统关系型数据库往往也部署成“两地三中心”架构，同城两个机房，一个主库，一个热备，异地一个冷备。虽然可以通过数据库原生的半同步机制来保证业务更新的同时也提交到备库，但并不是强保证机制，当主库出现故障时，备库依然可能没有最新的更新，并且强制将备库切为主库可能会导致数据丢失。这就意味着，传统关系型数据库的“两地三中心”架构要么选择高可用，要么选择强一致，无法打破 “CAP 理论”。但 OceanBase 数据库基于 Paxos 协议的多副本容灾技术真正做到了同城和异地的无损容灾，达到 RPO = 0，RTO < 8 秒。
+
+通过 OceanBase 数据库的多副本技术实现的容灾架构，应用只需要感知一个数据源，数据库内部复制的细节对应用完全透明。同时，它提供了单机级、机房级、甚至城市级故障的无损容灾能力，并且恢复时间小于 8 秒。
+
+### 单机容灾
+
+OceanBase 数据库内部的心跳机制能够自动处理节点异常，OBProxy 也能够感知节点异常状态，从而避免应用层对节点异常状态的感知。为了避免节点的非通断型故障引起的乒乓效应持续短暂影响应用，应该第一时间隔离异常节点，隔离异常节点的相关操作可参见 [隔离节点](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001050167)；如果隔离节点后自动产生的 Leader 不是最优，您可以通过主动切主的方式将 Primary Zone 切到指定 Zone，主动切主的详细操作请参见 [数据库层高可用](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001050139)。
+
+对于故障节点的后续处理，分为以下两种场景：
+
+* 故障 OBServer 可以重新启动
+
+  不论故障机器之前处于何种心跳状态，OBServer 重新启动后，OBServer 与 Root Service 之间的心跳数据包恢复以后，OBServer 可重新提供服务。重启 OBServer 的详细操作请参见 [重启节点](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001050176)。
+
+* 故障 OBServer 损坏，无法重新启动
+
+  在确认 OBServer 损坏无法重新启动后，需要走机器替换流程，即下线故障节点，并重新上线新机器。有关替换机器的详细操作请参见 [替换节点](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001050171)。
+
+### 机房容灾
+
+机房级容灾要求集群部署满足多机房部署条件，例如，同城三中心和两地三中心。该部署模式下，任何机房故障导致少数派副本不可用时，剩下的多数派副本依然可以继续提供服务，保证零数据丢失。如果机房故障仅影响到单个 Zone，您可以通过 Stop Zone 的方式隔离故障副本，通过 Stop Zone 隔离故障 Zone 的相关操作请参见 [隔离 Zone](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001050170)；如果机房故障影响到多个 Zone，您可以通过主动切主的方式将 Leader 切换到指定 Zone，主动切主的详细操作请参见 [数据库层高可用](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001050139)。
+
+### 城市容灾
+
+城市级容灾要求集群部署满足多城市部署条件，例如，三地五中心。该部署模式下，任意一个城市故障，最多损失两个副本，剩下的多数派副本依然可以继续提供服务，保证零数据丢失。如果自动选举产生的 Leader 不是最优，或者为了避免城市级故障的间隙性影响，您可以通过切主的方式将 Leader 切换到最优 Zone。

docs/user_manual/operation_and_maintenance/disaster_recovery_architecture_design/03_primary_standby_database_solution.md

@@ -0,0 +1,55 @@
+---
+title: 基于日志异步复制的物理备库解决方案
+weight: 3
+---
+
+  该方案类似于传统数据库的主备复制解决方案。两个或多个集群之间，允许以租户为粒度，通过异步复制 Redo 日志来构建租户级别的主备关系，提供计划内无损切换和故障时有损切换两种容灾能力。
+
+  该方案主要用于满足双机房或双地域场景下的容灾需求。主租户提供读写能力，备租户提供只读和容灾能力。在执行计划内无损切换时，主租户和备租户互换角色，不丢数据（RPO = 0），切换时间为秒级（RTO 为秒级）。
+
+  当主租户所在的集群出现故障后，可以执行有损切换，将备租户切换为主租户。此时不能保证不丢数据，RPO 大于 0，切换时间为秒级（RTO 为秒级）。
+
+
+## 物理备库容灾
+
+在一组使用物理备库的方案中，可以包含一个主租户和一个或多个备租户。主租户为业务提供读写服务，备租户通过 Redo 日志实时同步业务在主租户上写入的数据。
+
+一个主租户和对应的备租户可以部署在距离相近或相隔很远的多个不同的 OceanBase 集群中，也可以部署在同一个 OceanBase 集群中。相应的，同一个 OceanBase 集群中既可以包含主租户，也可以包含备租户，也可以同时包含主备租户。主租户和备租户的租户名称不要求相同，租户的资源规格、配置、Locality 等也不要求相同。
+
+此外，主租户和备租户既可以是单副本的租户，也可以是多副本或具备仲裁高可用能力的租户，不同的部署方式为租户提供不同级别的副本级容灾能力。
+
+租户级别的物理备库为用户的使用提供了极大的灵活性，下面介绍几种典型的部署使用场景。
+
+### 集群中仅有主租户或备租户
+
+在该部署方案中，用户有多个 OceanBase 集群，每个 OceanBase 集群包含的业务租户或者都是主租户，或者都是备租户。
+
+该部署方案是一种最典型的部署模式，用户可以使用物理备库功能完成异地容灾等各种所需的需求。
+
+部署架构图如下所示。
+
+![集群中仅有主租户或备租户](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/observer-enterprise/V4.2.1/manage/only-primary-tenants-or-standby-tenants-in-a-cluster.png)
+
+### 集群中既有主租户又有备租户
+
+在该部署方案中，用户有多个 OceanBase 集群，每个集群中既有主租户又有备租户，同时也允许集群中的租户只有主租户没有备租户。
+
+一个典型的使用场景如下：
+
+业务在两个不同的地域均有读写和异地容灾需求，因此需要在两个地域既有主库又有备库。在使用其他数据库基于主备的方案中，用户需要在两个地域各部署两个（或多个）集群，地域之间的集群互为主备。
+
+在 OceanBase 数据库的部署方案中，仅需要在两个地域各部署一个集群，通过租户级别的主备即可满足业务需求，大大简化数据库集群的管理复杂度。部署架构图如下所示。
+
+![集群中既有主租户又有备租户](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/observer-enterprise/V4.2.1/manage/both-primary-tenants-and-standby-tenants-in-a-cluster.png)
+
+### 主租户和备租户在同一个集群中
+
+在该部署方案中，用户只有一个 OceanBase 集群，主租户和对应的一个或多个备租户均在同一个 OceanBase 集群中。
+
+可能使用该种部署方案的场景如下：
+
+假设某个业务租户需要在业务升级前保留一个数据库的快照。此时可以为该业务租户在同一个集群内创建一个实时同步的备租户，并在业务执行升级操作前将该备租户暂停同步。之后，业务可以在主租户上进行任意读写操作（例如，进行业务升级），并且这些操作均不会影响备租户。后续若业务升级失败，可以将当前主租户删除，并将备租户切换为新的主租户（通过将新租户名修改为原主租户名，可以保证 Proxy 的访问不变）。
+
+部署架构图如下所示。
+
+![主租户和备租户在同一个集群中](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/observer-enterprise/V4.2.1/manage/the-primary-tenant-and-the-standby-tenant-in-the-same-cluster.png)