*79
、
OceanBase
的
Paxos
协议,不同于传统的主备库或者双活方案,可以彻底规避在容灾场景下的脑裂问题(也就是同时有两个主数据库的场景)。
O
对
O
错
*80
、每台
OB Server
是相对独立的,都有自己独立的
SQL
引擎,如果应用需要的数据不在当前OB Server
上,该
OB Server
将协调其他
OB Server
的数据,统一反馈给应用,这个过程对应用是透明的。
O
对
O
错
*81
、主副本通过同步
Redo-Log
日志的方式实现可靠性,主副本需要收到所有从副本落盘成功的消息后才能响应应用。
O
对
O
错
*82
、假如一个分区有
3
个副本,其中
1
个是主副本,剩余
2
个是从副本,一般情况下,业务读写操作均访问该主副本。
〇
对
O
错
*83
、管理员需要手工指定一个分区的哪个副本是主副本,哪个是从副本。
O
对
O
错
*84
、分区的副本只包含硬盘上的静态数据(
SS Table
),不包括
Mem Table
数据和日志数据。
〇对
O
错
*85
、主副本只能打散到所有
Zone
内,实现访问流量的负载均衡,不能将主副本聚焦到一个Zone
内。
O
对
O
错
*86
、
OceanBase
可以支持在一个数据库中同时支持
MySQL
租户和
Oracle
租户。
O
对
O
错
*87
、
OceanBase
通过
Explain
命令查看优化器针对给定
SQL
生成的逻辑执行计划,
Explain
所展示的计划是在执行命令时优化器根据当前的用户输入和数据统计信息所生成的逻辑执行计划,
而并不是在计划缓存中真正被使用的物理执行计划。
O
对
O
错
*88
、租户逻辑上类似传统数据库的实例,创建完成后,每个租户都将有自己的专属进程。
O对
O
错
*89
、如果要部署一个
“5-5-5”
的集群,也就是集群有
3
个
Zone
,每个
Zone
有
5
台服务器,一共15
台服务器。创建集群时,只需要指定
RootService
所在的
3
台机器,不需要在创建集群时就78
、指定所有
15
台机器。集群创建成功后,再将剩余的
12
台服务器添加进集群。
O对
O
错
*90
、
OceanBase
只支持
X86
架构的
CPU
,不支持其他
CPU
(如鲲鹏、海光、飞腾等)。
O
对
O
错
*91
、
memory_limit_percentage
设置成
90
,意味着
memtable
内存写入到
90%
会触发合并操作。
O
对
O
错
*92
、会话变量只对当前会话生效,不影响该租户下的其他会话。
O
对
O
错
*93
、
Global
级(租户级)变量修改后,对当前已经打开的
session
也依然生效。
O
对
O
错
*94
、普通租户只能设置自己租户的参数,系统租户可以查看和设置所有租户的参数(包括系统租户和普通租户)。
O
对
O
错
*95
、普通租户无法更改自身的系统变量,需要系统租户(
sys
)来更改普通租户的系统变量。
O
对
O
错
*96
、
OceanBase
数据库是在阿里和蚂蚁内部孵化了
10
年后才逐步推广到外部市场的。
O对
O
错
*97
、
OceanBase
数据库是基于开源数据库的再发行产品。
O
对
O
错
*98
、
TPC-C
就是一个跑分测试,官方没有什么规则限制,只要能跑高分就行。
O
对
O
错
*99
、
OceanBase
已发布到阿里云公有云及专有云中。
O
对
O
错
*100
、合并必须依赖
OceanBase
自动完成,无法手工启动合并。
〇对
O
错
*101
、
OceanBase
的数据在磁盘中按主键有序排列。
O
对
O
错
*102
、分库分表的架构虽然解决了集中式数据库的扩展性问题,但也带来了新的问题(不支持复杂SQL
,较难保证分布式事务的
ACID
等)。
O
对
O
错
*103
、一般情况下,每台
OB Server
都有主副本和从副本,实现整体的负载均衡,避免出现OB Server
忙闲不均的现象。
〇对
O
错
*104
、应用通过
OB Proxy
连接到
OceanBase
集群,比直连主副本所在的
OB Server
性能更好?
〇对
O
错
*105
、对于一个三副本的集群(有三个
Zone
)。企业在一个城市有两个机房,将两个Zone
部署到
1
个机房中,将另一个
Zone
部署到另一个机房中,可以提供机房级的容灾。
〇对
O
错
*106
、
OceanBase
除了支持同城三机房及三地五中心五副本高可用方案外,也支持传统的同城两机房方案和两地三中心方案,以便更好的利旧企业已有的基础设施。
〇对
O
错
*107
、
OceanBase
在少数副本不可用的情况下,可以实现
RPO=0
,
RTO<30
秒。
O
对
O
错
*108
、每个数据库服务的实例(租户)不感知其他实例(租户)的存在,租户拥有一组计算和存储资源,提供一套完整独立的数据库服务。
O
对
O
错
*109
、一个租户在同一个
Server
上可以有一个或多个资源单元
UNIT
。
O
对
O
错
*110
、创建资源单元仅仅指定
CPU
,
MEMORY
参数即可,无需指定
lOPS
,DISK_SIZE,
SESSION_NUM
参数。
O
对
O
错
*111
、同一个资源单元定义
unit config
(比如
2C8G
,或者
4C16G
等),可以被多个资源池使用。
O
对
O
错
*112
、
RootService
总控服务需要部署到每一台
0B Server
中。
O
对
O
错
*113
、
Zone
可以对应不同的城市,或者一个城市的不同机房,或者一个机房的不同机架,以实现不同级别的容灾。
O
对
O
错
*114
、
Zone
是个逻辑概念,是给集群内的一批机器打上同一个
tag
,属于同一个tag的服务器归属一个
Zone
。
O
对
O
错
*115
、租户的资源池一旦创建完成,就不可以改变。如果需要扩容,需要删除旧资源池,创建一个更大规模的资源池。
O
对
O
错
116
、创建租户时,需要指定租户类型为
Oracle
租户或者
MySQL
租户,以满足不同开发者的需求。
O
对
O
错
*117
、扩容服务器加入集群后,集群会基于负载均衡的策略,自动的将部分主副本和从副本迁移到扩容服务器中,以实现整体的负载均衡。
〇对
O
错
118
、修改资源池可以实现租户的另一种扩容
/
缩容的方式。比如在每个
Zone
中增加/
减少节点数量,可以通过修改资源池的
unit_num
来实现。
O对
O
错
*119
、在
OCP
中,可以选择某台
observer
进行
“
重启
”
,这个操作后台是通过系统租户登录,对该台机器的ip
地址,执行
stop server
操作,将这台机器上的读写流量切走。然后重新启动observer
进程,最后通过
start server
恢复服务
O
对
O
错
*120
、
OCP
是管理单元,只支持单机部署,不支持多节点高可靠部署。
O
对
O
错
*121
、通过
OCP
删除
OBServer
后,系统将会删除该
OBServer
的所有数据,且无法恢复,请谨慎操作。
O
对
O
错