本文详述了OceanBase数据库的使用、运维及优化，涵盖了OB业务场景、集群搭建与故障排查、数据同步与迁移、性能监控、内存管理、备份恢复、SQL执行流程等内容，旨在提供全面的OceanBase数据库操作指南。
目录
mysqldump到处数据库schema，数据库数据，表数据
Sysbench 测试步骤创建测试租户obd cluster tenant create 3-proxy
OB业务场景
公司使用理由：
1.新创改造，国家支持，全国产
2.成本低，负载均衡，
3.数据可靠性和服务可用性高，PAXOS分布式一致性协议（分布式数据库基本上都这协议）服务恢复时间（RTO）30秒内
4.数据节点和计算节点均可以在MPP架构下实现水平扩展没有数量限制（传统数据到一定量时插入数据变慢：1000万条数据 小于1小时，3000万条数据大于3小时）
加入OB：2020年
常见 bootstrap 失败原因
1.集群里observer节点之间网络延时超过200ms (建议在30ms以内)。
2.集群里observer 节点之间时间同步误差超过100ms (建议在5ms以内)。
3.主机ulimit 会话限制没有修改或生效
4.主机内核参数sysctlconf没有修改或生效
5.observer 启动用户不对，建议 admin 用户
6.observer启动目录不对，必须是~/oceanbase 。具体版本号会有变化
7.observer的可用内存低于8G。
8.observer的事务日志目录可用空间低于5%
9.observer 启动参数不对 (zone名称对不上，rootservice list 地址或格式不对，集群名不统一等)。
常见OBD 部署 失败原因
集群里observer 节点之间网络延时超过 200ms (建议在30ms以内)。
集群里 observer 节点之间时间同步误差超过 100ms (建议在5ms以内)。
主机ulimit会话限制没有修改或生效
主机内核参数 sysctl.conf 没有修改或生效
observer 启动用户不对，建议 admin 用户
·observer 启动目录不对，必须是~/eboroxy-3.2.0。具体版本号会有变化。
observer 的可用内存低于 8G。
observer 的事务日志目录可用空间不足 5%
observer 启动参数不对(zone名称对不上，rotservice list 地址格式不对，集群名不统一等)目录不为空 通常是第一次运行失败导致，此时清空所有相关目录(软件工作目录、数据文件目录、事务日志目录)即可
Grafana
nohup bin/grafana-server &
https://grafana.com/grafana/dashboards/15215
https://grafana.com/grafana/dashboards/15216
查看集群资源由各个节点的聚合情况
OB创建租户
查看集群资源由各个节点的聚合情况
表分组的场景
业务表能按同一个业务属性做水平拆分能规避分布式事务。
mysqldump到处数据库schema，数据库数据，表数据
导出整个数据库Schema，不包括数据
导出整个数据库数据，不包括表结构
mysqldump -u admin -p -t migration > migrate_full_data.sql
导出一个表Schema，不包括数据
mysqldump -u admin -p -d migration migrate_table --compact > migrate_table_ddl.sql
导出一个表数据，不包括表Schema
mysqldump -u admin -p -t migration migrate_table > migrate_table_data.sql数据同步框架 DATAX
优势
可靠的数据质量监控:支持强数据类型转换、作业全链路流量和数据量实时监控、脏数据探测。
丰富的数据转换:支持数据脱敏、补全、过滤等转换功能。
精准的速度控制:支持通道(并发)记录流和字节流三种流控模式。
强劲的同步性能:支持多种切分策略，任务切分为多个task，单机多线程执行模型
健壮的容错机制:支持线程级别、作业级别多层次局部/全部重试。
极简的使用体验:易用(解压缩即可用)、详细(日志打印传输速度、性能、CPU、JVM、GC等信息)
Canal同步注意事项
同步的表必须有主键
无主键表 delete 和update 同步会有问题
支持 ddl同步
支持新建表、新增列、删除表等，
不支持后期新增主键、修改主键、修改列的类型
待反馈补充。
obdumper使用注意事项
执行obdumper的机器上需要安装idk1.8且设置JAVA HOME环境变量。
导出时候-f指定的目录必须先提前创建，并授权可以读写。
导出的时候-f指定的目录不能是非空的。
导出的时候-u指定的用户须有导出对象的select权限。
--sys-user和--sys-password指定的是sys租户下的用户，可以使用root用户或者proxyro帐密
--file-name须与--table 参数搭配使用，指定多个表的时候这里的--file-name无效。
数据量大，导出时间长，执行期间发生了转储，中途会报错如”error: Request to read too oldversioned data”需要将undo retention变量调大一些
obdumper调优
1、命令行配置项调优
--thread
--page-size
2、iava内存调优
50 JAVA OPTS="$JAVA OPTS -server -Xms4G -Xmx4GXX:MetaspaceSize=512M -XX:MaxMetaspaceSize=512M-Xss352K”
3、OB转储
在导出数据的时候，可以先手动执行一下转储的操作。
obloader使用注意事项
执行obloader的机器上需要安装idk1.8且设置JAVA HOME环境变量
导入数据前，库需要提前创建，不会在导入期间自动创建库。
导入使用的用户需要有对应读写的权限。
导入的时候目录需要选择正确。
数据库中存在有外键的表时，无法保证结构和数据按照依赖顺序导入，可能会导入失败
什么是CDC
CDC: change data capture,数据变更捕获，核心思想就是监测并捕获数据库的变动(包括数据表的插入更新，删除，修改等)，将这些变更按发生的顺序完整记录下来，写入到目标数据库或消息中间件中来供其他服务进行订阅及消费。
https://en.wikipedia.org/wiki/Change data capture
OMS 是什么
OceanBase数据迁移服务(OceanBase Migration Service,简称0MS)是OceanBase提供的一站式数据传输产品。它支持多种关系型数据库、大数据(OLAP)及消息队列等数据终端与0ceanBase之间的数据复制，是一种集数据迁移、实时数据同步和增量数据订阅于一体的数据传输服务。
OMS产品架构
数据库架构演进
OceanBase 租户隔离原理
Docker 或虚拟机隔离主要有以下几个问题
虚拟机运行环境的开销太重，OceanBase数据库需要支持轻量级租户
虚拟机迁移开销比较大，OceanBase 数据库希望租户的规格变化和迁移尽量快
虚拟机不便于租户间的资源共享,例如，对象池的共享
虚拟机资源隔离很难定制，例如，租户内的优先级支持
虚拟机的实现不便于暴露统一视图
为了确保租户间不出现资源争抢保障业务稳定运行，OceanBase设计了更加轻量的租户隔离
OceanBase 把Unit 当作给租户分配资源的基本单位，一个Unit 可以类比于一个 Docker容器。个0BServer 上可以创建多个Unit,在0BServer上每创建一个Unit都会占用一部分该0BServer的CPU、内存等物理资源
OBServer 的资源分配情况会记录在内部表中以便 DBA:
SELECT*FROM all virtual server stat
一个租户可以在多个0BServer上放置多个Unit，但一个特定的租户在某个0BServer 上只能有一个Unit资源隔离，就是0BServer 控制本地多个Unit 间的资源分配的行为,它是0BServer 本地的行为OceanBase 数据库并没有依赖 Docker 或虚拟机技术，而是在数据库内部实现资源
最低0.47元/天 解锁文章
577
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
