作者简介：郑皓嘉，OceanBase 认证高级讲师
知识点目录
一、OceanBase 集群技术架构
1、Paxos 协议与负载均衡
2、动态扩容和缩容
3、数据可靠及高可用
4、分布式事务、MVCC、事务隔离级别
二、OceanBase SQL 与存储引擎
1、SQL 引擎
2、存储引擎
三、OceanBase 管理工具
1、OceanBase 连接方式
2、OceanBase 平台简介
四、试题解析
五、Q&A
正文：
一、OceanBase 集群技术架构
1、Paxos 协议与负载均衡
a. 多副本一致性协议
- 以分区为单位组建 Paxos 协议组：
每个分区都有多份副本（Replica），自动建立 Paxos 组，在分区级用多副本保证数据可靠性和服务高可用，数据管理更加灵活方便；
- 自动选举主副本：
OceanBase 自动生成多份副本，多副本自动选举主副本，主副本提供服务（如图黄色副本供应用访问，蓝色副本用于备份）;
b. 自动负载均衡与智能路由
- 自动负载均衡：
主副本均匀打散到各个服务器中，使得各个服务器都能承载业务流量。(如图应用1、2、3读请求分布路由到不同的 OB Server）;
- 每台OB Server 相互独立：
每台 OB Server 均可以独立执行 SQL，如果应用需要访问的数据在不同机器上，OB Server 自动将请求路由至数据所在的机器，对业务完全透明（如应用2->P6->P7/P8)。
c. 通过多副本同步 Redo Log 确保数据持久化
- Paxos 组成员通过 Redo-Log 的多数派强同步，确保数据的持久化；
- Leader 无需等待所有 Follower 的反馈，多数派完成同步即可向应用反馈成功；
示例：
- 应用写数据到P2分区，Zone2-OB Server1 的P2为主副本（Leader），承接业务需求；
- 将 Redo-Log 同步请求发送到 Zone1-OB Server1 和 Zone3-OB Server1 中的P2从副本（Follower）；
- 任何一个 Follower 完成 Redo-Log 落盘并将响应返回给 Leader 后，Leader 即认为 Redo-Log 完成强同步，无需再等待其它 Follower 的反馈；
- Leader反馈应用操作完成。
d. 通过设置 Primary Zone，将业务汇聚到特定 Zone
- 通过为不同的租户配置不同的 Primary Zone，可以将业务流量集中到若干 Zone 中，减少跨 Zone 及跨服务器的操作。
- Zone List，逗号两侧优先级相同，分号左侧优先级高于右侧。
示例1：
配置1：(z1,z2,z3) 意义：ZONE_1 =ZONE_2 = ZONE_3
主副本（Leader）均匀分布到各机器。
适合批处理场景，希望尽快跑完，不关注某一个 sql 的执行时间，期望让整体任务尽快完成。
示例2：
配置2：(z1;z2;z3) 意义：ZONE_1 >ZONE_2 > ZONE_3
主副本（Leader）只在 Zone1 存在，Zone 和 Zone3 均是从副本；
适合对时延敏感的在线处理业务，业务量不大，不超过一台机器的处理能力，可以尽量避免跨服务器访问，从而降低时延。
示例3：
配置3：(z1,z2;z3) 意义：（ZONE_1 = ZONE_2） > ZONE_3
主副本（Leader）均匀分布到 Zone1 和 Zone2，Zone3 均是从副本
适合三地五中心方案，将业务汇聚到距离较近的城市，距离较远的城市只承担从副本的角色；
e. Primary Zone 有租户、数据库和表不同的级别
如无特殊指定，自动继承上级对象的 primary_zone：database 继承租户的 primary_zone 设置，table 继承 database 的 primary_zone 设置。
database 和 table 可以指定各自的 primary_zone ，不必和上一级对象的设置保持一致；提供更加灵活的负载均衡策略。
- 租户(z1, z2 , z3)
主副本均匀分布到3个 Zone 中
满足大部分表的应用场景
- 数据库(z1;z2;z3)
（如没有特殊指定）该数据库下的所有表的主副本将集中到 Zone1 内机器中（可能是多台）
- 表(z1,z2;z3)
主副本将集中到 Zone1 和 Zone2 内机器中
Primary Zone 示例：
租户“tenant_name”所有表的主副本都位于Zone1
2、动态扩容和缩容
a. 动态水平扩展的场景
以上图为例，假设一个三副本的集群，每个 Zone 都有3000个分区的副本，扩容后，OceanBase 自动将1500个分区的副本（含主副本）迁移到新服务器中的资源 Unit 中；
OceanBase 可以很好的帮助业务线性的进行扩容和缩容，低成本的应对大型促销等活动；
b. 动态扩容和缩容技术实现
上图假设一个表有8个分区，扩容后，在每个 Zone 内，OceanBase 自动将4个分区的副本（含有主副本）迁移到新服务器的租户资源单元中，实现 Zone 内各个 OB Server 的负载均衡；
整个扩容过程是在线动态扩容，对业务无感知，可以降低运维难度。
Step1：购买资源
大促之前，准备扩容服务器，并安装 OceanBase 软件；
Step2：追平数据
新增服务器 OB Server2 到集群后，OB 会自动选择一些副本，动态的由 OB Server1 复制到 OB Server2 中（存量复制 +redo logo 增量复制），这个过程对业务无影响；
Step3：切换服务
数据追平后，OB Server1 中的主副本停止服务，由 OB Server2 中的新的主副本接管服务，删除 OB Server1 中的旧副本，这个过程对业务也无影响；
Step4：缩容
洪峰流量过去后，做反向动作，将 OB Server2 中的副本迁回到 OB Server1 中，业务重新访问 OB Server1 中的副本；
Step5：退回资源
释放扩容服务器的资源。
c. 租户扩容 – 通过扩大资源池规格实现纵向扩展
扩容前集群及租户资源情况：
3-3-3-3-3集群，共5个Zone
租户资源池使用 Zone1、Zone2、Zone3
规格为1C2G
资源单元数量为1（Unit Num=1）
扩容后集群及租户资源情况：
将租户资源池规格由1C2G扩容为2C8G
d. 租户扩容 – 通过增大资源池 Unit Num 实现横向扩展
扩容前集群及租户资源情况：
3-3-3-3-3集群，共5个Zone
租户资源池使用Zone1、Zone2、Zone3
规格为1C2G
资源单元数量为1
扩容后集群及租户资源情况：
将租户资源池的 Unit Num 由1扩容成3
负载均衡
基于负载均衡原则，会自动迁移部分数据到新Unit中（在Zone内迁移）
数据追平后，新Unit中将选举出主副本，从而分流业务流量
e. 租户扩容 – 增加系统可用性三副本扩容至五副本
扩容前集群及租户资源情况：
3-3-3-3-3集群，共5个Zone
租户资源池使用Zone1、Zone2、Zone3
规格为1C2G
资源单元数量为1
扩容后集群及租户资源情况：
将租户资源池的由3个Zone扩容成5个Zone
负载均衡
从原来的3个Zone内的主副本那里复制数据（Paxos组成员有3个增加到5个）
数据追平后，新Unit中将选举出主副本，从而分流业务流量（根据Praimary Zone的配置等情况）
f. 缩容基本步骤
a. 执行alter resource pool <pool name> unit_num = <smaller number>;命令，缩减资源池中的unit个数；
b. OceanBase自动启动“rebalance”过程，将一部分数据从待下线机器上的unit在线复制到同zone内其它机器的unit上；
c. 每个分区的数据复制完成后，OceanBase自动将服务切换到新的unit上，之后删除待下线机器的unit中分区上的数据；
d. 为每台要下线的机器执行alter system delete server;命令，完成机器下线的操作；
e. 手工终止已下线机器上的observer进程，并执行关机等操作；
数据复制的过程是否已经完成？查看__all_virtual_sys_task_status表，是否有comment like '%partition migration%'的任务。
3、数据可靠及高可用
a. 少数派故障时自动实现服务接管，保证服务高可用
举例：Leader副本故障
假设Zone3-OB Server2故障，P7 Leader主副本无法正常提供服务；
位于Zone1的P7 Follower从副本和Zone2的P7 Follower从副本将重新选出新的Leader，并接管业务；
整个过程无需人工干预，自动完成；
Zone3-OB Server2故障恢复后，P7副本首先追平数据，数据追平后，继续参加Paxos组，一般情况下，该P7副本还会是主副本（以实现负载均衡）；
举例：Follower从副本故障
假设Zone3-OB Server2故障，从副本（P5,P6,P8) 本来就不承接业务，剩下的2个副本依然满足多数派，依然可以正常提供业务，对业务无影响；
待从副本所在服务器故障恢复后，追平数据后继续加入Paxos组后依然是从副本；
b. OceanBase容灾：同城三机房
同城3个机房组成一个集群（每个机房是一个Zone），机房间延迟一般在0.5～2ms之间；
机房级灾难时，剩余的两份副本依然是多数派，依然可以同步Redo-Log日志，保证RPO=0；
但无法应对城市级的灾难；
c. OceanBase容灾：三地五中心五副本
三个城市，组成一个5副本的集群；
任何一个IDC或者城市的故障，依然构成多数派，可以确保RPO=0；
由于3份以上副本才能构成多数派，但每个城市最多只有2份副本，为降低时延，城市1和城市2应该离得较近，以降低同步Redo-Log的时延；
为降低成本，城市3可以只部署日志型副本（只有日志）；
d. OceanBase容灾：同城两机房“主-备”方案
同城三机房或者三地五中心的方案对基础设施要求太高。为了利旧企业现网的基础设施，OceanBase提供了同城两机房和两地三中心两种方案
每个城市都部署一个OceanBase集群，一个为主集群一个为备集群；
每个集群有自己单独的Paxos group，多副本一致性；
“集群间”通过Redo-log做数据同步，形式上类似传统数据库“主从复制”模式；
有“异步同步”和“强同步”两种数据同步模式，类似ODD中的“最大性能”和“最大保护”两种模式；
e. OceanBase容灾：两地三中心“主-备”方案
主城市与备城市组成一个5副本的集群；
任何IDC的故障，最多损失2份副本，剩余的3份副本依然满足多数派；
备用城市建设一个独立的3副本集群，做为一个备集群；
从主集群”异步同步“或者”强同步“到备集群，一旦主城市遭遇灾难，备城市可以接管业务；
4、分布式事务、MVCC、事务隔离级别
a. 分布式事务跨机执行时，OceanBase通过多种机制保证ACID
A：原子性Atomicity
原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。
依赖两阶段提交协议保证分布式事务的原子性。
C：一致性Consistency
事务前后数据的完整性必须保持一致。
保证主键唯一等一致性约束；
全局快照 - 单租户GTS服务，1秒钟内能够响应获取全局时间戳的调用次数超过200万次；
I：隔离性Isolation
多个用户并发访问数据库时，数据库为每个用户开启的事务，不能被其他事务的操作所干扰。
采用MVCC进行并发控制，实现read-committed的隔离级别；
所有修改的行加互斥锁，实现写 - 写互斥；
读操作读取特定快照版本的数据，读写互不阻塞；
D：持久性Durability
一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响。
Redo-Log使用Paxos协议做多副本同步。
b. 因服务器时钟差异，分布式数据库ACID挑战更大
和传统的数据库的单点全共享（即Shared-Everything）架构不同，OceanBase是一个原生的分布式架构，采用了多点无共享（即Shared-Nothing）的架构，在实现全局（跨机器）一致的快照隔离和多版本并发控制时，会面临分布式架构所带来的技术挑战。
示例：
事务T1修改数据为1(SCN10010)，事务T2修改数据为2(SCN10030)，因服务器B与服务器A有时钟差，事务T3查询到的数据为1，而不是2(SCN10020）。
c. OceanBase全局一致性快照技术
OceanBase数据库利用一个集中式服务来提供全局一致的版本号。事务在修改数据或者查询数据的时候，无论请求源自哪台物理机器，都会从这个集中式的服务处获取版本号，保证所有的版本号单调向前并且和真实世界的时间顺序保持一致。
d. 事务隔离级别（Isolation Level）
保证全局数据一致性的隔离级别
事务并发问题
脏读：读取了未提交的数据；
不可重复读：指的是在同一事务内，不同的时刻读到的同一批数据可能是不一样的（期间被别的事务更新数据）；
幻读：指的是在同一事务内，在操作过程中进行两次查询，第二次查询的结果包含了第一次查询中未出现的数据或者缺少了第一次查询中出现的数据（期间被别的事务插入或者删除了数据）；
OceanBase支持多种事务隔离级别
基于全局一致的数据版本号管理，以不同的版本号策略实现不同的隔离级别；
支持以下两种隔离级别，应用系统可以根据需求权衡使用任何一种隔离级别：
Read-Committed：避免脏读，存在不可重复读和幻读（默认）；
Serializable：避免脏读、不可重复读、幻读；
不支持脏读（Dirty-Read），只能获取已提交数据；
e. 多版本并发控制（MVCC），解决读写互斥问题
通过MVCC功能，T1的写事务和T2的读事务可以并行执行。
MVCC核心功能：
采用锁机制控制读写冲突时，加锁后其他事务无法进行读，导致读写竞争，影响读的并发度。MVCC可以有效解决该问题：
全局统一的数据版本号管理，取自全局唯一的时间戳服务（GTS）；
“读”、“写”操作都要从GTS获取版本号；同一个租户内只有一个GTS服务，可以保持全局（跨机）一致性；
修改数据：事务未提交前，数据的新旧版本共存，但拥有不同的版本号；
读取数据：先获取版本号，再去查找小于等于当前版本号的已提交数据；
写操作获取行锁，读操作不需要锁，有效避免读写锁竞争，提高读写并发度；
f. 小结
本章节主要介绍OceanBase集群的OB Server如何协同工作来实现负载均衡、高可用、分布式事务等特性。
每个分区的多个副本组成Paxos组，一般情况下由主副本对业务提供读写服务，主从副本之间通过同步Redo-Log日志确保数据的强一致性，主副本无需等待所有从副本的Redo-Log日志落盘,只要满足多数派落盘即可,这将提供更好的性能；
一般情况下，副本以及主副本将被均匀打散到Zone内各个服务器中（与租户资源池一致），实现自动负载均衡，避免各个服务器忙闲不均；
少数派故障,多数派将自动选出新的主副本,确保不影响业务；
OB Proxy是一个”无状态“的服务进程，不做数据持久化，对部署位置无要求；
OceanBase可以提供RPO=0，RTO<30秒的高可用，意味着当少数派故障时，OceanBase能够在30秒内恢复业务，且不会丢失任何数据；
OceanBase提供同城三机房三副本及三地五中心五副本的方案，同时为了利用企业已有基础实施，也提供传统的同城两机房主备方案及两地三中心主备方案。
试题1
在一个 3-3-3的 OB 集群上（（3 个 zone，每个 ZONE 有 3 台 observer），每个 observer 的容量都是 60C240G，管理员想要创建一个租户，这个租户一共有40C100G，可行的方案有？
a) 定义40C100G 的 Unit, 并且创建1 个 Unit 给该租户
b) 定义 20C50G 的 unit，并且创建 2个 Unit给这个租户
c) 定义 10C25G 的 unit，并且创建 4 个 Unit 给这个租户
d) 定义8C20G 的 unit，并且创建 5 个 unit 给这个租住
（答案：AB）
知识点：每个租户在一台observer 上只能有一个unit，且租户的unit是不能跨节点的，题中只有3个zone，则最多有3个unit。
试题2
假设一台服务器的规格是32c128G，在这台服务器上部署ObServer，其中配置项memory_limit = 0, memory_limit_percentage = 80, system_memory= 20, 只有一种租户Unit规格为4c16G，那么这台ObServer上最多可以部署多少个Unit？
a) 4
b) 5
c) 6
d) 8
（答案：B）
解题思路：（128*80%-20）/16=5.15
试题3
已知租户内存为50G，ob_plan_cache_percentage＝20 ob_plan_cache_evict_high_percentage＝80 ob_plan_cache_evict_low_percentage＝40，以下说法正确的是：
a) 计划缓存使用达到4G才会开始触发淘汰
b) 该租户计划缓存使用达到4G才会开始触发淘汰
c) 该租户计划缓存使用不会超过8G
d) 该租户计划缓存可使用12G内存
e) 该租户计划缓存使用超过8G时，会触发淘汰
（答案：E）
解题思路：租户cache可用内存为50*20%=10G，高水位参数是80%，低水位参数是40%，当缓存达到或超过8G则触发淘汰。
二、OceanBase SQL与存储引擎
1、SQL 引擎
a. SQL引擎支持MySQL和Oracle兼容模式
双模（MySQL + Oracle）共存：业内首创
同一个集群,同时支持mysql和oracle；
租户创建时需要配置为MySQL兼容模式或Oracle兼容模式；
DBA由原来维护“多个数据库产品”变为维护一个“统一的数据库产品”，DBA可以结合应用需求，创建不同兼容模式的租户；
MySQL兼容模式
MySQL 5.6语法全兼容
兼容MySQL通信协议，MySQL应用可直接迁移至OceanBase
Oracle兼容模式
兼容Oracle 11g语法
支持90%的Oracle数据类型和内置函数；还在持续完善中
支持分布式执行的存储过程（PL/SQL）
b. 基本操作：事务介绍
数据库事务(DatabaseTransaction)是指作为单个逻辑工作单元执行的一系列操作。事务处理可以用来维护数据库的完整性，保证成批的SQL操作全部执行或全部不执行
通过BEGIN TRANSACTION，或BEGIN和BEGIN WORK（被作为STARTTRANSACTION的别名受到支持）语句显示开始，以COMMIT（提交）或ROLLBACK（回滚）语句显示结束
事务语法如下：
START TRANSACTION | [BEGIN [WORK]]
COMMIT [WORK] ;
ROLLBACK [WORK];
c. 基本操作：提交事务
在提交事务（COMMIT）之前：
修改只对当前用户可见，对其他用户来说是不可见的
修改不是最终结果，可以通过ROLLBACK语句撤销修改
在提交事务（COMMIT）之后：
修改对其他用户都是可见的
修改是最终结果，不能通过ROLLBACK语句回滚修改
示例：
d. 基本操作：回滚事务
回滚事务：回滚（ROLLBACK）事务操作，表示事务已经结束，回滚所有事务操作，并释放事务锁。
示例：
e. 查看SQL的执行计划-EXPLAIN命令
语法：explain [extended] <sql statement> \G
使用非常方便，无需创建单独系统表，可直接获取语句的执行计划
extended选项会产生更多详细内容，排查执行计划问题时建议指定
命令的输出格式和Oracle数据库的EXPLAIN工具比较接近，可读性好
只是获取执行计划，并不真正执行
2、存储引擎
a. 传统数据库有随机写、写放大等问题
大量随机写：buffer pool和表空间页面“一一对应”，数据更新时会在磁盘上产生频繁的随机写（check point）
写放大：随机写导致SSD的写放大问题，影响性能及磁盘寿命
读数据
如果buffer Pool中有，则直接从内存读，如果没有，则从硬盘中提取到buffer pool中
可以提升热数据的读取速度，减少时延
写数据
修改数据时，先将数据写到buffer pool，再刷新到磁盘
通过check point将脏数据刷新到硬盘中，造成随机写和写放大：
数据页离散分布，造成大量随机写，延迟大，影响性能
SSD上的随机写会导致严重的写放大，不仅影响写操作性能，而且显著降低SSD的寿命
一般使用高端读写型的SSD
b. 准“内存数据库”+ LSM-Tree存储，避免随机写
增量数据直接写入内存，并将Redo-Log落盘及同步给从副本后，即可通知业务成功；
内存占用率达到阈值后冻结MemTable，并执行转储/合并等操作以释放内存空间；
内存增量数据批量合并到磁盘，以顺序写代替随机写；
读数据时，需要从热点缓存、MemTable以及转储SSTable中读取数据，保证数据一致性；
技术优势
读写分离：读内存和写内存分开；
提升写速度：准内存处理，数据修改主要是内存操作，无频繁 check point操作，提高写性能；
避免随机写：内存的脏数据批量合并之后，顺序写入SSD硬盘，避免随机写，提高写性能并延长SSD寿命；
数据持久性：为避免内存中数据丢失，redo-log以WAL机制实时落盘，保证数据持久性；
降低成本：磁盘数据按主键有序排列，磁盘碎片少，并提供快速检索能力。使用普通读密集型SSD硬盘；
底层存储会划分微块（micro block）和宏块（macro block），由数据库内部管理；
c. OceanBase转储和合并简介
磁盘数据按主键有序排列，提供快速检索能力。内存增量数据（MemTable）分多级做批量归并（Minor-Major)，最终整合到磁盘（SSTable），对整体性能影响较小。
转储操作（minor freeze）
目的是不断的把内存的 MemTable 写入磁盘以释放内存空间；
转储过程首先会冻结 MemTable（阻止当前的 MemTable 再有新的写入），并生成新的活跃 MemTable；
Partition 副本可以独立决定冻结当前 MemTable，并转储到磁盘上；
转储出的数据只与相同大版本的增量数据做数据归并，不与全局静态数据合并；
合并操作（ Major freeze ）
是将动静态数据做归并，会比较费时。当转储产生的增量数据积累到一定程度时，通过Major freeze实现大版本的合并
d. OceanBase转储和合并区别
转储和合并的最大区别在于，合并是集群上所有的Partition在一个统一的快照点和全局静态数据进行合并的行为，是一个全局的操作，最终形成一个全局快照。转储和合并的对比如下：
转储（Minor freeze）
Partition 级别，只是 MemTable 的物化；
每个 Partition 独立决定自己 MemTable 的冻结操作，主备 Partition 无需保持一致；
转储只与相同大版本的 Minor SSTable 合并，产生新的 Minor SSTable，所以只包含增量数据，最终被删除的行需要特殊标记；
合并（Major freeze）
全局级别，产生一个全局快照；
全局 Partition 一起做 MemTable 的冻结操作，要求主备 Partition 保持一致；
合并会把当前大版本的 SSTable 和 MemTable与前一个大版本的全量静态数据进行合并，产生新的全量数据；
e. 控制内存数据落盘（“转储”及“合并”）
触发memstore内存dump操作的阈值
freeze_trigger_percentage参数；默认值是70，即memstore的内存写满70%时，自动触发转储或者合并，具体行为取决于参数设置；
转储（minor freeze）的时机
内存达到阈值后自动触发；
手工触发：以root@sys用户执行alter system minor freeze;命令；
合并（major freeze）的几个时机
定时合并：由major_freeze_duty_time参数控制，默认值是"02:00"；
手工触发：以root@sys用户执行alter system major freeze;命令；
转储次数已满：当转储次数已经达到major_compact_trigger参数指定的次数时，自动触发合并；值为0时则关闭转储，直接触发合并；
支持轮转合并，多个Zone按次序合并
f. 控制内存数据落盘（“转储”及“合并”）- 其他说明
是否可以彻底关闭合并？
enable_major_freeze = False; 建议保持默认值True；
enable_manual_merge = True; 开启手工合并，需要手工触发所有的合并操作。极少数特殊运维场景会用到，不建议使用；
合并的并发线程数
merge_thread_count参数控制并发度，并发的粒度为分区；
默认值是0（系统自动判定并发度），值过大可能会影响在线业务性能；
少数快速写内存场景（如批处理）中，可以适当调大并发度，加快内存dump的速度；
g. LSMTree存储高数据压缩率，降低存储需求
通过数据编码压缩技术实现高压缩，比通用的压缩算法更懂数据，从而实现更高的压缩效率。
字典：把重复性较高的数据进行去重，把去重后的数据建立字典，而把原来存放数据的地方存成指向特定字典下标的引用。数据访问时无需解码。
第二次压缩是通用压缩，使用lz4等压缩算法对encoding之后的数据再做一次瘦身；
支持snappy、lz4、lzo、zstd等压缩算法，允许用户在压缩率和解压缩时间上做各自的权衡；
使用相同的块大小（16KB）以及相同的压缩算法（lz4），同样的数据存放在OceanBase中，要比在MySQL 5.7中平均节省一半的空间；
查询性能基本没有变化，写入（合并）性能有了较大的提升。
h. 小结
本章节主要介绍OceanBase的SQL及存储引擎原理：
SQL引擎支持MySQL和Oracle兼容模式。
数据库事务(DatabaseTransaction)是指作为单个逻辑工作单元执行的一系列操作。事务处理可以用来维护数据库的完整性，保证成批的SQL操作全部执行或全部不执行。
OceanBase是基于LSM-Tree的准内存型数据库。具备读写分离，准内存处理特性；内存的脏数据批量合并之后，顺序写入SSD硬盘，同时避免随机写，提高写性能并延长SSD寿命；同时为避免内存中数据丢失，以Redo-log以WAL机制实时落盘，保证数据持久性。
转储操作（minor freeze）：目的是不断的把内存的 MemTable 写入磁盘以释放内存空间。
合并操作（ Major freeze ）：当转储产生的增量数据积累到一定程度时，通过Major freeze实现大版本的合并。
三、OceanBase 管理工具
1、OceanBase连接方式（略）
2、OceanBase平台简介
a. OceanBase数据库产品家族
b. OCP（OceanBase Cloud Platform）是企业级数据库管理平台
OceanBase 云平台（OceanBase Cloud Platform，OCP）是以 OceanBase 为核心的企业级数据库管理平台。不仅对 OceanBase 集群和租户等组件提供全生命周期的管理服务，同时也对 OceanBase 相关的资源（主机、网络和软件包等）提供管理服务，让DBA能够更加高效地管理 OceanBase 集群，降低企业的IT运维成本。
高效的 OceanBase 集群管理
支持高可用性
响应速度可达到秒级
可视化的体验
任务详情提供流程图和自然灵活的画布交互，管理任务进度更直观、高效
新增集群和租户的拓扑图，透出分布式的业务逻辑，展示运行状态、关键数据
流畅高效的用户路径
对核心 Job 的任务进行串连设计，流程清晰、无断点
提供运维任务的快捷入口，在所有页面均可快速切换至任务
专业化的功能
提供 OceanBase 集群的全生命周期管理
针对 OceanBase 特性设计的管理功能
从集群到会话的递进式管理功能
精心设计的拓扑图功能
c. OCP产品架构和功能，一站式的管理运维工具
产品架构
被管理者安装OCP Agent，OCP通过Agent管理和监控各个被管理者；
OCP向管理员提供管理、监控、告警等功能；
每个OCP节点具有完备的完整功能，单个节点可提供全部OCP的能力，当某个OCP节点不可用时，自动调度到可用的OCP节点；
OCP Server支持多节点部署，通过DNS、HAProxy、Nginx或者F5形式实现负载均衡，确保系统高可用；
依赖的软硬件资源
OCP Server可以安装在物理机上，也可以安装运行在Docker容器中；
X86架构下OCP Server支持RHEL、CentOS、AliOS、OpenSUSE等操作系统；也支持ARM架构下的AliOS、中标麒麟、华为EulerOS等操作系统；
OCP-Agent占用资源较少，对硬件资源没有特别要求；
客户端使用Web浏览器访问OCP服务，支持Chrome、Firefox、Safari、Edge等浏览器；
d. OCP核心功能
集群管理
提供全生命周期管理，包括安装、运维、性能监控、配置、升级和删除等功能；
主机管理
提供添加主机、删除主机、主机关键信息显示等功能；
租户管理
租户的创建、租户结构拓扑图、性能监控、会话管理和参数管理等；
告警管理
支持集群、租户、主机等不同维度的告警。系统基于告警规则生成告警；
备份恢复管理
支持对OceanBase集群和租户级别进行全量备份、增量备份、Redo-Log备份、完全恢复、不完全恢复等功能；
用户及权限管理
通过对用户和角色的管理确保系统安全。
e. 集群管理-集群拓扑图
集群：展示集群的 ID、集群类型（主或备）以及集群当前的状态。备集群图标上方还会展示当前的备库延迟时间；
Zone：展示了Zone 名称、以及 Zone 当前的状态，包括 QPS、连接数和 Unit 数；
Server：展示了 Server 的 IP 地址以及 Server 当前的状态，包括 QPS、连接数和 SQL 端口；
f. 集群管理 – 租户管理
查看当前集群下工作负载最高的 5 个租户的性能信息，包含 TPS、QPS、SQL 响应时间、事务响应时间、活跃会话数、事件等待_次数、事件等待_时间、容量_表数量、容量_分区数量等性能监控指标；
根据业务需要，查看最近一小时、最近一天或最近一周的监控信息；
g. 集群管理 – 资源管理（1）
可以查看磁盘、分区副本、CPU和内存的趋势图；
可以按Zone来查看资源情况；
h. 集群管理 – 资源管理（2）
查看每个 Zone 下的 已分配内存、已分配 CPU、已使用磁盘 三个属性值，用来判断同一类型资源在 Zone 内机器上的使用率是否基本一致，如果基本一致则表明负载均衡；
根据已使用磁盘百分比来判断集群的磁盘容量是否够用，当磁盘使用到量到达磁盘容量80%时，则可以考虑增加机器进行扩容，使磁盘水位保持正常水位；
i. 租户管理 – 租户资源管理
在资源使用区域通过时间条件筛选，查看最近一周、一个月、六个月、一年或自定义时间段内的 磁盘、分区副本、CPU和内存信息。
j. 租户管理 – 租户性能管理
支持对性能与SQL、事务、存储与缓存进行统计和监控；
可以按统计周期监控，也可以查看实时数据；
可以按Zone及OBServer查看数据；
k. 租户管理 – SLQ诊断
可以对可疑SQL、TopSQL和SlowSQL进行诊断，诊断识别风险语句，规避风险。
l. 告警管理-告警项
配置告警的范围、触发条件、检测周期、告警等级等信息。
m. 告警管理-查看告警事件
控制台的告警事件列表用于查看和检索全部告警。告警事件列表支持丰富的搜索条件，其中关键字搜索会匹配告警概述、告警详情和所有标签的值。
n. 告警管理-告警通道
告警本身是独立的功能，未配置通道和订阅时，只能通过控制台的告警事件页面查看告警。通过配置告警通道和告警订阅，用户可以接收告警通知消息。
o. OMS核心功能简介
支持多种类型数据源：
支持包括 Oracle、MySQL、DB2、OceanBase 等数据库到 OceanBase 的全量迁移和增量实时数据同步；
兼容性评估和改造：
异构数据迁移 OceanBase 的对象兼容性评估和改写建议，极大降低业务迁移的门槛和业务改造的难度；
一站式交互：
数据迁移全生命周期管理，数据迁移的创建、配置和监控都在管控界面上连贯操作完成，交互简便；
多重数据校验：
提供多种方式校验的保护，更加全面、省时、高效地保证数据质量；同时展示差异数据，提供快速订正途径；
p. OceanBase开发者中心（ODC）产品架构
OceanBase 开发者中心（Oceanbase Developer Center，ODC）是为 OceanBase 数据库量身打造的企业级数据库开发平台；
ODC 支持连接 OceanBase 中 MySQL 和 Oracle 模式下的数据库，同时为数据库开发者提供了数据库日常开发操作、WebSQL、SQL 诊断、会话管理和数据导入导出等功能；
可以下载专门的客户端，也可以使用浏览器直接登录；
q. ODC六大核心功能，帮助开发者迅速上手OceanBase
企业级特性分区支持：
支持OceanBase MySQL和 Oracle模式下完整的分区类型；
数据库对象可视化管理：
提供引导式创建和可视化修改各类数据库对象的服务；
资源性能查看：
实时管控数据库会话访问，支持查看和终止会话，且提供SQL执行计划分析和SQL调优指导服务；
数据库变量编辑支持：
支持会话变量和系统全局变量的可视化修改，降低用户记忆变量的难度；
健全的控制台服务：
通过WebSQL技术为开发人员提供SQL语法高亮、格式化、智能提示等贴心特性，支持PL对象及匿名块的编译、运行、调试；
数据导入导出支持：
支持多种文件格式的导入和导出；
r. 利用OMS实现数据库平滑迁移方案：数据实时同步 + 快速切换 + 回滚预案
应用读写ORACLE/MySQL
OMS实时同步：ORACLE/MySQL -> OB
应用停写ORACLE/MySQL
OMS全量校验：OB vs ORACLE/MySQL
OMS实时同步：OB -> ORACLE/MySQL
应用切换读写OB
<回滚预案>
应用停写OB
OMS全量校验：ORACLE/MySQL vs OB
OMS实时同步：ORACLE/MySQL -> OB
应用切换读写ORACLE/MySQL
s. 小结
本章节主要介绍OceanBase的管理工具及相应特性：
OceanBase支持多种客户端工具 ：OceanBase客户端、MySQL客户端、OceanBase云平台、OceanBase开发者中心。
OceanBase 云平台（OceanBase Cloud Platform，OCP）是以 OceanBase 为核心的企业级数据库管理平台。主要功能：集群管理、主机管理、租户管理、告警管理、备份恢复管理、用户及权限管理。
OceanBase 迁移服务（OceanBase Migration Service，OMS）是 OceanBase 提供的一种支持同构或异构 RDBMS 与 OceanBase 之间进行数据交互的服务，它提供了数据的在线迁移和实时增量同步的数据复制能力。支持包括 Oracle、MySQL、DB2、OceanBase 等数据库到 OceanBase 的全量迁移和增量实时数据同步。
OceanBase 开发者中心（OceanBase Developer Center，ODC）是为 OceanBase 数据库量身打造的企业级数据库开发平台。支持连接 OceanBase 中 MySQL 和 Oracle 模式下的数据库，同时为数据库开发者提供了数据库日常开发操作、WebSQL、SQL 诊断、会话管理和数据导入导出等功能。
四、试题解析
试题4
对于如下的schema: create table t1(a int, b int, c int, d int, e int, primary key(a,b), index i1(c,b), index i2(d,a), index i3(d,e)), 对于查询select * from t1 where a = 1 order by c limit 1; 经过skyline pruning之后，还剩哪些？
a) 主键
b) 索引i1
c) 索引i2
d) 索引i3
（答案：AB）
试题5
假设分布式事务T1，更新了两个分区，分区leader分别分布在两个机器上，T1 commit成功之前。假设P1、P2上没有其他事务，后续先后开启事务T2、T3分别查询P1、P2刚刚修改的数据，如果T2能够读到T1关于P1修改的数据，那么T3能够读到 T1关于P2修改的数据吗？
a) 可以
b) 不可以
（答案：A）
试题6
OBProxy 有哪些 location cache ？
a) sys 租户数据的location cache
b) 普通租户数据的location cache
c) database location cache
d) 表/分区表的locatition cache
（答案：ABD）
试题7
以下哪些结构会被备份出去？
a) SSTable
b) Clog
c) SLog
（答案：AB）
试题8
通过系统参数syslog_level来调整打印应用日志的级别，下列日志级别的排序，由高到低，正确的是________？
a) ERROR > INFO > WARN > TRACE > DEBUG
b) ERROR > WARN > INFO > TRACE > DEBUG
c) ERROR > WARN > INFO > DEBUG > TRACE
d) ERROR > WARN > TRACE > INFO > DEBUG
（答案：B）
五、Q&A
Q：副本的扩容有规则吗？副本是不是一个zone？
A：副本不是一个zone。扩容是指比如扩大资源，原来是2个G变成4个G，也可以是横向放大，而zone是OB里买的一个逻辑结构，你可以定义一个机房为一个zone，也可以定义整个城市的所有服务器是一个zone。
Q：当集群资源不足横向扩容时，在补充副本期间是否影响性能？补充副本占用资源和带宽吗？
A：会有一些资源消耗，但会比较少，通常进行扩容时要避免业务高峰期。
Q：3个zone的OB Server1-1-1，必须2-2-2还是12345随便加？有规则吗？
A：理论上来说是没有规则的。比如1-1-1集群，有1台服务器要加到1个zone里面，也可以实现2-1-1。
————————————————
附录：
练习题：
实践练习一（必选）：OceanBase Docker 体验
实践练习二（必选）：手动部署 OceanBase 集群
实践练习三（可选）：使用OBD 部署一个 三副本OceanBase 集群
实践练习四（必选）：迁移 MySQL 数据到 OceanBase 集群
实践练习五（可选）：对 OceanBase 做性能测试
实践练习六（必选）：查看 OceanBase 执行计划
还没交作业的小伙伴要抓紧啦！
可以免费带走 OBCP 考试券喔~~
方法一：完成四道必选练习
方法二：任意一道练习题 ➕ 结业考试超过80分
已经有很多同学抢先答题了，
加入钉钉群（群号3582 5151），和大家一起学习、交流～～
进群二维码：
