mq4096_个人页

OBserver启动报错:init io benchmark fail 现象：     日志 /home/admin/oceanbase/log/observer.log 里报ERROR: [2019-03-15 10:40:35.047132] WARN  [COMMON] load_from_file (ob_io_benchmark.cpp:200) [22415][Y0-0000000000000000] [lt=13] the io bench result file not exist! [2019-03-15 10:40:35.047181] ERROR [COMMON] init (ob_io_benchmark.cpp:528) [22415][Y0-0000000000000000] [lt=45] Fail to load io benchmark result, (ret=-4027) BACKTRACE:0x2de73a9 0x2d7f9f7 0x53ebf9 0x2e08e71 0x12a7f63 0x12b08f0 0x51c31c 0x7f1bea53b445 0x53abc5 [2019-03-15 10:40:35.047322] ERROR [SERVER] init_io (ob_server.cpp:711) [22415][Y0-0000000000000000] [lt=134] init io benchmark fail, (ret=-4027) BACKTRACE:0x2de73a9 0x2d7f9f7 0x53ebf9 0x12a80d0 0x12b08f0 0x51c31c 0x7f1bea53b445 0x53abc5 原因：     在OCP的安装步骤里，会先用fio测试一下磁盘性能。测试结果会生成一个文件。OBServer启动时会检查这个文件。文件不存在的时候就报错。但是OBServer的启动逻辑会继续走下去。     所以这个报错可以忽略。代码里不应该报ERROR给客户造成困扰。这个问题会在未来修复掉。 ------------------------- [font=-apple-system, system-ui, '][2019-03-18 16:15:33.921698] ERROR [LIB] start_daemon (utility.cpp:1316) [9635][Y0-0000000000000000] [lt=0] [font=-apple-system, system-ui, ']pid already exists [font=-apple-system, system-ui, ']BACKTRACE:0x2de73a9 0x2d7f9f7 0x53d7d9 0x2debaee 0x51c424 0x7f3080ed8445 0x53abc5[font=-apple-system, system-ui, '][font=-apple-system, system-ui, ']这个错误也可以忽略。

OceanBase 1.4分区表用法 业务数据做水平拆分，有如下几种方案 分库分表：通过分布式数据库中间件做分库分表拆分和路由等。如DRDS，MyCat，TDSQL等。分区：Oracle 12c的sharding, OceanBase 1.0及以后的版本存储级别切片，对应用透明。如Google的Spanner，PingCap的TiDB 这里只演示OceanBase的分区用法。 OceanBase的分区策略支持hash/list/range，以及支持二级分区（hash+hash,hash+range,key+key,range+range等）。详细用法请参见 OceanBase官网 文档里 的 OB分区表用法 。 无论是分库分表，还是分区的方案，都会面临一个问题，就是当一个Query 要取不同机器（节点）上的数据的时候，如果保证取出来的数据是一致的（指来自于同一个时间点或版本）。 分库分表方案解决不了这个问题， OB1.4也不能解决这个问题。OB2.0 新增全局时间服务，能提供全局一致性快照读功能，所以解决了这个问题。 这里演示一下 OB1.4 里规避这个跨节点读的方案（弱一致读） SQL: SELECT @@version;drop table if exists t_parttable;create table t_parttable(    id bigint not null primary key,     name varchar(50) not NULL,      KEY name_ind(NAME) LOCAL ) DEFAULT CHARSET=utf8mb4 partition by hash(mod(id,1000)) partitions 8;insert into t_parttable(id, name) values(1,'a'),(2,'A'),(3,'b'),(4,'B'),(5,'c'),(6,'C'),(7,'d'),(8,'D');set session ob_query_timeout=1000000; select * from t_parttable where name='a';explain select * from t_parttable where name='a';select /*+read_consistency(weak)*/ * from t_parttable where name='a';select * from t_parttable partition(p1);select * from t_parttable partition(p2); 该问题，在OceanBase 2.0后版本已经解了 ------------------------- OB租户负载均衡历史查看 接楼上建的表，这里演示一下如何在租户里查看负载均衡的历史。 OB作为一个分布式数据库，至少包含3个节点。其负载均衡的原理跟传统负载均衡的原理大不一样。 传统负载均衡设备（F5）或软件（LVS,SLB等）都是通过在某一协议层作为流量入口然后分配流量给后端不同的节点，从而去改变后端节点的压力。 OceanBase的负载均衡是自己通过调整每个节点（ObServer）里的数据（Partition）分布，从而间接改变打到各个节点（ObServer)上的流量，从而改变各个节点的压力。 有关OceanBase负载均衡的原理详细，请查看 《 OceanBase负载均衡的魅力 》 示例演示：租户视角查看负载均衡历史。 这里是新建了一个分区表（8个分区），在插入数据后，触发了负载均衡机制，把8个分区分散到多个节点上。 SQL: # 查看分区表的数据SHOW CREATE TABLE db_bin.t_parttable;SELECT /*+read_consistency(weak)*/ * FROM db_bin.t_parttable ORDER BY id ;# 查看租户的资源单元(Unit)分布SELECT tenant_name, unit_id,zone,svr_ip,max_cpu,round(max_memory/1024/1024/1024) max_mem_gb FROM gv$unit;# 查看租户的负载均衡历史SELECT str_to_date(h.gmt_create,'%Y-%m-%d %h:%i:%s') gmt_create, h.zone, t.database_name, t.tablegroup_name, t.table_name, t.part_num,h.partition_id,h.data_size, h.data_src_ip,  h.dest_unit_id, h.dest_ip, h.result_code, h.COMMENT , h.rs_svr_ip FROM gv$unit_load_balance_event_history h JOIN gv$TABLE t ON (h.table_id=t.table_id)WHERE t.table_name NOT LIKE '%recycle%' AND t.database_name='db_bin'ORDER BY gmt_create DESC LIMIT 100; ------------------------- OB sys租户查看集群使用信息     OceanBase作为一款通用的分布式关系型数据库，跟其他同行产品相比，有一个独特的地方，就是支持多租户，即支持集群资源（CPU/MEM/DISK等）的做租户管理。 OceanBase集群，至少是三节点。OceanBase把三个节点的机器资源能力聚合成一个大的资源池，然后做二次资源管理和分配。为每个租户分配一个特定规格的小的资源池，并且随时可以动态调整。 租户对于业务开发来说就是一个体的实例，只是开发不需要关注这个实例在哪个节点上。租户的使用体验类似于 MySQL (默认，以后还支持Oracle兼容模式的租户）。     假设OceanBase集群已经搭建好了，在创建租户之前，先清点一下现有集群的资源使用状况。下面是示例     SQL: # 查看集群节点资源使用情况SELECT svr_ip, s.zone, s.cpu_total, s.cpu_assigned, s.cpu_assigned_percent, round(s.mem_total/1024/1024/1024) mem_total_gb, round(s.mem_assigned/1024/1024/1024) mem_ass_gb, s.mem_assigned_percentFROM __all_virtual_server_stat sORDER BY zone,svr_ip;# 查看资源单元规格定义SELECT NAME, max_cpu, min_cpu, round(max_memory/1024/1024/1024) max_mem_gb , round(min_memory/1024/1024/1024) min_mem_gb FROM __all_unit_config ORDER BY unit_config_id LIMIT 10;# 查看已有租户及其资源池信息SELECT t.tenant_name, p.name pool_name, c.name config_name, p.unit_count, p.zone_list, t.`locality`FROM __all_resource_pool p JOIN __all_unit_config c ON (p.unit_config_id=c.unit_config_Id)  LEFT JOIN __all_tenant t ON (p.tenant_id=t.tenant_id)WHERE p.NAME IN ('yq_Pool','app_pool')  ORDER BY p.resource_pool_id; ------------------------- OceanBase租户创建（很简单）     接楼上。     清点了OceanBase集群资源使用情况后，选定一个规格，就可以快速创建出一个租户(demo_t) 示例：OB1.4下创建租户（2步） SQL： # 清理已经创建的同名租户DROP tenant IF EXISTS demo_t;DROP resource pool demo_pool;# 创建新的资源池(Resource Pool)CREATE resource pool demo_pool unit='S0_unit_config', unit_num=2;# 创建租户 CREATE tenant IF NOT EXISTS demo_t resource_pool_list=('demo_pool') SET VARIABLES ob_tcp_invited_nodes='%';# 查看已有租户及其资源池信息SELECT now() cur_time, str_to_date(t.gmt_create,'%Y-%m-%d %h:%i:%s') gmt_create,  t.tenant_name, p.name pool_name, c.name config_name, p.unit_count, p.zone_list, t.`locality`FROM __all_resource_pool p JOIN __all_unit_config c ON (p.unit_config_id=c.unit_config_Id)  LEFT JOIN __all_tenant t ON (p.tenant_id=t.tenant_id)WHERE p.NAME IN ('demo_pool')  ORDER BY p.resource_pool_id;     退出当前sys租户，重新登录新建租户 ，用户名是：root@demo_t#集群名，密码默认是空。 登录后新建Database，并创建账户访问DB。 ------------------------- OceanBase里索引创建特征 OceanBase里创建索引稍微有点特殊，开发和运维需要留意一下。 如果是在create table里带上了索引（包括唯一索引，也就是唯一性约束），是立即生效的。OB 1.x 版本里在表存在的情况下新建的索引（包括唯一索引），命令立即返回，但是索引不是立即生效。需要等到OB集群发起大合并之后才会生效。其中唯一索引需要等待两次大合并。所以运维建索引后需要安排1-2次大合并操作。OB 2.x 版本里在表存在的情况下新建的索引（包括唯一索引），命令立即返回，索引也不是立即生效，但是索引开始后台异步创建，创建时间取决于数据量。 示例如下： 1. OB 1.x 版本的索引 2. OB 2.x版本的索引 ------------------------- 回 9楼(xcb296) 的帖子 有什么想了解的 可以先说一下。 这个主要是根据用户问题来做的。

回 1楼(苍穹之巅007) 的帖子 恩。TPCC将会在 OB 2.1版本后开始测试。 预计11月底可以。 ------------------------- 上面OB使用了6台机器。考虑到TiDB是用三台存储节点提供服务。于是我把OB租户缩容到三台机器再重新测试一下。 测试脚本不变。测试结论也不变。SATA盘性能确实不怎么好。当数据量非常大的时候，TiKV的主机Pagecache命中率和OBServer的Block cache命中率都不高的时候，都会有很多随机磁盘IO，磁盘的性能间接都会影响二者的RT和吞吐。 纯读场景 读写混合 纯写场景 ------------------------- 回 7楼(klkyy2018) 的帖子 机器就是 https://bbs.aliyun.com/read/589394.html 这个里面提到的。 资源池规格最大不超过单机的资源大小。 ------------------------- 回 10楼(EricSyh) 的帖子 恩，好。  记着了。 ------------------------- Re:回 12楼(zhm) 的帖子 请带上下面参数 试试 --db-ps-mode=disable  --mysql-ignore-errors=6002,6004,4012,2013,4016 1. OB 1.4还不支持prepare 接口，所以需要禁用。 2. 在导入数据过程中，OB有可能因为冻结合并发生内部切主或者kill事务（1.x版本问题，2.x没有），需要客户端自动重连。所以要加上 一些error的忽略。否则sysbench客户端会话直接中断退出了。

strong consistency across distributed node not supported 不支持全局强一致 报错信息：strong consistency across distributed node not supported OB版本：  1.x 报错原因： OceanBase 1.x 版本不支全局一致性查询。在1.x版本里，当SQL要查询的数据分布在不同OBServer节点上时，由于没有内置全局时钟，所以无法获取不同OBServer节点上同一个时刻的数据。 解决办法： 1. 在1.x版本里。如果SQL访问的是多个表，且表之间有业务联系，则将多个表设置为相同的表分组（tablegroup）可以规避这个问题；如果SQL访问的是单个分区表，且能接受延时，可以使用弱一致读hint来规避报错；否则，暂时无解。  弱一致读hint详情请参考官方文档 弱一致读(ob_read_consistency) 2. 计划在2.1版本里，支持全局一致性查询，就没有这个问题。 ------------------------- ERROR 4624 (HY000): machine resource is not enough to hold a new unit 报错信息：ERROR 4624 (HY000): machine resource is not enough to hold a new unit OB版本：所有版本 报错原因：     OceanBase从某个角度来说就是将一批机器的资源（CPU/Memory/Disk）聚合在一起形成一个大的“资源池”，然后再从里面分配资源。每个租户都得绑定至少一个Resource Pool。Resource Pool就是从原始的“资源池”里创建出来的。每个Resource Pool由N个相同的Unit组成。每个Unit在某个具体的OBServer内部分配。当创建新的Resource Pool或者调大老的Resource Pool规格时，可能会因为没有OBServer可以分配出对应规格的Unit而报错。 解决办法：     重新计算可用资源，调制分配资源的SQL里的规格。如果可用资源确实不够用，那就先补充机器资源或者释放不用的租户资源，然后再重试。 ------------------------- OceanBase是否开源？ 汇总一下有关OceanBase和开源相关的问题的答案。 1. OceanBase 0.4曾经开源，地址为 alibaba/oceanbase 。 喜欢看代码的从中可以学习到一些分布式数据库开发经验。 2. OceanBase从1.0版本不再开源，架构上做了很大的重构，对SQL和存储功能都有加强。不过关于LSM结构、冻结合并的原理没有大变。当前版本进入2.0。将来是否开源目前并无信息。 3. OceanBase 在用户体验上像MySQL，但是绝不是MySQL，也不是基于MySQL版本修改的，不是基于Postgre修改的，不是基于其他任何开源的产品修改的。OceanBase是蚂蚁自主研发的纯粹的分布式数据库，产品开发过程中，特别注意避免侵犯其他公司专利。所以OceanBase是按照一个商业通用数据库去规划设计的。 4. 随时欢迎开发能力很强的同学加入OceanBase内核开发团队。 ------------------------- OceanBase支持分布式事务吗？ OceanBase提供多租户能力（租户就是实例）。租户内的分布式事务需求，OceanBase是满足的。原理是两阶段提交协议，强一致。OceanBase对分布式事务两阶段提交过程做了一些优化，性能有提升。如果业务的事务范围超出了租户（实例）的边界，则必须借助第三方分布式事务中间件框架或者应用自己实现分布式事务。蚂蚁SOFA的分布式事务框架DTX支持三种分布式事务方法，即XA、TCC和FMT.其中TCC和FMT都是最终一致。 ------------------------- Q: OceanBase里创建索引是立即生效吗？唯一索引呢？A： 分场景。 如果是在create table里带上了索引（包括唯一索引，也就是唯一性约束），是立即生效的。OB 1.x 版本里在表存在的情况下新建的索引（包括唯一索引），命令立即返回，但是索引不是立即生效。需要等到OB集群发起大合并之后才会生效。其中唯一索引需要等待两次大合并。所以运维建索引后需要安排1-2次大合并操作。OB 2.x 版本里在表存在的情况下新建的索引（包括唯一索引），命令立即返回，索引也不是立即生效，但是索引开始后台异步创建，创建时间取决于数据量。 示例如下： 1. OB 1.x 版本的索引 2. OB 2.x 版本的索引 ------------------------- OceanBase合并触发条件 Q：OceanBase什么时候会触发「合并」？ A： OceanBase的数据写之前事务日志redo会及时落盘，但是数据的增量修改会一直在OB的增量内存memtable里，每天会落盘一次，这个就是合并。合并时间可以设定（major_freeze_duty_time）。另外，如果memtable使用率超过阈值（freeze_trigger_percentage），就会触发「冻结」，然后就是minor compaction，以及「转储」操作。转储会释放memtable内存，增量数据被输出到磁盘上，转储有次数限制（最大由参数minor_freeze_times），这个次数用完了就会触发「合并」。合并会比较耗OB的资源，时间长短取决于有多少增量数据要跟基线数据合并。 ## 查看冻结转储参数SHOW parameters WHERE NAME IN ('enable_major_freeze','minor_freeze_times','freeze_trigger_percentage','major_freeze_duty_time') AND svr_ip IN ('11.166.175.6');## 触发冻结合并ALTER system major freeze;SELECT sleep(1);## 查看冻结合并历史SELECT str_to_date(h.gmt_create,'%Y-%m-%d %h:%i:%s') gmt_create, module, EVENT,name1,value1,name2,value2 FROM __all_rootservice_event_history hWHERE h.module IN ('daily_merge','major_freeze', 'root_service')ORDER BY gmt_create DESC LIMIT 50; 示例：

OceanBase在云栖社区上的公众号（https://yq.aliyun.com/teams/356）和论坛版块（https://bbs.aliyun.com/thread/439.html）欢迎大家在论坛里讨论OceanBase技术问题。