专栏名称: AustinDatabases
PostgreSQL ACE ,PolarDB 3年, OceanBase 极速学习ING, MongoDB 8年经验, MySQL OCP, SQL SERVER, MCITP,REDIS ,做一个合格的数据库架构师
目录
相关文章推荐
数据中心运维管理  ·  一台交换机能带动多少网络摄像机? ·  昨天  
数据中心运维管理  ·  2025年数据中心值得关注的冷却趋势和策略 ·  21 小时前  
数据中心运维管理  ·  数据中心的等级划分 ·  3 天前  
AustinDatabases  ·  开源软件是心怀鬼胎的大骗局 -- ... ·  22 小时前  
AustinDatabases  ·  开源软件是心怀鬼胎的大骗局 -- ... ·  22 小时前  
AustinDatabases  ·  OceanBase ... ·  昨天  
51好读  ›  专栏  ›  AustinDatabases

OceanBase 架构学习--OB上手视频学习总结第二章 (OBCA)

AustinDatabases  · 公众号  · 数据库  · 2025-02-19 06:00

主要观点总结

文章主要介绍了如何加入一个数据库相关的交流群,以及文章接下来将详细讨论OceanBase数据库的学习框架、基本概念、架构、多租户、可用区、Observer、数据副本、日志流、Paxos协议、Root Service等概念,同时还会介绍OceanBase集群的扩缩容、负载均衡、数据副本与高可用性、多租户的优势、表组、自动补副本、容灾能力、RPO和RTO指标等内容。文章还涉及了其他数据库产品如PostgreSQL、MongoDB、MySQL、PolarDB等的介绍和讨论,以及阿里云数据库产品的使用体验。

关键观点总结

关键观点1: 加入数据库交流群

如果感兴趣数据库,可以加入文章提供的交流群,群内有各大数据库行业大咖,可以解决疑问。

关键观点2: OceanBase学习框架和基本概念

文章将介绍OceanBase的学习框架,包括6大学习法,以及OceanBase的基本概念,如多租户架构、集群、可用区、Observer、数据副本、日志流等。

关键观点3: OceanBase集群架构和扩缩容

讨论了OceanBase的集群架构,包括多节点、多副本、读写分离的特性,以及扩缩容的机制和策略。

关键观点4: OceanBase多租户优势和表组

分析了OceanBase的多租户架构优势,以及表组的概念,用于业务相关的表或分区汇聚到相同节点。

关键观点5: 阿里云数据库产品使用体验

文章还涉及了使用阿里云数据库产品的体验,包括权限设计缺陷、市场营销、客户服务、操作界面等问题。


正文


开头还是介绍一下群,如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题,有需求都可以加群群内有各大数据库行业大咖,可以解决你的问题。加群请联系 liuaustin3 ,(共2740人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9)(1 2 3 4 5 6 7群均已爆满+,开8群 9群)

一直提到框架学习法,其中主体的思想就是如何快速的学习某项数据库产品的知识。其中框架学习法里面有一条系统学习,系统学习是在给学习的知识搭建“骨架”,所以从这期起,开始搭建OceanBase学习的骨架。今年要和“申公豹”一样修炼岂可怠慢。

修炼岂可怠慢
修炼岂可怠慢

这里先解释一下什么是6大学习法,怎么将知识变成一种理念的过程,首先知识的学习是要以兴趣为动力的,没有兴趣去学习是无法提高学习的效率和成效的,在有了兴趣去学习后,那么上来就要上逻辑法,将学习的知识分成小块,也就是我们习以为常的总分总的分,在学习中不断的通过重复记忆,提炼的方法加深记忆,在理解了知识后, 使用庞统法,来将知识和周边的常识进行关联,最后通过费曼学习法将知识铁桶话,最后一步就是将学到的知识进行知行合一,这就是将知识转变为自己常识的知识学习6大法。学习OB的兴趣和动力我有了,下面首先就要上的是逻辑法,和重复记忆法。


此篇为OceanBase 视频学习总结的第二篇:这篇主要是围绕OBCA 4.0课程中的第二章中的三个小结进行学习

1  集群基本概念 2  路由与负载均衡 3  高可用部署架构

image
image

OceanBase 集群的基本概念、路由与负载均衡以及高可用部署架构总结如下: 集群基本概念

1整体架构

从业务流的视角来看,OceanBase 分布式数据库的访问可以分成四个层级:

1 应用层

2 负载均衡层

3 数据库代理层

4 后端的存储层

从 OceanBase 内部架构来看,它是一个多节点、多副本并且读写分离的架构。

从租户的角度,或者从多租户架构的角度来看:

一个数据库集群内可以划分多个业务租户,不同的租户之间资源与数据是隔离的。租户资源是以资源池的形式进行分配,对应用来说就相当于是一个个独立的数据库实例.

从用户的角度看: 系统分为系统组合和用户租户,系统租户在集群创建时默认创建,主要用来管理整个集群和所有租户。

用户租户由用户主动创建的业务租户,由用户负责租户内数据库对象的管理和访问,承载用户的业务数据。从 V4.0.0 版本开始,引入了 Meta 租户概念。

因此,当前版本对用户可见的租户有三种类型:系统租户、用户租户以及 Meta 租户。

从OB数据库的类型看,分为商业版本和开源版本,从数据库的兼容性看,分为 ORACLE 和 MySQL。

image
image
image
image

OceanBase 的基本概念: 基本概念关键词

1 多租户架构: OceanBase 采用多租户架构,允许在一个数据库集群内划分多个业务租户,以此实现资源和数据的隔离. 每个租户的资源以资源池的形式进行分配,对于应用程序来说,这就像是独立的数据库实例。

2 集群: 在物理层面上,OceanBase 集群分布在一个或多个数据中心的多台 observer 服务器上,这些服务器负责数据库的存储和计算服务。

3 可用区: 可用区是一个逻辑概念,每个可用区包含一份完整的数据副本. 例如,一个 OceanBase 数据库集群可能包含三个可用区,每个可用区由两台 observer 承载一份完整的数据副本。

4 Observer: Observer 是集群中承载数据、负责存储并提供计算服务的服务器. Observer 可以是物理服务器、ECS 或 Docker 容器。在 OceanBase 集群中,每个 observer 都可以同时提供存储和计算服务

5 数据副本 :为了保证数据与服务的高可用性,OceanBase 数据库会将同一份数据拷贝到多个可用区,每一份拷贝被称为一个副本. 在多个副本中,只有一个可以执行写操作,这个副本被称为主副本(Leader),其余的则为从副本(Follower). 从副本可以提供对数据一致性要求较低的读操作。

6 日志流: OceanBase 集群的多个副本之间通过同步事务日志来完成数据同步,这些在多个副本之间同步的事务日志被称为日志流。

7 paxos 协议 : 多副本之间日志流的同步依赖 Paxos 分布式一致性协议. 在更新数据时,对应的事务日志需要在多数派的副本同步成功才算提交完成. 副本的 leader 选举也依赖 Paxos 协议。

8 Root Service: Root Service 是 OceanBase 的核心模块,提供资源管理、容灾、负载均衡和 DDL 管理等功能. RS 负责租户的资源分配与管理,集群与租户的扩缩容,以及将租户的资源单元和 leader 节点合理地分布在不同的 observer 节点上,以达到负载均衡的目的。

image
image

OceanBase集群涉及租户和集群的扩缩容,并通过修改租户的资源单元个数来改变可用区下服务于该租户的observer个数。

OceanBase通过Root Service(RS)实现自动负载均衡能力,从而在数据库水平扩缩容与创建分区等场景下,达到各个服务节点上分区数与存储容量的均衡以及不同中间分区数量的均衡。

以下是关于OceanBase集群扩缩容的一些关键点:

资源管理 :Root Service(RS)负责租户的资源分配与管理,集群与租户的扩缩容等.

负载均衡 :RS将租户的资源单元以及leader节点合理地分布在不同的observer节点上,以达到负载均衡的目的。

水平扩缩容 :通过修改租户的资源单元个数来改变每一个可用区下服务于该租户的observer个数。

自动负载均衡 :在数据库水平扩缩容与创建分区的场景下,可以达到各个服务节点上分区数与存储容量的均衡,以及不同中间分区数量的均衡。

仲裁服务 :在3D5中心的部署架构里,可以使用仲裁服务来降低第三个城市的数据中心的建设成本, 仲裁服务是 OceanBase V4 版本引入的一种新的高可用机制. 仲裁服务作为中立的第三方,只参与副本 leader 选举相关的投票,不同步事务日志和数据。

image ·

数据副本与高可用 数据可以跨越多个数据中心,集群中的数据可以有多个副本。当集群有多个副本时,这是一个分布式集群,数据副本是一个完整的数据集合。OceanBase 通过日志流来实现多个副本的协同。当一个副本出现故障,其他副本可以继续提供数据的读写服务,以此实现数据库的高可用。

可用区和租户的知识详解:

定义:可用区(Zone) 是一个逻辑概念,代表数据副本的集合. 每一个可用区都包含一份完整的数据副本。

多副本集群:在 OceanBase 数据库集群中,一个典型的配置是包含三个可用区,例如 Z1、Z2 和 Z3,这构成一个三副本集群。

Observer 节点: 每个可用区下通常有多台 Observer 服务器,用于承载完整的数据副本. 例如,一个可用区下可能有两台 Observer 节点来承载数据副本。

Paxos 协议: OceanBase 分布式数据库使用 Paxos 多数派协议来保证多个副本之间数据的一致性. 这意味着数据的更新必须在多数派的副本中完成同步. 对于三副本集群,多数派副本数是2。

Primary Zone 设置: OceanBase 允许设置租户级别的 Primary Zone,将租户的 Leader 副本分配到指定的可用区内,从而影响业务流量的分布. 例如,将 Primary Zone 设置为 ZONE1,则该租户所有表或分区的 Leader 副本均在 ZONE1,数据访问均在 ZONE1 内完成.

优先级设置 :Primary Zone 可以设置优先级,使用分号分隔表示不同的优先级,逗号分隔表示相同的优先级. 例如,"ZONE1; ZONE2; ZONE3" 表示 ZONE1 > ZONE2 > ZONE3 的优先级,而 "ZONE1, ZONE2; ZONE3" 表示 ZONE1 等于 ZONE2 且都高于 ZONE3 的优先级。

数据分布和流量控制:通过合理设置 Primary Zone,可以控制数据分布和业务流量,在多地多中心的部署场景中尤其有用。

image


从用途上,租户可以分为系统租户和用户租户:

系统租户:在集群创建时默认创建,主要用于管理整个集群和所有租户。系统租户的数据是集群私有的,不与其他租户共享数据,并且是MySQL模式的租户。Root Service (RS) 作为系统租户的内置服务运行在系统租户的leader节点上。

用户租户: 由用户主动创建的业务租户,用户负责租户内数据库对象的管理和访问,承载用户的业务数据。

Meta租户: 存储管理用户租户的Meta信息,例如租户的位置项、副本位置信息以及租户管理相关的信息等。Meta租户是用户租户的影子租户,OceanBase自动为每一个用户租户创建一个Meta租户,其生命周期和用户租户保持一致。(V4版本)

租户ID: 系统租户的ID固定不变,用户租户的ID从1002开始分配,且为偶数,比用户租户ID小1的ID会分配给对应的Meta租户。

租户命名 :系统租户名为SYS,不可修改;用户租户的名字可以修改;Meta租户的名称由系统指定,不可修改,规则为Meta加用户租户的ID。

数据属性:系统租户包含集群的私有数据,Meta租户包含租户的私有数据,用户租户保存用户的真实业务数据。

访问方式: 系统租户、用户租户均可以连接访问Meta租户。 租户隔离: 租户隔离是多租户架构的关键,OceanBase通过以下方式实现租户隔离:

资源隔离: 租户之间除了数据隔离外,CPU资源、内存资源以及I/O资源也是隔离的。

数据隔离: 每个租户相当于一个独立的MySQL实例,租户之间的数据是隔离的。

权限管理和命名空间隔离: Database是数据库对象的集合,用于权限管理和命名空间隔离,是一个逻辑概念。

多租户的优势: 多租户架构适用于微服务架构和云上的SaaS服务商,可以平衡隔离性和成本,并且大小租户可以独立进行扩缩容。

image
image
image

租户扩缩容与日志副本日志流部分详解

1 租户扩缩容要点

资源管理:Root Service(RS)负责租户的资源分配与管理,集群与租户的扩缩容等。

负载均衡: RS将租户的资源单元以及leader节点合理地分布在不同的observer节点上,以达到负载均衡的目的。

水平扩缩容: 通过修改租户的资源单元个数来改变每一个可用区下服务于该租户的observer个数。

自动负载均衡 :在数据库水平扩缩容与创建分区的场景下,可以达到各个服务节点上分区数与存储容量的均衡,以及不同中间分区数量的均衡。

image

副本--日志流---Paxos协议这三者的关系式

OceanBase通过多副本实现高可用性,日志流用于副本间的数据同步,而Paxos协议是保证数据一致性的基础

image

ceanBase通过多副本实现高可用性,日志流用于副本间的数据同步,而Paxos协议是保证数据一致性的基础. 以下是关于副本、日志流和Paxos协议的要点:

副本 (Replicas)

OceanBase数据库将同一份数据拷贝到多个可用区,每一份拷贝被称为副本。

多个副本中只有一个主副本(Leader),负责执行写操作,其他是从副本(Follower),可以提供对数据一致性要求较低的读操作。当主副本发生故障时,OceanBase会自动从从副本中选举新的主副本。副本的数量通常为奇数,如3副本或5副本,以满足Paxos协议的多数派要求。

日志流 (Log Stream)

OceanBase集群的多个副本之间通过同步事务日志来完成数据同步,这些同步的事务日志称为日志流。

在V4版本中,OceanBase像单机数据库一样处理事务日志,将一个租户在同一台observer下的所有leader分区作为一个整体来写事务日志,并作为一个日志流在多个副本之间进行同步,这被称为单机日志流。在单机日志流的架构下,事务的参与者从一个个分区变成了observer节点。扩缩容时,相应的日志流需要做拆分,并分布到更多的observer节点上去。

Paxos 协议

Paxos是OceanBase分布式架构的基础,多副本之间日志流的同步离不开Paxos分布式一致性协议。在对数据进行更新时,对应的事务日志需要在大多数副本同步成功才算提交完成。OceanBase通过Paxos协议实现分区级别的高可用性,可以简单理解为一个Paxos组包含一个分区的3个副本,包括一个主副本和2个从副本。Paxos协议可以确保事务的协调者和参与者都是多副本、高可用的,副本的leader选举也依赖Paxos协议。

OceanBase 数据库访问代理的概念和详解:

image

OceanBase数据库访问代理(ODP),也称为OBProxy,在OceanBase的分布式架构中扮演着关键角色,它为应用提供统一的数据访问入口,并负责实现自动的访问路由服务。 以下是关于OceanBase数据库访问代理 (ODP) 的一些关键要点:

统一访问入口: 在没有ODP的情况下,应用服务器需要感知数据的分布位置,并直接连接到不同的Observer节点来实现业务访问,这显然是不现实的。ODP的出现,使得应用只需连接到ODP,即可访问整个分布式数据库集群,无需关心数据存储在哪个Observer节点上。

反向代理: ODP作为数据库服务的反向代理,能够感知数据库集群内表和分区的位置,并将不同的数据访问请求发送到对应的Observer节点上。

高可用性: 为了避免ODP故障导致数据库访问的不可用,通常会部署多个ODP节点,实现ODP的高可用。

无状态服务: ODP是一个无状态的服务进程,不做数据保留,多个OBProxy之间也没有关联,互相不感知。

主要能力:

数据库服务反向代理: 感知数据库集群内表和分区的位置,将数据访问请求发送到对应的Observer节点。

Observer状态感知: 可以自动屏蔽问题节点,避免将SQL请求发送到故障节点上。

轻量级SQL解析: 仅对SQL做轻量化的解析,不做数据的加工处理,从而提供非常高的性能。单个OBProxy进程每秒可提供百万次的SQL路由服务.

连接管理: 将应用到数据库的连接分成两段,一段是应用到OBProxy的连接,一段是OBProxy到Observer的连接,从而提供连接管理能力.

负载均衡: 当部署了多个OBProxy服务时,需要在应用与数据库代理之间部署负载均衡设备,为所有OBProxy节点提供统一的VIP或者域名,让应用统一连接这个VIP,从而将并发的应用请求按照设定的规则分散到不同的OBProxy节点上,实现负载均衡与高可用

Primary Zone 的作用和定义:

image

Primary Zone 是 OceanBase 中一个用于影响业务流量分布的重要配置。 通过设置租户的 Primary Zone,可以将租户的 leader 副本分配到指定的可用区内,从而控制业务流量的分布。 以下是关于 Primary Zone 的一些关键要点:

定义:Primary Zone 是一个可用区(Zone)的集合。

作用:通过设置 Primary Zone,可以将租户的 Leader 副本分配到指定的可用区内,从而影响业务流量的分布。

流量控制:

例如,将租户的 Primary Zone 设置为 ZONE1,则该租户所有表或分区的 Leader 副本均在 ZONE1,数据的访问均在 ZONE1 内完成,业务请求也只会路由到 ZONE1。

优先级设置:

Primary Zone 可以设置优先级,使用分号 ; 分隔表示不同的优先级,逗号, 分隔表示相同的优先级。

例如,ZONE1; ZONE2; ZONE3 表示 ZONE1 > ZONE2 > ZONE3 的优先级。

ZONE1, ZONE2; ZONE3 表示 ZONE1 等于 ZONE2 且都高于 ZONE3 的优先级。

流量均分:

如果要把业务流量均分到 ZONE1 和 ZONE2,而不分配到 ZONE3,那么需要设置 Primary Zone 为 ZONE1, ZONE2; ZONE3。

如果要把业务流量均分到所有 Zone,那么需要设置 Primary Zone 为 ZONE1, ZONE2, ZONE3。

多地多中心部署:Primary Zone 的设置在多地多中心的部署场景中尤其有用,可以基于性能的考虑,将特定的业务流量聚集到特定的数据中心或者可用区。

无法完全避免跨节点数据访问:当租户的 Zone 多于一个 Zone 时,或者租户的 Primary Zone 只有一个,但是一个 Zone 内有多个跨机房的节点,Primary Zone 的设置并不能完全避免跨节点数据访问的问题。

image

什么是表组,表组的定义属性等概念

image

表组(Table Group) 功能用于将业务相关的表或分区汇聚到相同的节点,以便更精细地控制数据分布和业务流量。

以下是关于如何使用表组(Table Group)将业务相关的表或分区汇聚到相同节点的一些关键点:

表组的定义:表组提供了一种能力,按照一定的规则将表组内的表或分区进行聚合。

表级属性:表组是表级别的属性,可以在创建表或者修改表时指定表所在的表组。

Sharding 模式:表组根据其定义的 Sharding 模式的不同,可以对表组内的表和分区进行不同程度的聚集。 OceanBase 表组提供三种 Sharding 模式:SHARDING=NONE、SHARDING=DUPLICATED和SHARDING=PARTITION.

SHARDING=NONE:最宽松的标准模式,不要求表组内表的分区方式相同,即可以包含分区表,也可以包含非分区表。

SHARDING=DUPLICATED:OceanBase 会将表组内的所有表和分区都聚集在相同的 Observer 上,它们的 leader 副本也聚集在同一台 Observer 上,对于应用来说,表组内的表提供了类似集中式数据库的访问性能。

SHARDING=PARTITION:对表组内的表的分区方式有要求,按照分区号对表组内的表进行相应的聚集。

聚集效果:对于SHARDING=DUPLICATED模式,OceanBase 会将表组内的所有表和分区都聚集在相同的 Observer 上,它们的 Leader 副本也聚集在同一台 Observer 上。对于应用来说,表组内的表提供了类似集中式数据库的访问性能。 因此,通过将 Sharding 模式设置为 SHARDING=DUPLICATED,可以将业务相关的表分区汇聚到相同的节点上,从而优化性能。

image
image

OceanBase的负载均衡具有以下特点:

Root Service (RS) 负载均衡: OceanBase集群依赖Root Service总控服务来实现分布式架构下的高可用能力. RS作为系统租户的内置服务,提供负载均衡的职能,将租户的资源单元以及leader节点合理地分布在不同的observer节点上,达到负载均衡的目的。

自动负载均衡能力: OceanBase通过RS服务实现了自动的负载均衡能力。在数据库水平扩缩容与创建分区的场景下,可以达到各个服务节点上分区数与存储容量的均衡,以及不同中间分区数量的均衡。

OBProxy 负载均衡: 当部署了多个OBProxy服务时,需要在应用与数据库代理之间部署负载均衡设备,为所有的OBProxy节点处于统一的VIP或者域名,让应用统一连接这个VIP。这样可以将并发的应用请求按照设定的规则分散到不同的节点上,实现负载均衡与高可用。

单机分布式一体化架构下的负载均衡 :OceanBase在分布式部署的时候,可以自动地进行负载均衡。

image

image

容灾能力和高可用方案比较:

无需停机扩展:

无论是单机转数据库,还是垂直扩展增加单机的规格,或是水平扩展增加 Zone 的节点数或增加 Zone 的数量,OceanBase 都不需要停机停服,对上层业务无感知。

自动故障恢复:

OceanBase 具有自动故障恢复能力,当包含 Leader 副本的 Observer 节点发生故障时,会自动进行选举操作,从 Follower 副本中选出新的 Leader 继续提供服务。

如果发生故障的 Observer 节点只包含 Follower 副本,只要剩余的副本数依然满足多数派的要求,节点故障对数据库集群和业务访问均没有影响。

OceanBase 提供自动补副本的能力,如果某个 Observer 节点出现故障,且故障时间达到一定的阈值,OceanBase 会将故障节点永久下线,并将故障节点上的副本剔除,然后在同一个可用区内的其他 Observer 节点上重建这些副本

多副本机制:

OceanBase 通过将同一份数据拷贝到多个可用区来实现数据库的高可用。

每个可用区包含一份完整的数据副本

多个副本中,只有一个是主副本(Leader),负责写操作,其他的为从副本(Follower),提供对数据一致性要求较低的读操作。

当主副本出现故障时,OceanBase 会自动从从副本中选举出新的主副本。

image

仲裁服务:

OceanBase V4 版本引入了仲裁服务,作为一种新的高可用机制。

仲裁服务代表中立的第三方,只参与副本 Leader 选举相关的投票,不同步事务日志和数据,资源要求非常低。仲裁服务还提供集群副本数自动升降级的能力。

OceanBase 中 RPO 和 RTO 指标的内容如下:

RTO(Recovery Time Objective,服务恢复时间目标):指的是数据库在发生故障之后,需要经过多久时间才能恢复对外服务。RTO 的实际意义是当发生故障之后,数据库需要经过多久时间才能恢复对外服务。通常数据库故障恢复的 RTO 总是大于 0 的。

RPO(Recovery Point Objective,数据恢复目标):指的是数据库的数据恢复目标,代表了服务的可用性。RPO 的实际意义是,当发生故障之后,数据库可能丢失的数据的时间范围是多少。RPO=0 时,表示没有数据的丢失。

OceanBase 的 RPO 和 RTO:

OceanBase 原生分布式架构可以满足金融行业的 6 级容灾标准,也是最高的容灾标准。

在 V4 版本,OceanBase 进一步提升了高可用能力,在数据零丢失及 RPO 等于零的基础上,将服务恢复时间缩短到了 8 秒以及 RTO<8 秒,树立了行业的新标准。

与传统集中式数据库相比,OceanBase 在高可用能力的优势最重要的一点是 RPO=0,数据零丢失。在多副本的架构下,发生少数派故障不会导致数据丢失。

OceanBase 有自动的容灾恢复和负载均衡机制,可以在少数派故障发生后,在 8 秒钟之内完成 leader 副本的切换和服务的恢复

image

image

OceanBase的自动补副本具备以下特点

自动触发: 如果某个Observer节点出现故障,并且故障时间超过设定的阈值,OceanBase会将该故障节点永久下线,并从集群中移除该节点上的副本。

副本重建 :OceanBase会在同一个可用区内的其他Observer节点上重建这些副本。 由于一个可用区内只能有一个副本,补副本操作只能在发生故障的可用区内进行。

资源依赖: 副本是否能够成功重建,取决于可用区内正常运行的Observer节点上是否有足够的资源。

目的 :在leader副本重新选举后,集群在缺失副本的情况下运行,为了避免再次发生宕机故障导致集群不可用,OceanBase提供自动补副本的能力。

image

image

image

image

OceanBase 的同城双中心主备、同城三中心仲裁和三地五中心仲裁的容灾部署方案具有以下特点:

同城双中心主备互备架构:

在机房 IDC E1 的 OceanBase 集群 1 中创建主租户 1,并在机房 IDC2 的 OceanBase 集群 2 中创建主租户 2。在两个集群中分别创建对方集群的备租户。既实现了传统主备库的高可用,又解决了传统备库无法提供业务服务的问题。

同城三中心仲裁高可用部署:

可以在每一个中心都部署全功能副本,构建一个三副本或五副本的集群。也可以在第三中心只部署仲裁服务,构建一个 2F1A 或 4F1A 的集群。使用仲裁服务可以大幅降低第三中心的建设成本,因为仲裁服务对资源和网络带宽的要求很低。

三地五中心仲裁架构:

最极致的容灾架构,可以应对城市级灾难。当一个数据中心甚至一个城市发生故障时,仍然有多数派的副本可用,保证集群的高可用。可以使用仲裁服务来降低第三个城市的数据中心的建设成本。如果出现中心级故障,比如 IDC1 发生断电,仍然有三个全功能副本可用,满足多数派要求,所以不会导致集群不可用。如果出现城市级故障,比如主城市 1 类的 IDC1 和 IDC2 同时不可用,主城市 2 里面的 IDC3 和 IDC4,加上仲裁服务,依然满足多数派的要求,不会导致集群不可用。仲裁服务检测到同一个城市的两个副本均出现故障后,会自动进行降副本的操作,将 4 个副本加仲裁降级为 2 个副本加仲裁。

image



写到最后,如果你意识到这是你最后一次机会的时候,你一定
不会浪费每一分,每一秒,每一天,珍视你每一次向上的力
量,无视周围嘈杂的声音--
一个现实中的申公豹的留言

置顶

AI 祸国殃民必须铲除,AI国强民富必须支持

公众号给我两个数字 34.6万,65.5万--告别2024

云不云的,我不晕,从今天起云专栏的喇叭开始广播了。

没有谁是垮掉的一代--记 第四届 OceanBase 数据库大赛

ETL 行业也够卷,云化ETL,ETL 软件不过了


OceanBase 相关文章
OceanBase 6大学习法--OB上手视频学习总结第一章
没有谁是垮掉的一代--记 第四届 OceanBase 数据库大赛
OceanBase  送祝福活动,礼物和幸运带给您

跟我学OceanBase4.0 --阅读白皮书 (OB分布式优化哪里了提高了速度)

跟我学OceanBase4.0 --阅读白皮书 (4.0优化的核心点是什么)

跟我学OceanBase4.0 --阅读白皮书 (0.5-4.0的架构与之前架构特点)

跟我学OceanBase4.0 --阅读白皮书 (旧的概念害死人呀,更新知识和理念)

聚焦SaaS类企业数据库选型(技术、成本、合规、地缘政治)

OceanBase 学习记录-- 建立MySQL租户,像用MySQL一样使用OB
OceanBase  学习记录 -- 安装简易环境
OceanBase  学习记录 --  开始入门
数据库最近第一比较多,OceanBase 定语加多了?
临时工访谈:OceanBase上海开大会,我们四个开小会 OB 国产数据库破局者
临时工说:OceanBase 到访,果然数据库的世界很卷,没边
数据库信息速递  阿里巴巴的分布式数据库OceanBase旨在进军中国以外的市场 (翻译)
PostgreSQL 相关文章
PostgreSQL  添加索引导致崩溃,参数调整需谨慎--文档未必完全覆盖场景
PostgreSQL 的搅局者问世了,杀过来了!
PostgreSQL SQL优化用兵法,优化后提高 140倍速度
PostgreSQL 运维的难与“难”  --上海PG大会主题记录
PostgreSQL 什么都能存,什么都能塞 --- 你能成熟一点吗?
PostgreSQL 迁移用户很简单 ---  我看你的好戏

PostgreSQL 用户胡作非为只能受着 --- 警告他

全世界都在“搞” PostgreSQL ,从Oracle 得到一个“馊主意”开始
PostgreSQL 加索引系统OOM 怨我了--- 不怨你怨谁

PostgreSQL “我怎么就连个数据库都不会建?” --- 你还真不会!

病毒攻击PostgreSQL暴力破解系统,防范加固系统方案(内附分析日志脚本)
PostgreSQL 远程管理越来越简单,6个自动化脚本开胃菜

PostgreSQL 稳定性平台 PG中文社区大会--杭州来去匆匆

PostgreSQL 如何通过工具来分析PG 内存泄露

PostgreSQL  分组查询可以不进行全表扫描吗?速度提高上千倍?

POSTGRESQL --Austindatabaes 历年文章整理

PostgreSQL  查询语句开发写不好是必然,不是PG的锅

PostgreSQL  字符集乌龙导致数据查询排序的问题,与 MySQL 稳定 "PG不稳定"
PostgreSQL  Patroni 3.0 新功能规划 2023年 纽约PG 大会 (音译)
PostgreSQL   玩PG我们是认真的,vacuum 稳定性平台我们有了
PostgreSQL DBA硬扛 垃圾 “开发”,“架构师”,滥用PG 你们滚出 !(附送定期清理连接脚本)

DBA 失职导致 PostgreSQL 日志疯涨


MongoDB 相关文章

MongoDB  大俗大雅,上来问分片真三俗 -- 4 分什么分

MongoDB 大俗大雅,高端知识讲“庸俗” --3 奇葩数据更新方法

MongoDB 学习建模与设计思路--统计数据更新案例

MongoDB  大俗大雅,高端的知识讲“通俗” -- 2 嵌套和引用

MongoDB  大俗大雅,高端的知识讲“低俗” -- 1 什么叫多模

MongoDB 合作考试报销活动 贴附属,MongoDB基础知识速通

MongoDB 年底活动,免费考试名额 7个公众号获得

MongoDB 使用网上妙招,直接DOWN机---清理表碎片导致的灾祸 (送书活动结束)

数据库 《三体》“二向箔”  思维限制 !8个公众号联合抽奖送书 建立数据库设计新思维

MongoDB  是外星人,水瓶座,怎么和不按套路出牌的他沟通?

17000多张MongoDB表的锅 自动分析删除表数据难题--从头到尾的处理过程(文尾有MongoDB开发规范)
MongoDB 插入更新数据慢,开发问哪的问题?附带解决方案和脚本
MongoDB 不是软柿子,想替换就替换
MongoDB  挑战传统数据库聚合查询,干不死他们的 MongoDB 2023纽约 MongoDB 大会 -- 我们怎么做的新一代引擎 SBE Mongodb 7.0双擎力量(译)
MongoDB 2023年度纽约 MongoDB 年度大会话题 -- MongoDB 数据模式与建模
MongoDB  双机热备那篇文章是  “毒”
MongoDB   会丢数据吗?在次补刀MongoDB  双机热备
MONGODB  ---- Austindatabases  历年文章合集

MySQL相关文章

MySQL 怎么让自己更高级---从内存表说到了开发方式
MySQL timeout 参数可以让事务不完全回滚

"DBA 是个der" 吵出MySQL主键问题多种解决方案

MySQL 让你还用5.7 出事了吧,用着用着5.7崩了

MySQL 的SQL引擎很差吗?由一个同学提出问题引出的实验
用MySql不是MySQL, 不用MySQL都是MySQL 横批 哼哼哈哈啊啊






请到「今天看啥」查看全文