图 规模为3-3-3的OceanBase集群
上图是一个三副本部署的例子OceanBase集群里的各个OBServer的角色都是平等的除了包含RootService的三台OBServer略有不同外。所以搭建一个三副本集群通常机器要能等分三份分别划为不同的区域Zone存放。这是逻辑上的划分。物理上安置机器的时候尽可能是放到三个机房。如果没有三个机房放到一个机房的三个房间也行或者一个房间的三个机柜也行分别走不同的交换机。机器摆在哪里是容灾设计首先要考虑的。
等分三份后三个Zone的机器就可以一一对应起来所有的机器都安装observer程序。手动搭建集群的时候要从三个Zone里分别选中一台组成一个原始最小的OceanBase集群1-1-1启动时指定rslistrootservice简称rs为这三台机器。然后再分别把其他机器加到对应的zone里。所以安装一个3-3-3的OceanBase集群实际上是先启动一个1-1-1的小集群然后逐步扩容至3-3-3模式。
初次安装的时候稍有不对可能就无法启动集群OceanBase有个OCP产品可以自动化安装OceanBase集群。详情参见OceanBase官方文档。
当OceanBase集群搭建起来后就拥有了全部机器的可用资源每个机器会保留少量资源用于自身OS使用。那么现在OceanBase要怎么管理这些资源呢 在设定管理目标之前先可以看看传统商业数据主备模式的机器管理。Oracle的DataguardSQL Server的Mirror架构MySQL的Master-Slave架构默认只有主库提供读写服务备库一直处于恢复状态不提供服务。当然Oracle的active standby和MySQL的slave 其实也可以提供只读服务只不过应用要接受一些延时。这是特殊用法先不提。这里机器资源利用率就是50%准确的说我们指的是CPU利用率因为备库恢复使用的CPU资源不多。
OceanBase集群以三副本模式部署的时候每个数据在集群里都存了三份所以实际最大可用空间是整体空间资源的1/3。至于CPU利用率就看有多少台服务器提供读写服务。客户一开始使用的时候往往也是用1/3的机器提供读写服务。跟商业数据库不一样的地方是OceanBase并不定义某台机器是主某台机器是备。所以理论上每台机器都可以提供读写服务。但运维人员是否选择这样做是需要做一个综合考虑即在资源利用率和容灾目标方面做一个权衡。比如说如果每台机器都提供服务CPU和空间利用率都很高当有1或者2台主机故障时剩余的机器可能没有足够的空间和CPU来接纳故障机器的数据和接管故障机器的对外服务因为新机器CPU资源会紧张。决策的关键点是故障的概率究竟有多大和业务能承受数据库服务多大的损失。这点后面我们再看几个业务案例。
3.3 租户资源的分配
当OceanBase集群把所有机器资源聚合在一起的时候运维就可以管理这片资源了。当接到开发申请数据库的需求时运维评估给多大的资源比较合适。OceanBase相对传统商业数据库的一个优势就在这里运维不用特别担心租户资源评估出入太大。如果资源给少了后面可以弹性扩容如果资源给多了后面可以弹性收缩。能做到弹性是因为资源的分配都是逻辑的不跟具体的物理机绑定。
OceanBase对资源的分配采取了一定的策略。首先是定义几种常用的资源规格。每个规格定义了可以使用的cpu、memory、iops、disk size、session number的份额。如下例子是开发环境的几种规格给的都比较小。定义资源规格是标准化工作是规模化运维的前提。如果规模很小的话只要定义少数几类规格即可。
$ mysql -h100.82.127.89 -P3306 -uroot@sys#ant_dev_g -pcybE8oI9~ oceanbase -A
MySQL [oceanbase]> select unit_config_id, name, min_cpu, max_cpu, round(min_memory/1024/1024/1024) min_memory_gb, round(max_memory/1024/1024/1024) max_memory_gb,round(max_disk_size/1024/1024/1024) max_disk_size_gb from __all_unit_config;
---------------- --------------------------- --------- --------- --------------- --------------- ------------------
| unit_config_id | name | min_cpu | max_cpu | min_memory_gb | max_memory_gb | max_disk_size_gb |
---------------- --------------------------- --------- --------- --------------- --------------- ------------------
| 1 | sys_unit_config | 2.5 | 5 | 23 | 27 | 4173 |
| 1001 | B_unit_config | 0.25 | 0.25 | 1 | 1 | 120 |
| 1002 | LogOnlyNormal_unit_config | 1 | 1 | 2 | 2 | 500 |
| 1003 | LogOnlySystem_unit_config | 5 | 5 | 35 | 35 | 500 |
| 1004 | S0_unit_config | 1 | 1.5 | 4 | 4 | 500 |
| 1005 | S1_unit_config | 1.5 | 1.5 | 6 | 6 | 500 |
| 1006 | S2_unit_config | 3 | 3 | 12 | 12 | 500 |
| 1007 | S3_unit_config | 6 | 6 | 20 | 20 | 500 |
| 1008 | S4_unit_config | 12 | 12 | 40 | 40 | 500 |
---------------- --------------------------- --------- --------- --------------- --------------- ------------------
9 rows in set (0.01 sec)
有了资源规格就很容易想到在分配资源的时候选择合适的规格或者将多种规格叠加。OceanBase可以创建资源池ResourcePool一个资源池定义只能是一种规格但允许分配多个同等规格不允许包含两个不同规格的。注后续版本资源池改为支持多种规格的资源。当创建资源池的时候就会实际在每个Zone里分配一块或者多块资源单元Unit主要是CPU和内存、空间。具体是在哪台机器上分配Unit由OceanBase依据一定的分配策略判断。这个策略跟以下几点因素有关
·        Unit的规格对应的最大CPU和memory
·        OBServer的理论cpu利用率和memory利用率
·        参数resource_soft_limit 和 resource_hard_limit
·        同一个OBServer内不能有多个该资源池的Unit
图 OceanBase Resource和Unit
上图是一个4-4-4的OceanBase集群。创建了一个Resource Pool 01使用的是某种资源规格S并且Unit数量设置为2。于是OceanBase在每个Zone 挑2个有资源的机器从中分配2个同等大小的Unit绿色的。图中灰色的Unit是其他资源池的Unit。每个OBServer上每分配一个Unit其对应的资源CPU、Memory和disksize就相应的扣减该规格。
资源池创建好后再绑定到具体的租户里则租户就可以开始建库建表了。租户有个Primary zone属性会指定默认每个Partition的主副本主副本可以提供读写服务在哪个Zone。假设是Zone1。则建表的时候OceanBase会查该租户对应的资源池在Zone1里的Unit分布。如上图有2个OBServer上有Unit。有两个Unit可以选在哪个上面分配就依据一定的策略了。这个策略跟以下几个因素有关
Unit的load值
tablegroup和partitiongroup
Unit内的PartitionGroup数量
单个OBServer内最大partition数量
图: Partition在Unit内的分布
上图就是分区表order、order_item和非分区表base_config、以及其他表xxx的Partition可能的分布。分区表order和order_item是属于同一个tablegroup的它们的同号分区组成一个partition group。分区表的不同分区可能在一个Unit内部也可能不在一个Unit内部当有多个Unit的时候同一个partition group的多个分区一定在一个Unit内部。
Zone2和Zone3的机器跟Zone1里的机器一一对应其内部的Unit分布也是一一对应。Unit内的Partition可以理解为也是一样的。图中就省略了。
租户资源里的Unit使用的内存是独占的空间是名义上独占多个节点之间不能挪用。CPU资源是名义上独占但是可以在租户内部Unit之间挪用一部分只要总的使用配额符合定义即可。
3.4 总结
总结一下OceanBase 租户相关的对象创建过程。
OceanBase集群搭建好后默认有个系统租户sys。sys租户的root用户是集群里最大权限可以定义资源规格、创建资源池、OBServer的扩容和缩容、Partition的相关操作等等。
sys租户的root创建好用户租户后用户租户默认有root用户。
用户租户的root用户登录后可以创建数据库、定义表分组tablegroup、创建业务用户。
用户租户的业务用户登录后可以创建数据库对象。如表、视图、索引等等。
每个表至少有一个Partition。Partition是资源分配的最小单元、也是OBServer和Unit做负载均衡时的最小调度单元。
Zone内的OBServer可以在不停集群的情况下动态下线和上线租户的资源池的Unit可以在同一个Zone内多台OBServer之间内部动态迁移租户的表的Partition可以在租户的多个Unit内部动态迁移。这就是OceanBase扩展、均衡能力的基本原理。
运维人员可以通过sys租户的下面视图了解OceanBase细节。
视图名
作用
__all_server
所有observer信息
__all_unit_config
所有资源规格定义
__all_unit
所有已分配资源信息
__all_resource_pool
所有资源池定义
__all_tenant
所有租户信息
__all_table
所有表信息
__all_meta_table
所有副本信息
__all_root_table
所有系统表信息
__all_tablegroup
所有表分组信息
__all_rootservice_event_history
所有rootservice事件信息。内部元数据的变更、负载均衡和高可用都有rootservice服务管理。
v$sql
缓存的sql信息
v$sql_audit
所有sql运行日志
……
其他查看官方文档或者自己探索
4 再说分区Partition4.1 分区的副本类型
前面提了分区是存储用户数据的最小粒度是负载均衡调度的最小单元。当整体集群是三副本模式部署时每份数据都有三份具体体现就是每个分区也有三份。这三份就是三个副本内容一致。但是角色分工有不同。副本的类型有全功能副本Full、日志副本Log、只读副本Readonly。前面所提到的所有Partition都指的全能副本指既包含数据又包含事务日志。每个分区的三个副本一定是存在三个Zone里因为分区所在的Unit一定是分布在三个Zone里。副本的角色有主Leader副本和Follower副本。每个分区最多只有一个Leader副本如果都是Follower应用读写会报错找不到Leader副本。这种情形一般是副本角色切换的中间过程持续时间在10s以内是中间态。
OceanBase的数据更新同样遵守WALWrite-Ahead Log协议。在写数据之前会先写事务日志。在提交的时候Leader副本的事务日志会同时发往到其他Follower副本。三个副本里只要有一半成员副本很可能也包括Leader副本自己投票反馈事务日志落盘成功主副本上的事务就可以提交。这个机制就是通过Paxos协议保证的。OceanBase具体使用的是Multi-Paxos。
能参与投票的副本类型目前只有全能副本F和日志副本L只读副本R只接受事务日志但不投票。所以如果觉得多副本方案比较耗费机器的话另外一种选择就是将某个副本类型改为日志副本。但我们建议最少还是有三份数据。
只读副本的资源规格可以跟全能副本规格不一致因为租户可以关联多个不同资源规格的资源池只读副本可以从另外一个资源池的Unit里分配出来的。只读副本的使用场景一是读写分离二是可以跟一些分区表的副本做本地连接以规避跨节点表连接时性能问题。
4.2 分区Partition和高可用
再换个角度说每个分区的三副本构成一个Paxos组合这个组合能达到这样一个效果
每次选举只会选出最多一个Leader副本。即不会有脑裂。
只要多数派成员存活参与投票就一定可以选举出一个Leader副本。
当Leader副本失效时会在两个租约时间内自动选举出新的Leader副本。即自动故障切换Failover并且数据是强一致的。又叫高可用。
