关于OceanBase的《一个伪DBA的信创修养》系列终于要告一段落了。
写完这篇，潭主的OBCP笔试复盘也该结束了，要去准备实验考了。
本期，说说OceanBase运维相关的Paper经验。
OceanBase用户管理
最初学OB有两个感觉，一个是v$视图太多太难记，另一个就是黑屏输出信息太多。
好在白屏简单很多，OB日常运维监控基本可以通过OCP解决。
回想起当年搞DB2 DPF，同样是分布式，一个db2_all就搞定了，倒也没觉得有什么。
关于OB的用户和角色管理，跟大多数IT产品实现机制一样。
OB用户分为：
系统租户下的用户
一般业务租户下用户
考点：权限管理的等级与分类。
MySQL模式分3个级别：
管理权限（租户级别）
数据库权限
对象权限
Oracle模式分两类：对象权限和系统权限
潭主笔试遇到了，考的是每类权限的Grant语法结构，对有DBA基础的属于送分题。
OceanBase日志管理
OB系统日志文件主要分三类，默认打印INFO级别以上的日志。
observer.log
election.log
rootservice.log
每类日志文件都有一个带有.wf后缀的日志文件，如observer.log.wf，用于记录WARING级别以上的日志。
通过集群配置项enable_syslog_wf控制是否生成WARNING日志文件，默认Ture。
OB单个日志文件大小不超过256MB，当大小达到256MB时会做日志轮转，并添加时间后缀。
考点：OB日志的回收控制参数，多选题
enable_syslog_recycle：仅当max_syslog_file_count配置项的值设置为非0正数时，该功能才会生效。
max_syslog_file_count：在回收日志文件之前可以容纳的日志文件数量。当该配置项的值为0时，无限制，OB默认不清理日志。
考点：OB的日志优先级别，单选真题
ERROR > WARN > INFO > TRACE > DEBUG
最新V4版本对日志级别又做了调整。
OceanBase日志的其他考点
OB在后台目录中还有三种日志：
Clog：事务日志，也叫Commit日志，所有分区共用，记录事务（可能乱序），基于Paxos协议实现
Ilog: Index日志，分区共用，单分区内日志有序，每个副本自行记录
Slog: Storage日志
事务日志包括Redo，Prepare、Commit、Abort和Clear，但不包括Undo。
关于日志格式，潭主考试没遇到。
| module_name | 打印该条日志的语句所在模块。 |
| function_name | 该条日志的语句所在的函数。 |
| file_name | 该条日志的语句所在的文件。 |
| file_no | 该条日志的语句所在文件的具体行数。 |
| thread_id | 该条日志的线程的线程号。 |
集群配置项：syslog_io_bandwidth_limit，设置系统日志所能占用的磁盘IO带宽上限，超过带宽上限容量的系统日志将被丢弃。
关于OBServer的错误码
一个错误通常包含以下三个信息：
一个32位整数表示的错误码
一个5位字符组成的串，即SQLSTATE
一个字符串，包含可读的错误消息
ob_error是OB的错误码解析工具，类似O记的oerr，根据输入的错误码返回相对应的原因和解决方案。
SQLSTATE由5个数字或大写拉丁字母组成的字符串值，前两位表示大的错误类别，后面三位表示更具体的错误原因。
例如，00表示成功，01表示告警，02表示未找到，22表示数据类错误，42表示语法错误等。
学Oracle都没看这么细。
对于OB，同一个错误在MySQL和Oracle模式下会返回相同的SQLSTATE。
通常，非兼容的自定义错误码对应的SQLSTATE一般都是HY000。
考点：好像有个题是关于MySQL的错误信息范围的，4000以上跟OB相关。
OceanBase的日常运维
对于OCP，了解了OB的架构和概念后很容易上手。
但白屏运维屏蔽了命令行，建议初期尽量通过黑屏积累些经验。
机器重启是常见运维动作之一，适用于对机器进行短暂维护，以及修改系统配置项后需要重启生效的场景。
重启节点的主要流程为：停止服务->转储->关闭进程->启动进程->启动服务。
考点：在停止OBServer前执行转储，加快OBServer服务恢复过程，缩短恢复时间。
由于数据修改都在内存中进行，OBServer启动后要执行一些动作：
与其他副本同步，将Clog（停机时间短）或者基线数据进行同步（停机时间长）
将上一次合并之后的内存数据恢复出来（Clog回放），才能提供服务
潭主不由想起了传统数据库的Crash Recovery里的Rollforward和Rollback。
OB的Stop Server可以在多副本架构上实现业务无损的重启效果。
OBServer的Stop执行逻辑：
将待重启节点上的Leader全部切走，并保证除了重启节点以外的其他节点上的副本满足多数派，同时停止该节点对外服务（在执行Stop Server前需要确认enable_auto_leader_switch功能开启）
在Root Service上将待重启节点标记为stopped（节点状态为ACTIVE且stop_time字段大于0），客户端识别后，不会将业务请求路由到该节点。
如果Stop Server执行失败，需要停止重启并检查原因，例如，可能出现的原因有缺少副本、RedoLog延迟、总投票成员数小于3等。
考点：如何判断OBServer启动成功
检查__all_server，查看status为active，且start_service_time值>0，表示OBServer正常启动并开始提供服务。
再补充一个知识点：
server_permanent_offline_time：集群配置项，设置节点心跳中断的时间阈值，即节点心跳中断多久后认为其被永久下线，永久下线的节点上的数据副本需要被自动补足，默认为 3600s。
节点服务停止与OBServer宕机性质不同，节点停止服务的时间可以超出server_permanent_offline_time配置项指定的永久下线时间且不会导致节点真的下线。
如果机器长时间维修，需要走机器替换流程。
考点：常见的运维操作
NTP时钟同步：offset的偏移值小于50ms为时钟同步正常
OB内存不足：调大租户内存；转储或合并释放内存
磁盘空间不足：运行日志盘满：清除old日志；Clog盘满：查询__all_virtual_server_clog_stat，清除old日志，再合并；数据文件满：扩容，或将较老的数据迁移到历史库，再合并
OceanBase的监控考点
考点：事件查询（参照官网PPT）
__all_rootservice_event_history ：记录集群级事件，如Major Freeze、合并、Server上下线、修改Primary_zone引发的切主操作、负载均衡任务执行等。
__all_server_event_history： 记录Server事件，如转储、用户发起的系统命令。
注意，两张内部表保留的都是7天内的数据。
笔试考的就是转储的例子，需要掌握不同信息记录的位置。
考点：和内存有关的两个性能视图
gv$memory：所有OBServer上每个租户的内存使用状况，提供CONTEXT（Mod名称）名称等。
gv$memstore：展示所有OBServer上的所有租户的MemTable内存使用状况，包括FREEZE_TRIGGER，FREEZE_CNT等。
最后，关于OB的Troubleshooting，潭主回顾了一下，笔试没遇到。
最好的经验都是在运维过程中实战积累的，关于问题处理，在实战中需要结合所学的架构和各个模块的知识辅助进行问题定位。
师傅领进门，修行在个人
去年参加完OceanBase老友会，潭主就想着深造一下OBCP。
花了一个多月的时间准备，运气不错，顺利过了笔试。
不过考试不是目的，信创修养才是。
在OBCP笔试复盘过程中，潭主对比了V3和V4，有些新收获，期间也结识了一些新朋友。
希望《一个伪DBA的信创修养》能帮到更多对OceanBase感兴趣的人。
- END -
感谢阅读。如果觉得写得还不错，就请点个赞或“在看”吧。
公众号所有文章仅代表个人观点，与供职单位无关。
推荐阅读：
