Oceanbase

本文章介绍了OceanBase集群对于数据文件的缩容场景，并提供一种缩容计划予以参考。 作者：关炳文，爱可生 DBA 团队成员，负责数据库相干技术支持，一步两阶梯，兼具怠惰与慵懒。 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 本文约 1200 字，预计浏览须要 4 分钟。 缩容场景此前某银行一套 1-1-1 架构的 OceanBase 集群其中一个节点，OBServer 程序解体时默认生成 core 文件在数据盘 /data/1。个别状况下，core 文件的大小即为程序运行时占用的内存大小，约 400GB。然而数据盘早已预调配 90% 的空间给数据文件（block_file），残余可用空间不足以寄存如此之大的文件，导致 /data/1 目录被写满，并由此引发两个问题： core 文件没写残缺，不残缺的 core 文件使得对故障起因的剖析工作难以停顿。数据盘被写满，间接导致该节点无奈对外业务提供服务。复原 OBServer 服务之后，通过与项目组探讨，决定 采取给该集群的数据文件进行缩容至数据盘总大小的 80% ，防止日后故障复现时产生同样状况。 本文内的图片以及代码中展现的服务器信息（IP 地址、集群名、租户名），为集体搭建的模仿环境所用，仅用于辅助阐明具体步骤。缩容操作版本信息OBServer 版本：3.2.3OCP 版本：3.3.3相干参数datafile_size用于设置数据文件的大小。如果想要缩减 datafile_size，能够将这个节点从集群中删除，重建这个节点，集群以后值为 0。 datafile_disk_percentage示意占用 data_dir 所在磁盘总空间的百分比，集群以后值为 90。 1 调整参数集群->参数治理，调整 datafile_disk_percentage 的值为 80，即 block_file 占盘比例为 80%。 2 缩减租户正本集群->租户治理，抉择租户（包含 sys 租户）在正本详情中选中 zone 删除正本（例：zone3），期待工作完结。 3 下线 OBServer集群->总览，OBServer 列表中删除 zone3 的 OBServer，相当于在该节点卸载 OBServer 服务，期待工作完结。 ...

OceanBase 单机租户容许创立的最大分区数是多少？作者通过分区超限谬误排查，计算出单机容许创立的最大分区数量。 作者：何文超，爱可生南区交付服务部 DBA 团队成员，次要负责 MySQL 故障解决，MySQL 高可用架构革新，OceanBase 相干技术支持。喜好足球，羽毛球。 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 本文共 1200 字，预计浏览须要 3 分钟。 背景ERROR 1499 (HY000): Too many partitions (including subpartitions) were defined创立表报错，尽管是外部谬误，然而错误信息是指：创立了太多了分区。 [root@observer04 ~]# mysql -h10.186.64.125 -P2883 -uroot@wenchao_mysql#hwc_cluster:1682755171 -p"xxxx" MySQL [lss]> CREATE TABLE `wms_order` ( `A1` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT 'A1', `A2` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT 'A2', `A3` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT 'A3', `A4` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT 'A4', `A5` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT 'A5', `A6` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT 'A6', `A7` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT 'A7', `A8` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT 'A8', `A9` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT 'A9', `A10` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT 'A10') DEFAULT CHARSET = utf8mb4 ROW_FORMAT = DYNAMIC COMPRESSION = 'zstd_1.0' REPLICA_NUM = 3 BLOCK_SIZE = 16384 USE_BLOOM_FILTER = FALSE TABLET_SIZE = 134217728 PCTFREE = 0 COMMENT = '物流订单表'MySQL [lss]> ERROR 1499 (HY000): Too many partitions (including subpartitions) were defined接下来咱们剖析一下问题的起因。 ...

上一期咱们讲了对于 OceanBase 平安审计的《身份甄别》和《用户治理与访问控制》 两个局部，OceanBase 的平安机制介绍其反对传输加密，明天咱们次要来实际一下如何配置传输加密以及验证是否真的加密。 作者：金长龙 爱可生测试工程师，负责 DMP 产品的测试工作。 作者：陈慧明 爱可生测试工程师，次要参加 DMP 和 DBLE 自动化测试项目。 本文起源：原创投稿 * 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 OceanBase 的平安机制介绍其反对传输加密，明天咱们次要来实际一下如何配置传输加密以及验证是否真的加密。 环境筹备企业版 OceanBase 4.1 集群（3 节点） + OBProxy配置 CA、服务端、客户端证书OceanBase 社区版也能够实现。OBServer 传输加密2.1 开启加密OceanBase 传输加密的开启通过多个配置项配合应用。 通过 root 用户登录 sys 租户指定私钥/证书/CA 证书的获取形式alter system set ssl_external_kms_info = '{"ssl_mode":"file"}';配置 MySQL 端口 SSL 通信alter system set ssl_client_authentication = 'TRUE';# 配置为 TRUE 后，MySQL 通信 SSL 即时开启。配置 RPC 通信的 SSL 白名单因为 OBServer 之间 TCP 连贯都是长连贯，因而须要重启 OBServer 后 RPC SSL 加密通信能力开启。 ...

OceanBase 环境根本都会先装置 OCP 来部署、监控、运维数据库集群。但如果有机器过保等问题，就须要有安稳的 OCP 节点的替换计划。 作者：张瑞远 上海某公司 DBA，已经从事银行、证券数仓设计、开发、优化类工作，现次要从事电信级 IT 零碎及数据库工作。有三年以上 OceanBase 工作教训。取得的专业技能与认证包含 OceanBase OBCP、Oracle OCP 11g、OracleOCM 11g 、MySQL OCP 5.7。 本文起源：原创投稿 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。前言OceanBase 云平台（OceanBase Cloud Platform，OCP），是以 OceanBase 为外围的企业级数据库治理平台。 咱们生产环境根本都是须要先创立 OCP 平台，而后依赖 OCP 去创立及治理监控生产集群，所以装置 OCP 个别是零碎上线的第一步。之后可能随着机房布局等问题，就会有须要搬迁或者替换 OCP 的机器的需要。 别离介绍两种 OCP 节点的替换办法。一种是应用 OAT 平台（OceanBase Admin Toolkit，管理者工具）来替换；另一种就是应用 antman 脚本替换。本文先介绍第一种。 PS：我的环境的 OCP 负载平衡应用的 F5，所以新的机器须要先配置 F5，其余负载平衡场景同理。环境背景大家如果有接触 OB 生产环境的教训的话，能够能会理解，后期版本在装置 OCP 的时候，须要装置 OCP 软件/metadb/obproxy 三个 Docker 包，前期 OCP 版本将 DB+Proxy 集成在了一个 Docker 包里，OAT 的话只能纳管 DB+Proxy。集成的 metadb，离开的状况还须要应用 antman 脚本来替换。 ...

突发奇想OBClient 是连贯数据库的客户端工具。可同时兼容拜访 OceanBase 数据库的 MySQL 以及 Oracle 租户。 在常常应用的过程中，突发奇想给本人的 OBClient 定制给非凡的标签显示。 批改前成果 批改后成果 以下是自己调整办法，仅供参考(●'◡'●) 1、装置依赖并拉取 OceanBase 源码[root@10-186-61-36 ~]# yum install -y git cmake gcc make openssl-devel ncurses-devel rpm-build gcc-c++ bison bison-devel zlib-devel gnutls-devel libxml2-devel openssl-devel libevent-devel libaio-devel[root@10-186-61-36 ~]# git clone https://github.com/oceanbase/obclient.gitCloning into 'obclient'...remote: Enumerating objects: 9229, done.remote: Counting objects: 100% (299/299), done.remote: Compressing objects: 100% (243/243), done.remote: Total 9229 (delta 85), reused 121 (delta 44), pack-reused 8930Receiving objects: 100% (9229/9229), 112.91 MiB | 4.14 MiB/s, done.Resolving deltas: 100% (2960/2960), done.Checking out files: 100% (8729/8729), done.2、批改源代码文件第一个文件：obclient/client/mysql.cc ...

本文汇总了我的项目实际中前辈的教训和笔者的了解，旨在帮忙初学 OceanBase（以下简称 OB）的工程师，疾速解决 SQL 执行迟缓等性能问题。当遇到性能问题时，很多工程师可能会感到无从下手，本文将依据要害日志提供多种剖析方向，以减速问题排查。 背景利用连贯 OB 的生产架构，个别有两种： 应⽤ -> OBProxy -> OBServer应⽤ -> OBProxy-Sharding -> OBServer前者是大多数客户使⽤场景，后者是多数客户使⽤的单元化架构场景，后文将 OBProxy 和 OBProxy-Sharding 统称为 ODP（OceanBase Database Proxy）。 当咱们发现某条语句耗时较长时，咱们须要排查的点有：应⽤到 ODP 的⽹络工夫、ODP 的执行工夫、ODP 到 OBServer 的⽹络工夫、OBServer 的执行工夫。 从哪些信息动手？要诊断哪局部工夫耗费长，以及起因是什么，大多数状况会从如下几个组件获取信息。 ODP 组件obproxy_digest.log：审计⽇志，记录执⾏失败的 SQL 语句、执行工夫大于参数 query_digest_time_threshold 阈值（默认是 2ms）申请。obproxy_slow.log：慢 SQL 申请日志，记录执⾏工夫大于参数 slow_query_time_threshold 阈值（默认是 500ms）的申请。obproxy.log：ODP 总日志。在 obproxy_digest.log 和 obproxy_slow.log 中，第 15、16、17、18 列（即 8353us,179us,0us,5785us）别离示意：ODP 解决总工夫、ODP 预处理工夫、ODP 获取连接时间、OBServer 执⾏工夫。示例如下： 2023-05-0416:46:03.513268,test_obproxy,,,,test:ob_mysql:sbtest,OB_MYSQL,sbtest1,sbtest1,COM_QUERY,SELECT,failed,1064,select t1.*%2Ct2.* from sbtest1 t1%2Csbtest2 t2 where t1.id = t2.idwhere id <10000,8353us,179us,0us,5785us,Y0-7FA25BB4A2E0,YB420ABA3FAC-0005FA2415BE0F81-0-0,,,0,10.186.63.172:2881ODP 解决总工夫的终点：ODP 接管到客户端申请的工夫；ODP 解决总工夫的起点：ODP 把所有的数据都写回给客户端；ODP 预处理工夫：蕴含去 oceanbase.__all_virtual_proxy_schema 查问 Leader 的工夫；ODP 获取连接时间：目前不做记录，看到的都是 0；OBServer 执行工夫：终点是 ODP 发送申请给 OBServer，起点是收到 OBServer 返回第一条记录。从下面的原理能够看出，后三项工夫相加并不等于第一项工夫，比方 ODP 解决总工夫比拟长，然而预处理工夫和 OBServer 执行工夫都很短，有可能工夫耗费在 OBServer 将第一条记录返回给 ODPServer 和 ODPServer 把所有数据写回给客户端之间，这在后果集较大的 SQL 语句中⽐较常⻅。 ...

近日，OceanBase开源社区引入新的成员-上海爱可生信息技术股份有限公司（以下简称“爱可生”），作为国内出名的开源数据库整体解决方案公司，爱可生将投入内核研发、工具产品、服务撑持踊跃退出OceanBase社区生态，并推出基于OceanBase开源内核的商业发行版ActionDB。 爱可生始终致力于开源数据库、周边生态工具和服务体系，爱可生开源社区也保护本人的数据库开源我的项目，并汇集了泛滥国内的开源数据库爱好者。爱可生开源社区以提供开源数据库周边工具、日常分享数据库技术干货，致力构建残缺的开源数据库常识体系、帮忙数据库技术人才的继续成长。爱可生开源社区目前开源的我的项目有：SQL审核工具SQLE、分布式中间件DBLE、数据传输组件DTLE、全局事务框架TXLE等。OceanBase自2021开源以来，继续吸引了大量开发者和合作伙伴共建数据库开源生态。OceanBase开源社区致力于和搭档一起共建数据库生态，打造残缺的数据库利用体系，保持开源凋谢中更好解决用户开源数据库应用中的痛点问题。爱可生凭借在开源数据库畛域十多年的业余能力积攒，尤其有多年基于金融、电信等外围行业的运维基线、运维标准的了解和实战经验，会更好地帮忙OceanBase在国内公有云场景的落地。本次爱可生退出开源社区并致力于成为 OceanBase开源社区的重要贡献者，必将踊跃推动OceanBase开源社区生态倒退。退出OceanBase开源社区后，爱可生利用本人的工具能力、内核奉献和服务能力，并推出基于OceanBase开源内核的商业发行版ActionDB。发行版ActionDB继承了OceanBase的优良个性：分布式架构、强一致性、高可靠性、高并发性、高扩展性等，同时在平安、易用性、工具等方面将进行优化和加强，提供企业级的平安个性、审计能力、多库管理工具等性能，并将提供OceanBase开源数据库的服务能力，将更好满足不同行业和场景的数据库需要。将来，爱可生聚焦用户新需要，帮助数据库不同利用场景下的数据库技术优化和迭代，比方将在生态兼容（如OceanBase与MySQL复制的全面兼容）、平安可信（全密态数据库与可信计算的联合）等方面积极探索，并将这些摸索奉献社区、回馈社区。 本文关键字：#OceanBase# #ActionDB#

本文摘要本文剖析并复现了 OceanBase 频繁更新数据后读性能降落景象的起因，并给出了性能改善倡议。 背景测试在做 OceanBase 纯读性能压测的时候，发现对数据做过更新操作后，读性能会有较为显著的降落。具体复现步骤如下。 复现形式环境准备部署OB应用 OBD 部署单节点 OB。 版本IPOceanBase4.0.0.0 CE10.186.16.122参数均为默认值，其中内存以及转储合并等和本次试验相干的重要参数值具体如下： 参数名含意默认值memstore_limit_percentage设置租户应用 memstore 的内存占其总可用内存的百分比。50freeze_trigger_percentage触发全局解冻的租户应用内存阈值。20major_compact_trigger设置多少次小合并触发一次全局合并。0minor_compact_trigger管制分层转储触发向下一层下压的阈值。当该层的 Mini SSTable 总数达到设定的阈值时，所有 SSTable 都会被下压到下一层，组成新的 Minor SSTable。2创立 sysbench 租户create resource unit sysbench_unit max_cpu 26, memory_size '21g';create resource pool sysbench_pool unit = 'sysbench_unit', unit_num = 1, zone_list=('zone1');create tenant sysbench_tenant resource_pool_list=('sysbench_pool'), charset=utf8mb4, zone_list=('zone1'), primary_zone=RANDOM set variables ob_compatibility_mode='mysql', ob_tcp_invited_nodes='%';数据准备创立 30 张 100 万行数据的表。 sysbench ./oltp_read_only.lua --mysql-host=10.186.16.122 --mysql-port=12881 --mysql-db=sysbenchdb --mysql-user="sysbench@sysbench_tenant" --mysql-password=sysbench --tables=30 --table_size=1000000 --threads=256 --time=60 --report-interval=10 --db-driver=mysql --db-ps-mode=disable --skip-trx=on --mysql-ignore-errors=6002,6004,4012,2013,4016,1062 prepare环境调优手动触发大合并 ...

作者：操盛春 技术专家，任职于爱可生，专一钻研 MySQL、OceanBase 源码。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 本文是对官网同名文档局部内容的解释，官网文档链接：https://www.oceanbase.com/docs/enterprise-oceanbase-database-... 一、查看解冻状况1.1 解冻性能是否失常？以 tenant_id = 1001 租户为例，查问 __all_virtual_tenant_memstore_info 表： -- 留神：where 条件中 tenant_id 须要批改成理论场景对应的值select * from __all_virtual_tenant_memstore_info where tenant_id = 1001\G*************************** 1. row *************************** tenant_id: 1001 svr_ip: 10.186.17.106 svr_port: 22882active_memstore_used: 1295451600 total_memstore_used: 1298137088major_freeze_trigger: 8589934550 memstore_limit: 17179869150 freeze_cnt: 0active_memstore_used 示意沉闷状态的 MemTable 占用的内存，major_freeze_trigger 示意 memstore 占用内存达到 major_freeze_trigger 之后会触发转储（或合并）。 如果解冻性能失常，租户 memstore 占用内存达到 major_freeze_trigger 之后，就会先解冻、而后转储该租户下的 MemTable，转储实现的 MemTable 占用的内存会从 active_memstore_used 中减去。 解冻是转储或合并的前置操作，所以，先依据 active_memstore_used 和 major_freeze_trigger 的大小关系，判断解冻性能是否失常： active_memstore_used <= major_freeze_trigger，阐明解冻性能失常，须要查看转储状况，参照 2. 查看转储状况大节。active_memstore_used > major_freeze_trigger，阐明解冻性能不失常，须要查看解冻线程的状况，参照 1.2 解冻线程是否失常工作？大节。1.2 解冻线程是否失常工作？能够执行以下命令判断负责解冻性能的线程是否在失常运行： ...

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 明天遇到一个 OceanBase 数据库下 Oracle 租户的 PLSQL 分隔符问题，特来分享下。 我的初衷是对 Oracle 租户下的一张表造点随机数据，写好了 INSERT 语句，却提醒没有函数 dbms_random.value 。于是查阅 OceanBase 官网文档，发现须要导入零碎包 dbms_random ！dbms_random 零碎包寄存在 OceanBase 装置目录下的 admin 子目录里，蕴含两个 SQL 文件，一个是包的申明 SQL：dbms_random.sql；另一个是包的定义 SQL：dbms_random_body.sql 。 我在 obclient 下导入这两个 SQL 文件，间接报语法错误。官网给的 SQL 文件怎么可能有语法错误呢？预计是我没有齐全依照文档来标准操作而导致的问题。 最终我把报错的中央提取进去，整顿成如下简略函数： create or replace function tt return number is v1 number; v2 number; begin v1 := 10; v2 := sqrt(-2 * ln(v1)/v1); return v2; end; /间接执行这个函数，也是报同样的谬误。 ...

作者：张乾 外星人2号，现专任六位喵星人的资深铲屎官。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 手滑误删了数据文件，并且没有可替换的节点时，先别急着提桶跑路，能够思考利用参数 server_permanent_offline_time 来重建受影响的节点。 原理：server_permanent_offline_time 是 OceanBase 数据库中用于管制节点永恒下线时长的参数。当集群中的某个节点宕机后，零碎会依据该参数的设置值来进行相应操作。 如果节点宕机工夫小于该参数设置的值，零碎会临时不做解决，以防止频繁的数据迁徙；如果宕机工夫超过该参数设置的值，该节点被标记为永恒下线，RootService 会将该 OBServer 上蕴含的数据正本从 Paxos 成员组中删除，并在同 zone 内其余可用 OBServer 上补充数据，以保证数据正本 Paxos 成员组残缺。该参数默认值是 3600 秒，个别设置较大，以防止不必要的正本复制。此外，当永恒下线的节点从新被拉起后，其上的全副数据都须要从其余正本从新拉取。 在本场景下，即是通过调低该参数，让故障节点疾速永恒下线再从新上线，达到数据重建的目标。 请留神，此过程会占用集群肯定的资源，可能会影响性能，因而倡议在业务低峰期进行。 官网倡议对于 server_permanent_offline_time 的实用场景和倡议值，官网提供如下: OceanBase 数据库版本升级场景：倡议将该配置项的值设置为72h。OBServer 硬件更换场景：倡议将该配置项的值设置为4h。OBServer 清空上线场景：倡议将该配置项的值设置为10m，使集群疾速上线。筹备过程准备一套环境应用OBD工具疾速部署一套3节点OB以及一个OBProxy，再创立好一个租户sysbench_tenant，primary_zone为RANDOM。 注：本文基于OB 3.1.2版本，其余版本需注意另作验证。 筹备些数据应用 sysbench 创立一个表 sbtest1 并插入1W数据。 sysbench ./oltp_insert.lua --mysql-host=10.186.60.3 --mysql-port=2883 --mysql-db=sysbenchdb --mysql-user="sysbench@sysbench_tenant" --mysql-password=sysbench --tables=1 --table_size=10000 --threads=1 --time=600 --report-interval=10 --db-driver=mysql --db-ps-mode=disable --skip-trx=on --mysql-ignore-errors=6002,6004,4012,2013,4016,1062,5157,4038 prepare这里改写了 sysbench 的建表语句，分了3个区，查问 sbtest1 表分区正本散布如下 MySQL [oceanbase]> select tenant.tenant_name, zone, svr_ip,svr_port, case when role=1 then 'leader' when role=2 then 'follower' else NULL end as role, count(1) as partition_cnt from __all_virtual_meta_table meta inner join __all_tenant tenant on meta.tenant_id=tenant.tenant_id inner join __all_virtual_table tab on meta.tenant_id=tab.tenant_id and meta.table_id=tab.table_id where tenant.tenant_id=1001 and tab.table_name='sbtest1' group by tenant.tenant_name,zone, svr_ip,svr_port, 5 order by tenant.tenant_name, zone, svr_ip, role desc;+-----------------+-------+--------------+----------+----------+---------------+| tenant_name | zone | svr_ip | svr_port | role | partition_cnt |+-----------------+-------+--------------+----------+----------+---------------+| sysbench_tenant | zone1 | 10.186.64.74 | 2882 | leader | 1 || sysbench_tenant | zone1 | 10.186.64.74 | 2882 | follower | 2 || sysbench_tenant | zone2 | 10.186.64.75 | 2882 | leader | 1 || sysbench_tenant | zone2 | 10.186.64.75 | 2882 | follower | 2 || sysbench_tenant | zone3 | 10.186.64.79 | 2882 | leader | 1 || sysbench_tenant | zone3 | 10.186.64.79 | 2882 | follower | 2 |+-----------------+-------+--------------+----------+----------+---------------+开始试验应用 sysbench 继续写入数据，维持肯定的流量，便于在节点重建后比照各节点数据是否统一。 ...

2023年3月25日，首届OceanBase开发者大会在北京举办。NineData 的首席架构师谭宇（茂七）受邀加入 OceanBase 数据管理与服务技术专场，发表了《NineData 多云数据管理》主题演讲。谭宇示意：作为已经 OceanBase 开创团队成员，做过内核开发、平台，还开辟过客户，算是“样样都干”。尽管来到了 OceanBase 团队，但依然为 OceanBase 获得的问题感到自豪。明天，咱们看到做一个数据库内核很难，然而要把数据库建成一个生态能够说更难。目前 NineData 所做的工作，可能帮忙大家更好地用好 OceanBase、用好数据库。 NineData 的首席架构师谭宇（茂七）整体介绍次要会分享以下几个内容：一是介绍一下玖章算术团队和 NineData 多云数据管理平台的整体状况；二是着重介绍一下咱们在数据复制方面的一些工作；最初是咱们对多云数据管理平台，将来的一点认识和对多云应用的一些倡议。研发团队先来简略的看一下 NineData 团队的根本状况。 NineData团队根本状况NineData 团队次要来自阿里云数据库团队，创始人叶正盛、花名斗佛大家可能都意识，已经负责阿里云数据库产品与解决方案事业部总经理，也就是负责整个阿里云数据库产品体系的打造以及相干解决方案的制订，并研发了 DTS/DMS/DBS/DAS 等多款云原生数据产品。在做这些产品的过程中，咱们其实就始终在思考一个问题，就是这一类产品应该在云厂商做还是该由独立的厂商来做，最初咱们感觉如果处于一个第三方中立的立场上可能将这类产品做得更好，所以在2021年11月份的时候斗佛创建了玖章算术，通过一年的打磨，推出了 SQL 开发、数据复制、数据备份和数据比照四款产品，推出后取得了业界的一些奖项，也是对咱们在这个畛域的粗浅认知的必定。 NineData产品整体概览这是咱们产品的一个整体概览，先来看这个图的最底层，有两个关键点，一是“多云或多基础设施反对”，不论是阿里云、华为云、AWS 还是自建 IDC，咱们都能够提供反对。另一个是“多数据库类型反对”，明天企业都会应用很多种数据库来加工和解决数据。对于“多云和多源”的反对是咱们的外围竞争力之一。NineData产品能力而后再来具体看咱们的产品。最上层是 SQL 开发，它负责的是 DataBase DevOPS，次要解决团队之间的协同开发效率与数据安全的问题。上面是数据复制和数据比照两个性能，次要是两个方面的考量，一方面是数据要流动、散发能力产生价值，另一方面是数据流动也常常引起数据不统一或数据品质相干的问题。最上面是数据备份，在数据作为企业最重要的资产之一的明天，如何做好备份以及将备份这种较冷的数据利用起来也是一个十分重要的课题。为什么做这四个产品，一方面当然是出于咱们之前的教训，另一个方面也是咱们看到了有问题须要解决。云计算催生了数字化，所以每个企业都在朝科技企业转变，对云和数据的使用就显得至关重要，特地是随着多云和多数据源的采纳，要应用好云和数据是一件十分有挑战的事件。 NineData多云数据管理平台建设背景第一个是开发效率、业务稳定性与数据安全方面的挑战，有报告表明，开发效率高的企业其营收增长和翻新速度均远高于业界平均水平。开发同学不操作线上数据库会导致效率问题，操作线上数据库则产生稳定性与数据安全方面的问题。第二个是数据散发方面的挑战，既然应用了多种数据库类型来解决数据，数据就须要流动起来，然而多云和多源同时也妨碍了数据散发。最初是数据保护和数据品质方面的挑战，如何确保数据失去了无效的爱护？如何保证数据在流动后还能保持一致？NineData利用场景从这些问题登程，咱们构建了 NineData 多云数据管理平台，整体利用场景是这样： NineData数据管理场景其中 SQL 开发模块治理的是协同流程，次要是从日常环境到线上环境的数据库变更与平安操作线上数据库。数据备份专一于爱护外围的数据资产，而数据复制则用于各个环境、上下游零碎、不同业务之间的数据散发与同步。数据比照则保障所有环节的数据一致性。数据复制：技术解读理解了场景之后，接下来深刻的看一下数据复制这个产品。咱们把数据复制定义为数据流动的基础设施，一般来说数据复制会有这几种场景： NineData数据流动的基础设施一是业务之间或上下游之间的数据流动，比方 TP 到 AP、数据库到搜索引擎、音讯零碎等。二是不同厂商之间的数据流动，比方咱们访问过的很多客户，不论是出于议价或用云所长等起因都在逐渐走向多云。三是跨境的数据流动，这个比常见比方跨境电商、出海企业都有数据归集剖析的需要。从这三种典型的场景，咱们能够总结数据复制面临的几个艰难： 数据复制面临艰难NineData 很好的解决了这些难点，并造成了两大根底能力与五大产品劣势： NineData数据复制能力及劣势接下来我会着重解说一下咱们的多云互通架构与产品劣势。 多云互通架构与产品劣势NineData 的架构充分利用了获取云资源的便利性与弹性。通过将零碎中必须要事后存在的节点和能够动静拉起的节点离开，咱们造成了核心管制节点与单元节点拆散的架构，只事后拉起核心节点以节俭资源和老本，当有用户工作过去的时候，零碎会主动购买与用户数据库雷同 Region 的资源并拉起服务，同时会继续关注任务量来进行主动伸缩。在网络的解决方面，NineData 反对私网连贯、网关模式以及专属模式供不同的用户进行抉择。通过奇妙的架构设计与精密的网络解决，咱们当初曾经能够联通绝大多数支流的云厂商以及自建机房。数据复制：外围劣势接下来是咱们的几个外围劣势：一是欠缺的预查看机制。因为多云和多源的复杂性，有十分多的因素会导致数据复制失败，咱们查看影响工作的每个方面并一次性给出查看后果与解决计划，能够极大的晋升后续工作成功率。 NineData欠缺的预查看机制二是齐备的构造同步。NineData 自研了十分残缺的 SQL 解析器，比市面上开源的计划都要精密得多，比方在咱们结构的400个 case 中，最好的开源 SQL 解析器也只能解决其中的350条。 ...

作者：姚嵩 不晓得是地球人还是外星人，晓得的能够留言通知小编... 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 背景：ob中的租户相当于咱们平时认知的数据库集群，对外提供数据库服务。 当须要删除ob中的租户时，会删除该租户下的所有对象，蕴含数据库、表等。 数据是⾮常重要的，为了防止意外状况， 此时，你可能须要设置多种策略，以便确认&解决⼀些异样场景： 1.确认该租户删除后，业务是否会有异议； 2.删除租户后，如果业务须要，也能够复原该租户； 环境阐明：ob版本： 5.7.25-OceanBase-v3.2.3.2 租户类型： MySQL租户 待删租户名： obcp_t1 删除租户的⼤概流程：1.确认租户以后是否正在被使⽤，如果租户以后正在被业务使⽤，则和业务沟通确认租户是否真的要删除； 2.如果租户未被使⽤，锁定租户； 3.⼲掉租户现有的闲暇连贯，防⽌现有连贯执⾏SQL； 4.租户锁定N天，期待业务反馈是否受影响，防止待删除的租户影响业务模块； 5.业务反馈⽆影响后，删除租户。 操作步骤：阐明：下⾯的操作都是使⽤sys租户下的root账户操作； 倡议采⽤间接连贯observer的连贯⽅式，因为执⾏kill的操作须要直连observer执⾏ (kill的session_id来源于oceanbase.__all_virtual_processlist表)。 -- 设置⽤户变量存储租户名 set @tenant_name='obcp_t1';-- 确定租户以后是否正被使⽤ -- 如果存在⾮Sleep状态的会话，须要确认是否正在执⾏SQL，如果存在，须要和业务沟通租户是否正确 select user,tenant,host,db,command,svr_ip,user_client_ip, trans_id,thread_id,total_time,infofrom oceanbase.__all_virtual_processlistwhere tenant=@tenant_name and command!='Sleep'order by total_time desc ;-- 如果租户以后⽆业务执⾏，锁定租户 -- 锁定租户后，就不能在该租户上创立新的连贯，已有连贯放弃不变 alter tenant obcp_t1 lock ; -- 锁定是幂等操作，能够反复执⾏ select tenant_name,locked from __all_tenant ; -- 1示意锁定，0示意未锁定-- ⽣成kill租户会话的语句 select concat('kill ',id,';') from oceanbase.__all_virtual_processlistwhere tenant=@tenant_name;-- (直连observer)执⾏上⼀个步骤⽣成的kill语句，杀掉租户已有的连贯 kill xxx;.....-- N天后，业务反馈⽆影响，再持续租户删除步骤 ...

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 之前在学习 OBCP 的培训资料时，有一项名为 BUFFER 表的解释，过后也没太在意（次要是 OBCP 考试里没有波及到），之后当他人考我时，我 ......！ 什么是BUFFER 表（OceanBase 里也叫 Queuing 表）？之前我认为 BUFFER 表就是全局长期表或者说是相似 MySQL 一次性整体导入的 MyISAM 表，对这类表的操作无非是划出一块内存区域对其进行读写，来防止频繁的 IO 操作。通过查阅 OceanBase 官网文档后，这个 BUFFER 表并非我了解的那样（我的了解齐全谬误）。 所谓 BUFFER 表指的是某张表（表记录数可能并不多）被频繁的全量更新（所有记录被执行批量 DML 操作）、按肯定比率更新（比方20%的记录被执行批量DML操作），短时间又对这张表进行全量检索，性能急剧下降或者说比之前性能有明显降低的这样一种景象。对于 OceanBase 来讲，对表的 DML 操作都是只打标记（比方 UPDATE ，变为 DELETE 打标记+INSERT），后盾再缓缓异步清理旧的数据。所以必然会在更新频率过快并且后盾线程清理数据不及时导致的重大读写放大问题、或者统计信息重大不精确（OceanBase 统计信息在合并时触发）导致的执行打算非最优的问题，最终影响检索性能。 能够通过如下操作来进行补救： 绑定执行打算，人为疏导优化器抉择最优执行门路。 比方创立 OUTLINE 让 SQL 语句绑定固定执行打算。手工进行转储或者合并来清理无用数据。给表加属性 table_mode='queuing' 。 这个属性是 OceanBase 专门为 BUFFER 表做的优化，具体流程简略概述为：当 BUFFER 表更新记录数超过肯定阈值时，主动对这张表进行独自转储以打消大量有效检索，从而实现对 BUFFER 表的疾速检索。这个表属性针对 MySQL 租户和 Oracle 租户都无效。Oracle 租户能够自定义 BUFFER 表转储阈值：一个是触发基于全量数据的转储百分比（_ob_queuing_fast_freeze_min_threshold）;另外一个是触发疾速转储的记录数（_ob_queuing_fast_freeze_min_count）。MySQL 租户目前没看到对应配置项，然而其对BUFFER表的批量更新申请，后盾也会有对应的转储操作（对应表：gv$merge_info）。比方在 MySQL 、Oracle 租户下都创立一张表t2，指定表 table_mode='queuing' 。 ...

作者：姚嵩 不晓得是地球人还是外星人，晓得的能够留言通知小编... 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 简介：删除租户后，租户下的数据库和表也同时被删除。 然而租户使⽤的资源配置不会被删除，资源配置能够持续给其余租户使⽤。 留神只有sys租户的root⽤户能力执⾏drop tenant命令。 语法：DROP TENANT [IF EXISTS] tenant_name [PURGE|FORCE];删除租户的⽅式： 删除租户⽅式的区别： 查看和设置提早回收工夫：show parameters like 'schema_history_expire_time'; -- 取值范畴[1h, 30d]，默认7天；alter system set schema_history_expire_time='7d' ; -- 设置提早回收工夫，设置即⽣效；查看和设置回收站⾃动清理工夫： show parameters like 'recyclebin_object_expire_time'; -- 取值范畴[0s, +∞)，0s示意敞开⾃动回收性能； ALTER SYSTEM SET recyclebin_object_expire_time = "7d"; -- 设置⾃动清理工夫，设置即⽣效；回收站中租户的解决：删除租户，将其置于回收站中： set recyclebin=1; DROP TENANT t1;查看回收站中的租户： show recyclebin ; select tenant_name,status,in_recyclebin, from_unixtime(substr(drop_tenant_time,1,10),"%Y-%m-%d %H:%i:%s") drop_tenant_time from oceanbase.__all_tenant where in_recyclebin=1 ;复原回收站中的租户(回收租户时，租户名可⽤租户原始名称或者回收站中的对象名)： FLASHBACK TENANT t1 TO BEFORE DROP ; -- 使⽤租户原始名称复原 FLASHBACK TENANT __recycle_$_1665918035_1676612471384576 TO BEFORE DROP ; -- 使⽤租户回收站中的名称复原 select tenant_name,status,in_recyclebin, from_unixtime(substr(drop_tenant_time,1,10),"%Y-%m-%d %H:%:%s") drop_tenant_time from oceanbase.__all_tenant where tenant_name='t1' ;革除回收站中的租户： ...

OceanBase 是由蚂蚁团体自主研发的高性能分布式关系型数据库系统。它采纳分布式架构和高可用设计，反对海量数据存储和高并发拜访，可能为企业提供稳固、高效、可扩大的数据管理服务。 OceanBase 通过自主研发的分布式事务引擎、高性能存储引擎和智能优化器等核心技术，实现了多正本数据主动同步和故障复原、高效数据查问和批改、以及数据安全爱护等性能。此外，它还提供了丰盛的数据管理工具和 API，反对 SQL 语言和 NoSQL 接口，能满足各种利用场景的需要。 目前码匠曾经实现了与 OceanBase 数据源的连贯，反对对 OceanBase 数据进行增、删、改、查， 同时还反对将数据绑定至各种组件，并通过简略的代码实现数据的可视化和计算等操作，能让您疾速、高效地搭建利用和外部零碎。 在码匠中集成 OceanBase步骤一：新建数据源连贯，抉择 OceanBase 数据源，并依据提醒填写相应配置。 步骤二：新建 OceanBase 查问，码匠中反对 SQL 模式和 GUI 模式，让您可能更加灵便便捷地操作数据。 步骤三：书写/抉择查询方法并展现/应用查问后果。 在码匠中应用 OceanBase操作数据：在码匠中能够对 OceanBase 数据进行增、删、改、查的操作，在 SQL 模式下能够自定义查问语句，在 GUI 模式下则有以下操作，即便对 SQL 语法不相熟也能疾速上手： 插入插入，抵触后更新更新删除批量插入批量更新应用数据：这两种模式下，用户能够在左侧的查问面板内查看数据结构，并通过{{yourQueryName.data}}来援用查问后果： 对于码匠码匠低代码平台是一款实用于企业级利用开发的全栈低代码开发平台，旨在通过极简化开发流程，实现疾速构建利用的目标。平台采纳可视化拖拽式开发、主动生成代码、疾速迭代等低代码开发理念，使得开发者能够通过简略的操作，疾速搭建出功能丰富的利用，同时保障了利用的可扩展性和可维护性。码匠低代码平台反对多种开发语言和多种云厂商，开发者能够抉择最适宜本人团队的语言和云服务，同时平台也提供了一系列的性能组件和集成插件，开发者能够依据本人的需要进行抉择和定制。通过应用码匠低代码平台，企业能够疾速响应市场需求，升高开发成本和危险，进步开发效率和品质。 立刻试用：https://majiang.co/

作者：金长龙 爱可生测试工程师，负责DMP产品的测试工作 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 先前在做OB存储引擎这块学习的时候，对 OceanBase 的分层转储和 SSTable 这块有些细节就懵懵的，比方L0层的 mini SSTable 的每次生成是否就计入转储次数，L0层到L1层转储的机会以及和 minor_compact_trigger 之间的关系等。 明天就这部分内容做个更粗疏的探索，试图更深刻的了解 OceanBase 的分层转储。 一、LSM-Tree首先来看一下 LSM-Tree（全称是Log-Structured Merge Tree），当下许多较新的数据库都会抉择LSM-Tree作为存储构造，比方TiDB、Cassandra、OceanBase等。LSM-Tree的劣势是程序写，晋升了整体写入性能。 LSM-Tree 大抵能够分为两局部： Memtable: 常驻内存的 KV 查找树 + 无序的 WAL 文件SSTable (Sorted String Table): 一组存储在磁盘的不可变文件，存储有序的键值对写入流程1、同步写 Memtable先将数据写入 WAL 文件，而后批改内存中的 AVL，因而最优状况下，每次写操作只有一次磁盘 I/O。 删除操作并不会间接删除磁盘中的内容，而是将删除标记（tombstone）写入 Memtable。当 Memtable 增大到肯定水平后，则会转换为 Immutable Memtable 并产生一个新的 Memtable 承受写操作。 2、异步写 SSTable后盾会启动一个合并线程，当 Immutable Memtable 达到肯定数量，合并线程会将其写入磁盘（Flush），生成 Level 0 的 SSTable 文件。 当 Level N 的 SSTable 文件数量达到阈值之后，会进行合并压缩（Compaction）操作，在 Level N+1 生成新的 SSTable 文件。 ...

盼星星盼月亮！掰掰手指，间隔 3 月 25 日还有 123456......两周啦~除了白天的主论坛和分论坛的精彩分享外，晚间的 3 场 Hands-on Workshop 入手试验营也深得大家期待，从部署到迁徙，从 On-Premise 到 Cloud ，明天咱们为大家带来「 Cloud Workshop」。本次 Cloud Workshop 是 OceanBase Cloud 寰球开服以来，第一次与宽广开发者们进行的面对面、手把手的交换 。咱们心愿借此机会和大家一起入手，在实际环境中体验如何疾速应用 OceanBase Cloud 产品，接下来让咱们具体理解一下吧！ 在 OceanBase 资深技术专家的领导下，你能够学习如何在 AWS 和阿里云环境下应用 OceanBase Cloud 服务，理解 OceanBase Cloud 的产品架构、劣势、实际案例，洞悉行业趋势。技术零距离：理解 OceanBase Cloud 的云原生技术架构以及如何做到多云治理，也有数据库行业中最前沿的云数据库产品和技术分享，干货满满，紧跟行业脉搏；专家零距离：本次 Workshop 由多位行业从业教训 10 年以上的数据库专家为大家解说，并面对面为你答疑解惑，讲讲咱们在云数据库畛域的最佳实际、多云架构以及发展趋势等； 搭档零距离：在这里你会结识一批气味相投的小伙伴，线上线下独特交流经验、分享心得，兴许你将来的“最佳拍档”就在其中。 欢送所有对云数据库感兴趣的小伙伴报名参加，一起探讨云数据库的明天和将来。 ▋ 适宜人群：开发者、DBA、数据库爱好者等▋ 参会须知：参加本期线下 Workshop 须要提前报名~为保障 Workshop 体验，本期线下流动共凋谢 50 个名额；参加 Workshop 的小伙伴务必携带笔记本电脑； 软件要求：Terminal 程序并且要有 ssh 的客户端，实际学员倡议理解 Linux 常用命令；请提前准备好 Terraform 环境，也可从这里下载。https://developer.hashicorp.com/terraform/downloads最初，欢送大家提前开明OceanBase云数据库的免费版进行体验。登录下方网址即可进入 OceanBase 官网收费试用页面。简略 3 步，收费开明 30 天 1 核 4GB，10GB 存储空间的租户实例。https://www.oceanbase.com/free-trial3 月 25 日，让咱们相聚 2023 OceanBase 开发者大会 Cloud Workshop，快来报名吧！ ...

作者：杨文 DBA，负责客户我的项目的需要与保护，会点数据库，不限于MySQL、Redis、Cassandra、GreenPlum、ClickHouse、Elastic、TDSQL等等。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 一、环境阐明：集群扩容分为两种状况：一种是扩正本，一种是扩资源。 原集群部署模式：1-1-1。 上面介绍两种扩容形式： 扩容正本：扩容后的模式：1-1-1-1-1；扩容资源：扩容后的模式：2-2-2。阐明：扩容操作有两种形式：白屏形式操作和黑屏形式操作。 二、白屏形式进行扩容：扩容正本：进入OCP -> 找到要扩容的集群 -> 总览 -> 新增zone； 扩容资源：进入OCP -> 找到要扩容的集群 -> 总览 -> 新增OBServer； 如图： 三、黑屏形式进行扩容：阐明：为了防止篇幅反复，此处扩容正本和扩容资源将别离应用自动化形式扩容和手工形式扩容。 3.1、扩容正本（Zone）：通过OBD形式进行自动化扩容： 1）筹备配置文件： vi /data/5zones.yaml# Only need to configure when remote login is requireduser: username: admin #password: admin key_file: /home/admin/.ssh/id_rsa.pub #port: your ssh port, default 22 # timeout: ssh connection timeout (second), default 30oceanbase-ce: servers: # Please don use hostname, only IP can be supported - name: observer4 ip: 10.186.60.175 - name: observer5 ip: 10.186.60.176 global: ...... appname: ywob2 ...... observer4: mysql_port: 2881 # External port for OceanBase Database. The default value is 2881. rpc_port: 2882 # Internal port for OceanBase Database. The default value is 2882. # The working directory for OceanBase Database. OceanBase Database is started under this directory. This is a required field. home_path: /home/admin/oceanbase-ce # The directory for data storage. The default value is $home_path/store. data_dir: /data # The directory for clog, ilog, and slog. The default value is the same as the data_dir value. redo_dir: /redo zone: zone4 observer5: mysql_port: 2881 # External port for OceanBase Database. The default value is 2881. rpc_port: 2882 # Internal port for OceanBase Database. The default value is 2882. # The working directory for OceanBase Database. OceanBase Database is started under this directory. This is a required field. home_path: /home/admin/oceanbase-ce # The directory for data storage. The default value is $home_path/store. data_dir: /data # The directory for clog, ilog, and slog. The default value is the same as the data_dir value. redo_dir: /redo zone: zone52）部署集群： ...

作者：何文超 爱可生南区交付服务部 DBA 团队成员，次要负责MySQL故障解决，MySQL高可用架构革新，OceanBase相干技术支持。喜好足球，羽毛球。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 OceanBase 单机环境部署可参考：https://opensource.actionsky.... 一. 租户首次应用的步骤| 步骤 | 作用 | | --- | --- | | 01.创立资源单元 | 指定每个单元要应用CPU（逻辑限度）、Memory（硬限度）、IOPS（不限度）、DISK（不限度）资源分配时不要超过__ALL_VIRTUAL_SERVER_STAT残余的可用资源 | | 02.创立资源池 | 资源池须要指定资源单元以及要应用的zone || 03.创立租户 | 创立租户指定正本数量，指定资源池，执行租户类型oracle、mysql。社区版仅反对mysql版 | | 04.在租户上创立用户 | 用户是最终提交给终端用户应用的账号 || 05.提供应用 | 将账号提供给终端用户，视理论状况赋予相应权限 | 二. 创立 wms_tenant 租户（mysql类型）创立资源单元create resource unit wms_unit1 max_cpu=5,min_cpu=2,memory_size='2G';创立资源池create resource pool wms_pool1 unit 'wms_unit1',unit_num 1;创立wms_tenant租户（mysql类型，三正本）CREATE TENANT IF NOT EXISTS wms_tenant charset='utf8mb4',replica_num=3, zone_list=('zone1','zone2','zone3'), primary_zone='RANDOM',comment 'mysql tenant/instance', resource_pool_list=('wms_pool1') set ob_tcp_invited_nodes='%',ob_compatibility_mode='mysql';创立完租户后，查看当初的资源单元配置数据：sys_unit_config（sys 租户资源单元）和wms_unit1一共占用4G，加上之前500租户（零碎租户）的1G，曾经达到 memory_limit 的设置。 ...

作者：杨文 DBA，负责客户我的项目的需要与保护，会点数据库，不限于MySQL、Redis、Cassandra、GreenPlum、ClickHouse、Elastic、TDSQL等等。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 1、问题形容有时咱们在导入导出数据时，须要对数据进行解决，来满足业务上的数据需要，此时须要应用管制文件配合导数工具来满足业务上不同数据的需要。 2、管制文件模板：lang=java( 列名 字节偏移地位(可选) "预处理函数" 映射定义(可选), 列名 字节偏移地位(可选) "预处理函数" 映射定义(可选), 列名 字节偏移地位(可选) "预处理函数" 映射定义(可选));简略示例： lang=javaserver=mysql/oracle( c1 "nvl(c1,'not null')" map(field_position), c2 "none" map(field_position));参数阐明： field_position为导入的数据文件中预处理数据的列地位。管制文件的命名标准：table_name.ctl，大小写与数据库中保持一致。管制文件的内容要求列名的程序与表中定义的列程序保持一致，且列名大小写与表中的列名大小写保持一致。3、应用案例：3.1、测试数据：cat /data/test/TABLE/test.dat1@##oceanbase@##2023-01-12 15:00:00.0@##1@##ob@##1@##ob2@##oceanbase@##2023-01-12 15:00:00.0@##2@##ob@##2@##ob3@##oceanbase@##2023-01-12 15:00:00.0@##3@##ob@##3@##obcreate table test01 (id int(10) not null primary key,name varchar(10),time timestamp not null default '1971-01-01 01:01:01',blank varchar(255) null);create table test02 (id int(10) not null primary key,name varchar(10) not null,time timestamp not null,bar varchar(255) default null,blank varchar(255) default null,line varchar(255) default null,mark varchar(255) default null,test varchar(255) not null);3.2、案例1：表列少于文本列：表全列导入。 ...

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 咱们晓得，OceanBase 3.X 版本部署单机架构（一个ZONE，一台SERVER）须要消耗较多硬件资源能力失常应用。OceanBase 4.X 版本公布后，在资源占用这块做了很多优化，官网声称4.X 版本是单机分布式一体化的架构，单台OB SERVER对数据的解决与单机数据库相比性能相当。比方对于 OceanBase 3.X 版本，就算是单机部署，对多个分区的数据更新仍然须要两阶段提交来保障其原子性；对于OceanBase 4.X 单机部署，对多分区的数据更新不再须要两阶段提交来保障其原子性。 接下来，咱们来体验下 OceanBase 4.X 版本的最小化单机部署。 上面是通过 OBD 部署的配置文件： 次要是以下几个参数memory_limit 设置为4G，这个是所有租户的总内存容量。system_memory 设置为1G，这个是500租户的内存容量。理论租户可应用内存是4G - 1G=3G。因为零碎租户默认内存为2G，所以最初预留给业务租户的内存只有1G。当然也能够缩小零碎租户内存容量为1G，不过不倡议这么做。 __min_full_resource_pool_memory 设置为1G，这样能力容许创立unit最小内存为1G，要不会报如下谬误：ERROR 1235 (0A000): unit MEMORY_SIZE less than __min_full_resource_pool_memory not supported cpu_count 设置为2。设置为2也够用了，零碎租户应用一个核，剩下的一个核给业务租户应用。 oceanbase-ce: servers: - name: ob1 ip: 127.0.0.1 global: syslog_level: WARN enable_syslog_recycle: true max_syslog_file_count: 1 __min_full_resource_pool_memory: 1073741824 memory_limit: 4G system_memory: 1G datafile_size: 20G log_disk_size: 24G devname: lo cpu_count: 2 production_mode: false cluster_id: 1 appname: obytt100 mysql_port: 2881 rpc_port: 2882 data_dir: /ob_data/1 redo_dir: /ob_log/1 home_path: /home/admin/oceanbase/1 zone: z1用以上配置文件来部署 OceanBase ，上面是我部署好的数据库：只有一台 OB SERVER ，能够当做单台 MySQL 实例一样来失常操作。 ...

作者：郭奥门 爱可生 DBLE 研发成员，负责分布式数据库中间件的新性能开发，答复社区/客户/外部提出的一般性问题。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 前言observer调试有三种⽅法：⽇志，gdb调试，vscode调试（实质上是gdb或lldb）。这里咱们关注如何借助vscode进行调试 调试版本 OB代码基线：开源版本，社区版，3.1.5 github：https://github.com/oceanbase/... commit id：99777b4bc94d2cfc6be8ae1dce624e46beefad08 调试形式采纳本地开发工具+近程gdb形式 本地指的是调试者的电脑（windows或mac） 近程指的是observer和gdb所在的linux服务器 所需工具：本地：vscode（所需插件：C/C++、CMake、CMake Tools、Remote - SSH、Remote Development） 近程：gdb 近程环境编译具体可参考：https://github.com/oceanbase/... yum install -y git wget rpm* cpio make glibc-devel glibc-headers binutils m4cd /opt && git clone https://github.com/oceanbase/oceanbase.gitcd oceanbase && git checkout 99777b4bc94d2cfc6be8ae1dce624e46beefad08curl http://mirrors.aliyun.com/oceanbase/OceanBase.repo## 批改编译选项## 正文掉 set(DEBUG_PREFIX "-fdebug-prefix-map=${CMAKE_SOURCE_DIR}=.")vi cmake/Env.cmake#工夫较长，能够先操作上面的步骤bash build.sh debug --init --make#实现后会在当前目录生成build_debug子目录，在build_debug/src/observer目录下会有一个observer二进制文件，此文件为observer的启动文件装置查看环境这里我的环境只须要调整以下配置，倡议依照官网文档检查一下本人的服务器：环境和配置查看-OceanBase 数据库-OceanBase文档核心-分布式数据库应用文档(https://www.oceanbase.com/doc...) vi /etc/security/limits.conf#追加root soft nofile 655350root hard nofile 655350* soft nofile 655350* hard nofile 655350* soft stack 20480* hard stack 20480* soft nproc 655360* hard nproc 655360* soft core unlimited* hard core unlimited#退出以后会话，从新登录。执行以下命令，查看配置是否失效：ulimit -a部署具体可参考：https://github.com/oceanbase/... ...

在《高性能数据拜访中间件 OBProxy（五）：一文讲透数据路由》中，咱们讲到了数据路由影响因素包含性能因素、性能因素和高可用因素。本文次要介绍高可用因素相干的内容。  相比传统的 IOE 架构，OceanBase 利用更低的老本实现了更高的可用性，为客户提供机器级别容灾、机房级别容灾和城市级别容灾个性，是 OceanBase 数据库的杀手锏之一，深受用户喜爱，因而，本文将对高可用个性开展具体的介绍。 从技术角度看，分布式系统的高可用波及的模块很多，每个模块都可能呈现故障，实现高可用个性是一件十分艰难的事件。即便艰难很多，OceanBase 数据库还是对外做了 RPO = 0、RTO < 30s 的承诺，这其中波及到的知识点很多，OBProxy 遇到的问题和 OBServer 也有很大不同，因为本文是 OBProxy 系列文章，所以次要从 OBProxy 的视角去介绍高可用的内容，但 OBServer 的高可用实现也十分精彩，大家也能够多多理解～   OBProxy 高可用的两个维度  理解 OBProxy 高可用个性的实现还得从高可用的概念讲起。“高可用性”（High Availability）通常指一个零碎通过专门的设计，从而缩小复工工夫，而放弃其服务的高度可用性。假如零碎能够始终提供服务，那么零碎的可用性是100%。如果零碎每运行100个工夫单位，会有1个工夫单位无奈提供服务，那么零碎的可用性是99%。 咱们都晓得，单点往往是零碎高可用最大的危险和敌人，应该尽量在零碎设计的过程中防止单点。从方法论而言，高可用保障的准则是“集群化”，或者叫“冗余”：只有一个单点，该单点挂了会使服务受影响；如果有冗余备份，挂了还有其余备份能顶上。为保证系统高可用，架构设计的外围准则是冗余，只有“冗余”还不够，故障每次呈现都须要人工染指复原肯定会减少零碎的不可服务实际。因而，咱们往往通过“主动故障转移”来实现零碎的高可用。 置信你曾经从上述内容中理解到 OBProxy 的高可用个性就蕴含两个维度：一是实现 OBProxy 服务高可用个性，产生故障后可及时复原 OBProxy 的服务；二是保障 OceanBase 数据库的高可用，如探测和辨认 OceanBase 数据库节点的故障并退出黑名单，通过正当路由对利用端屏蔽数据库故障，当数据库节点故障复原后及时洗白 OBServer 节点，充分利用每一台机器资源。 上面对这两个维度开展具体介绍。   维度一：OBProxy 服务高可用  OBProxy 服务的高可用是指 OBProxy 自身可能间断提供服务，升高故障对代理服务影响。但这会受以下三个因素影响。 因素1：部署 OBProxy 的机器是否失常，比方该机器是否能够和其余机器失常通信、机器是否产生了宕机。因素2：OBProxy 过程是否能够稳固运行并失常提供服务，以及过程被误杀后是否能够及时拉起。因素3：OBProxy 依赖的第三方模块如 OCP 和 OBServer 是否失常提供服务，比方 OCP 是否能够失常提供 HTTP 服务。  因素1：部署机器异样  《高性能数据拜访中间件 OBProxy（二）：装置部署最佳实际》中咱们介绍了 OBProxy 的常见部署形式，咱们将通过剖析利用端部署和独立部署（OBServer 端部署相似）两种状况下的机器故障介绍 OBProxy 服务高可用，当初咱们来回顾一下之前内容。 ...

本文选自 InfoQ《中国卓越技术团队访谈录》（2022 年第四季），此次采访，心愿可能将 OceanBase 具备创新性的技术演进历程展示在读者背后，让开发者和业内人士更加深刻理解与 OceanBase 数据库无关的所有。  根底软件是个须要漫长工夫积攒才有可能积淀出后果的畛域。作为三大根底软件之一的数据库技术，没有十年以上的深耕和积攒，很难在巨头林立的国内市场砸出水花。 我国数据库技术绝对于欧美国家起步较晚，大概始于七十年代中期。1977 年 11 月，由中国科技大学在黄山主办了第一次数据库技术研讨会，标记着中国数据库软件产业进入了技术跟踪期，其后经验了三十多年的倒退，中国数据库软件产业相继经验了强势垄断期、翻新发展期，最终进入了目前的产品成熟期。   OceanBase 六年演进历史  2009 年，淘宝发动了“双十一购物节”流动，使得刹时数据呈爆炸式增长，传统单机数据库很难应酬峰值时的海量数据，这也就有了 OceanBase 诞生的土壤。 2014 年，OceanBase 数据库的自研工作获得了肯定功效，研发团队将支付宝交易业务中 10% 的任务量迁徙到了 OceanBase 上，这是整个外围业务应用 OceanBase 迈出的第一步。对于业内来说，也是外围业务应用国产数据库的一个 0 的冲破。 2016 年，OceanBase 数据库公布了架构从新设计后的 1.0 版本，反对了分布式事务，晋升了高并发写业务中的扩大，同时实现了多租户架构，这个整体架构连续至今。同时，到 年“双 11”时，支付宝全副外围库的业务流量 100% 运行在 OceanBase 数据库上，包含交易、领取、会员和最重要的账务库。 至此，阿里巴巴实现了数据库自在。 2017 年，OceanBase 数据库开始试点内部业务，胜利利用于南京银行。 2018 年，OceanBase 数据库公布 2.0 版本，开始反对 Oracle 兼容模式。这一个性升高利用革新适配老本，在内部客户中疾速推广开来。 到了 2019 年，OceanBase 数据库 2.2 版本加入代表 OLTP 数据库最权威的 TPC-C 评测，以 6088 万 tpmC 的问题备受瞩目。随后，在 2020 年，又以 7.07 亿 tpmC 刷新纪录。OceanBase 数据库是第一个也是截止目前惟一一个上榜 TPC-C 的中国数据库产品。 ...

作者：操盛春 技术专家，任职于爱可生，专一钻研 MySQL、Ocean Base 源码。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 OceanBase 运行时会产生很多各种级别的日志，如果呈现了谬误，想要从数量繁多的谬误日志中定位到谬误起因，是件不太容易的事。 谬误日志是咱们定位谬误起因的次要路径，本文咱们就来聊聊怎么从 OceanBase 谬误日志中找到咱们想要的错误信息。 1. 日志文件OceanBase 日志分为 3 类： 选举模块日志：寄存选举模块产生的日志。总控服务（RootService）模块日志：寄存总控服务模块产生的日志。启动、运行日志：寄存除选举模块、总控服务模块之外的其它所有模块产生的日志。每类日志又蕴含 2 种日志文件： .log、.log.YYYYmmDDHHMMSS 文件中蕴含该类型所有级别的日志。.log.wf、.log.wf.YYYYmmDDHHMMSS 文件中蕴含该类型 WARN、USER_ERROR、ERROR 3个级别的日志（须要把系统配置 enable_syslog_wf 的值设置为 true）。每类日志都写入到对应的 .log(.log.wf) 文件中，写满 256M 之后，把 .log(.log.wf) 文件改名（加上 .YYYYmmDDHHMMSS 后缀），而后再创立新的 .log（.log.wf） 文件。通过 ls -l 查看 OceanBase 日志目录，能够看到相似如下的日志文件： -rw-r--r-- 1 admin admin 18688919 10月 9 02:08 election.log-rw-r--r-- 1 admin admin 4998884 10月 9 02:07 election.log.wf-rw-r--r-- 1 admin admin 75158675 10月 9 02:08 rootservice.log-rw-r--r-- 1 admin admin 268437081 10月 8 23:25 rootservice.log.20221008232523-rw-r--r-- 1 admin admin 61688030 10月 9 02:08 rootservice.log.wf-rw-r--r-- 1 admin admin 227610855 10月 8 23:25 rootservice.log.wf.20221008232523-rw-r--r-- 1 admin admin 156856561 10月 9 02:08 observer.log-rw-r--r-- 1 admin admin 268435919 10月 9 01:25 observer.log.20221009012502-rw-r--r-- 1 admin admin 91282191 10月 9 02:08 observer.log.wf-rw-r--r-- 1 admin admin 158605686 10月 9 01:25 observer.log.wf.202210090125022. 日志格局依照日志谬误级别不同，OceanBase 格局分为 2 种： ...

依据麦肯锡相干报告显示，2020 年寰球领取业支出 11 年来首次降落。黑天鹅事件让领取行为产生重大转变，现金使用量大幅降落，商务服务从线下疾速转移至线上，这些转变为领取参与者带来了新的机会与挑战。2021 年，领取业支出指标疾速修复反弹，其中，数字领取在面对危机时展示进去的敏捷性成为推动经济更快复苏的重要因素之一。如菲律宾电子钱包 GCash 在2022 年 Q1，注册用户数首次超过 6000 万，达到笼罩菲律宾 83% 成年人口的里程碑。 在此轮疾速修复与暴发增长中，企业间的竞争劣势之战也拉开帷幕。整个领取业开启二次改革，由多场景繁多服务向全场景数字化经营转变，数字领取从便当抉择变为根本服务，为数字化经济和产业互联网注入新的生机。 局部企业曾经通过基础设施降级、技术架构迭代和新技术的引入，通过科技翻新伎俩晋升了老本控制能力、进步了服务质量、优化了单位成本生产效益，持续扩充本身劣势和市场规模。 对于作者作者：周贵卿 OceanBase 解决方案架构师、分布式数据库布道者。领有近十年基于传统 Oracle 的开发教训，曾主导电信行业 BOSS 外围零碎技术架构，参加制订 IETF RFC8543 规范，翻译出版 O'Reily《ZooKeeper, Distributed Process Coordination》书籍，对分布式一致性协定有着深刻的钻研；曾就任 CNNIC，作为“互联网域名治理技术国家工程实验室”骨干，推动国家域名外围零碎分布式革新；前京东云 IaaS 架构师，主导多个行业解决方案的设计施行。是分布式技术的拥趸者和狂热者。 数字领取面临新挑战数字领取的技术架构通过多年的倒退，已从单体架构逐步倒退为微服务、单元化等分布式架构，但鲜有企业采纳原生分布式数据库，在最外围的数据底座上短少业务倒退的强有力撑持。 晚期数字领取的传统数据库架构大多采纳单机数据库，因为其简略易用，且强 ACID（Atomic 原子性，Consistency 一致性，Isolation 隔离性，Durability 持久性），帮忙领取企业疾速积攒了肯定市场规模。 随着业务增长，单机数据库的容量、性能很容易达到下限，利用架构开始降级为分布式架构。与此同时，基于中间件的分库分表计划应运而生，这种形式短期内无效解决数据激增、高并发等问题，但实质还是单机数据库的横向组合，与之也带来一系列其余的问题，制约了企业在新一轮增长期的倒退。 业务连续性难保障保障业务连续性是数字领取的重中之重，次要包含高可用、高容灾。高可用须要数据库在机房断电、网络异样、磁盘静默等故障，甚至是光纤断掉等极其状况下，依然能保证数据 0 失落，业务失常运行；高容灾则是指在地震、火灾、洪水等本地数据库遇到劫难时，备灾数据库能疾速承当起本地数据库工作的能力。 传统的单机数据库遇到故障后，业务可能长时间中断，甚至数据失落；即便能做到高可用、高容灾，也依赖于操作系统、存储硬件、数据库等多组件的整合分级实现，与业务本身利用的配合度低，切换要求高、难度大，不足以保障数字领取企业的业务连续性。 频繁分库分表效率低下数字领取企业的业务初期，数据量不大时，采纳单机数据库架构往往就能很好地失常运行。但当业务倒退到肯定规模时，随同数据量激增，要么抉择一直减少单机数据库；要么分库分表，分库分表也就意味着要做技术改造，这对整体架构设计能力的要求甚高，略微有设计不合理之处，都将可能使零碎的整体性能、可用性大打折扣。 此外，分库分表也就意味着要在肯定工夫内进行业务，对运维人员来说则是大量的数据清理、拆库拆表的繁琐工作。大量的数据库实例，也将导致运维的复杂度直线回升，造成整体运维效率低下。 存储老本日益昂扬毋庸置疑，随着多年的倒退和积攒，导致数据量的激增，数字领取企业的数据库老本会越来越高。 一是监管要求的热数据存储周期要求，以及监管审查的全量数据存储要求；二是业务增长导致一直减少的数据库的硬件老本；三是分库分表的多实例的资源利用率低，造成计算资源节约；四是累积的海量数据存储导致存储老本的回升。因而，数字领取企业的存储老本广泛高于其余对数据保留工夫要求较低的企业。 高并发时稳定性差随着挪动互联网的到来，海量高并发场景的背地都须要数字领取企业做稳固撑持，如直播带货抢购时、超低折扣商品秒杀时须要同时调用第三方领取的接口，保障用户的交易、领取等行为失常；如通过技术手段将银行、第三方领取等多种领取整合于一体的聚合领取，每天都面临着大量高并发的场景。 传统数据库架构须要依据业务倒退提前布局容量，不反对动静扩缩容，不具备突发流量的承载能力。面对短时间大量的领取、交易等 SQL 申请，如果每一条 SQL 都减少 1 毫秒的提早，用户将会有延时期待的不佳体验，数据库也很有可能间接宕机。 大数据分析过程漫长中国的数字领取无论在市场规模还是增长速度始终引领寰球领取市场，也基于一直的业务翻新，包含场景数字化经营转变。不论是第三方领取还是聚合领取，都有从面向 B 端商家进行大数据分析的场景，如商家查问近期交易的汇总数据、分润数据统计分析等；到面向 C 端的用户画像的精准营销场景，如领取收单与银行数据联动等。 因为传统架构通常将 OLTP 和 OLAP 分为两套数据库，当遇到须要大数据分析的场景时，往往须要将负责 OLTP 数据库的数据同步至 OLAP 数据库，再由 OLAP 数据库进行大数据分析，大多统计分析时效为 T+1，影响商业决策时效性，也制约了业务模式的翻新和倒退。 ...

近日，OceanBase CTO 杨传辉解读 HTAP 的文章《真正的 HTAP 对用户和开发者意味着什么？》介绍了 OceanBase 对 HTAP 的了解和技术思路，在读者中引发了宽泛探讨。 OceanBase 认为，真正的 HTAP 要求先有高性能的 OLTP，而后在 OLTP 的根底上反对实时剖析。OceanBase 通过原生分布式技术提供高性能的 OLTP 能力，真正通过“一个零碎”同时提供事务处理和数据实时剖析能力，“一份数据”用于不同的工作负载，从根本上保持数据的一致性并最大水平升高数据冗余，帮忙企业大幅升高总成本。 要让 OLTP 数据库具备 OLAP 的能力，尤其是大数据量 OLAP 的能力，除原生分布式架构、资源隔离，还须要给简单查问和大数据量查问找到最优解。高效执行的向量化引擎，就是解决这个问题的核心技术之一。 对于作者曲斌花名：鲁信 OceanBase 技术专家。数据库畛域多年教训，曾从事列式数据库，时序时空数据库内核开发。目前在 OceanBase SQL 执行引擎组，次要方向是向量化引擎开发，OceanBase TPC-H 攻坚我的项目组成员。 明天，咱们邀请了 OceanBase 技术专家曲斌为大家分享 OceanBase 对向量化引擎的观点，并具体介绍咱们利用向量化引擎的场景价值、设计思路与技术计划： *咱们为什么要做向量化引擎；向量化引擎有哪些技术价值和特点；OceanBase 向量化引擎的设计实现。* 为什么要做向量化引擎与 Oracle 和 SQL Server 等数据库系统相似，OceanBase 的用户场景除了 OLTP 类的简略查问， 还有报表剖析、业务决策等简单 OLAP 查问。很多用户心愿在实现在 OLTP 联机事务处理的同时，提供连贯查问、聚合剖析等 OLAP 剖析能力。而 OLAP 查问具备数据处理量大、计算查问简单、耗时高的特点，对数据库的 SQL 执行引擎的执行效率要求较高。 晚期咱们通过并行执行技术将数据平均摊派到分布式系统中多个 CPU 上，通过升高每个 CPU 解决的数据量实现查问响应工夫（RT）升高。随着用户数据量的一直增多， 在不减少计算资源的前提下，每个 CPU 计算数据的量也一直增大。咱们在客户现场发现，OLAP 场景下局部非凡状况的 CPU 利用率靠近 100%。这在聚合剖析、连贯查问等大数据量剖析查问中变得尤为显著。 ...

随同着云计算、大数据技术的倒退，传统信息技术及利用受到了微小冲击，数据库作为根底软件也迎来了新的挑战和时机。同样数据应用场景出现多元化趋势，数据规模也随之爆发式增长。海量异构数据的爆发式增长，对数据库的存储和计算能力提出了更高的要求。将来，传统的基于单物理服务器节点的数据库将在更多的场景下被分布式数据库取代，分布式数据库利用前景将越来越广。 《对话ACE》第四期流动便围绕“分布式数据库将来倒退的挑战和时机”为背景，邀请到极数云舟创始人&CEO、Oracle ACE Director 周彦伟，OceanBase 产品和解决方案部高级总监王南独特摸索“分布式数据库将来倒退”，以此推动分布式数据库技术更好的倒退。 以下为对话实录：OceanBase产品和解决方案部高级总监 王南Q：OceanBase 齐全自研的国产分布式数据库，在设计之初，会有哪些难点？对于 OceanBase 而言，并非从设计之初就思考到要解决更长期阶段的问题和难点。这其中有一个决策和立项的过程，包含可能解决什么问题，产生什么样的价值，须要多大的投入，须要多长的工夫和代价能力解决这样的问题。晚期是基于场景和问题去逐渐解决的，间接的分阶段实现整个认知过程。 第一个阶段源于淘宝的场景，解决的是外围数据规模和数据量，包含数据拜访的吞吐在一直增长的状况下可能应答业务增长。第一步解决的还是分布式的问题，是没有关系模型的一个分布式的 NoSQL。随着淘宝场景的问题解决后，更多的业务场景同样存在扩展性的诉求。很多场景本就是基于关系型数据库去做撑持的，对于数据库的诉求，局部业务是能够通过应用层革新来解决，但大量的业务如果要走向通用场景的话，关系模型还是一个很必要的诉求。 第二个阶段在解决分布式的问题后，逐步实现关系模型，反对SQL能力。随着 OceanBase 从蚂蚁和支付宝外部开始走向通用市场，能够看到很多业务场景既有基于 MySQL 开源生态的，也有基于 Oracle 商业生态的，所以利用如何可能迁徙到新的分布式数据库上来？其实有一个很大的问题。 第三个阶段就是能做到很好的兼容，对于用户来讲，在应用层包含迁徙过程中的老本和代价是什么样的，OceanBase 在解决了 MySQL 兼容性后又实现了 Oracle 的全面兼容，包含语法、语义和存储过程等等。 再之后会遇到关键问题和挑战就是随着数据量的增长达到肯定规模后，对于 AP 的能力的诉求还是比拟强的。HTAP 的能力在以后阶段，是一个要害的难点和技术挑战。同样随着云计算的倒退，对于云基础设施甚至跨云异构云的反对，也会有很多客户的诉求。 所以在设计之初包含倒退过程中的技术难点，其实是在反对和服务客户的过程中逐渐去发现的。 Q ：在银行、保险等金融场景很多企业曾经抉择分布式数据库作为外围首选，那么将来在哪些场景内还会存在相似的状况？之前 OceanBase 在金融场景利用会更多一点，近两年工夫除了金融之外，咱们曾经在通用市场的很多企业外面开始利用了。这个问题有比拟多的影响因素，明天我次要从产品和技术这个视角来去探讨和分享一下。 在目前曾经大量利用的分布式数据库的外围场景来看，他们抉择散布数据库。其实有几大类的起因，大家都是基于几大类的这种不同的诉求和思考来去抉择的。 第一，有外围零碎迁徙需要的用户。这些用户往往不是从业务诉求驱动，因为这种场景下，用户抉择一个什么样的架构，是集中式还是分布式，不是特地强的一个强束缚，而是更关怀在 Oracle 的兼容、切换和代替过程中，是否可能高性价比的平滑迁徙。 第二，解决连续性问题的用户。对于数据库的供给、购买、包含数据库服务能力等面临越来越多的这种挑战，所以连续性可能也是重要起因之一。 第三，有真正业务诉求的用户。因为抉择的实质最初还是要回到商业，或者回到市场，来抉择一个产品到底是不是经济、划算、正确。从这个视角来看，无论是客户业务量的迅速增长，而后导致的对于数据库或者数据管理这一层扩容、扩大的诉求，还是因为数据量的过大，集中式的架构没有方法承当将来业务诉求和数据量。这类用户其实他的诉求是更刚需的，也是更迫切的，也是可能触动和驱动用户真正下决心去做技术升级革新的很外围的因素。 这个过程外面，用户关怀的关键因素除了数据库本身能力，包含性能、性能、规格、平安这些能力是否满足之外，还有一个比拟大的因素就是利用迁徙的老本和代价。数据库作为根底软件和利用有很大的差别，替换时对于比较复杂的各种业务零碎，影响和代价比拟大。 所以说对于什么场景会抉择分布式和什么场景会抉择一个新数据库，其实是两个概念。对于抉择数据库，大家更多地思考数据的安全性和规格是不是能满足。然而对于是否抉择分布式，这外面须要有一些外围诉求的：要么是原有的繁多金融零碎没有方法可能满足诉求；要么是我为将来做一些技术上的降级和储备。最终将来可能还会有哪些场景会抉择散布数据库，还是要回到真正这个市场抉择自身这个话题上来。 Q ：对于分布式数据库产品的运维或者大规模智能化运维，有什么好倡议？其实一个产品，它的利用规模越大，其诉求、挑战会更高。因为产品没有被规模利用的时候，无论他怎么去做，哪怕是人肉撑持，也可能把运维很好的撑持起来。然而一旦放量之后，这个运维就是很大的挑战，特地是数据库产品，它和一般的利用有很大的差别，在运行时会影响到各种因素的影响。比方软硬件故障，这也是为什么有 DBA 这样一个业余方向的群体来去专门做这个数据库的运维。传统数据库通过几十年的倒退，曾经造成比拟成熟的 DBA 群体，除此外，散布数据库绝对于集中数据库来讲，其实还是有不同的挑战的。 首先是技术架构，它自身就带来了更高的复杂度，绝对于集中式数据库来讲，分布式对于高可用故障复原以及执行打算的各种调优，它会有更高的对于能力上的诉求。对于一个新的产品和架构，要去学习了解，再造成广泛的认知，还有应用它的熟练度，其实须要很长的过程。这个可能不是说针对某一个数据库，而是因为分布式的架构和技术特点决定了会有这样的一个过程，而且其实咱们在运维的问题下面，也有几个层面在实际和摸索。 第一个层面是产品能力。除了数据库的内核之外，要真正把一个产品用起来须要思考产品化配套相干的各种工具，整个集群治理运维监控、全链路的诊断，还有主动的优化器、性能调优、自助运维，所以用工具去解决这个问题十分要害。当然这外面必定是须要 DBA 和人去造就这样的能力，然而如果你有比拟好的工具或者比拟残缺的工具能力做撑持，有比拟好的技术去提供这种撑持和查问，其实是很大的一个帮忙。所以从产品能力上来讲，咱们要去构建这样的一些能力撑持和底座。 第二个层面是整个用户层面的认知，包含运维人员体系的造就。OceanBase 当初正在通过开源去造就一些用户，咱们也倡议大家都用起来，晓得数据库有什么特色，会遇到什么问题。更多人去用，在运维上更多人才会去了解它、用它。同时加入一些培训认证，像OceanBase 当初的 OBCA/OBCP/OBCE，针对不同的人群，不同的特点去打造全认证体系，让更多人可能疾速学习、应用和理解的这个分布式数据库。这不单单针对 OceanBase，而是想要对于整个分布式数据库的运维、调优去造就这样一些人才根底。 第三个层面是咱们在市场化和交付的过程中，缓缓领会和了解到整个数据库的运维问题。这点只靠咱们本人远远不够，像 Oracle 这么成熟的一个产品和公司，它的运维也是靠大量的第三方业余服务公司以及 DBA 群体一起去搞定的。对于分布式数据库来讲，OceanBase 属于一家守业公司，当初规模不大，后续一旦规模利用到更多行业和用户场景，仅靠原厂去反对服务很难。所以对于数据库运维，我认为要把第三方的各种业余服务公司、生态、包含 DBA 的能力都综合利用起来。 除此外大家也会有一些摸索。像资质能力、包含 AI 也是将来咱们的一个摸索框架。我认为在目前这个阶段，刚刚提到的三个层面是咱们重点要去发力和投入关注的。 ...

自治数据库旨在齐全自动化数据库部署中的配置和运维工作，例如建设索引和进行参数调优。实现自治数据库的要害是建设可能预测各种优化工作的开销和收益的行为模型。但数据库的零碎复杂度、并发操作、以及训练数据的获取代价使得建模具备挑战性。 基于此，明天为大家带来 OceanBase Paper Time 第二期文字版分享回顾，由卡耐基梅隆大学博士后马林分享《为自治数据库建设行为模型》，原论文名为“MB2: Decomposed Behavior Modeling for Self-Driving Database Management Systems”。为大家介绍一种合成式的建模框架解决上述难点，并利用所建模型精确预测不同优化工作的开销和收益，欢送大家一起学习探讨分享。 以下为直播实录：大家好，我是马林，当初 CMU 博士后在读，明天我跟大家分享的论文为“MB2: Decomposed Behavior Modeling for Self-Driving Database Management Systems”，是 2021 SIGMOD 上发表的论文。 MB2 是一个合成式的自治数据库建设行为模型的框架。在当初互联网时代，各种资源、数据十分多的状况下，人们通常会用数据管理系统去控制数据的存储和拜访。但随着数据的爆发式增长，数据管理自身也变得越来越简单，尤其随同数据量级和数据多样性的增长，这些零碎自身须要有很多的设置工作。 咱们通常须要 DBA 去治理数据库系统部署中的各种工作，比如说数据管理员须要设置各种各样的索引（一种减速局部数据拜访的一种数据结构）；或者数据管理员要设置数据库各种各样的参数，比如说进行日志治理的距离等；尤其是云时代，数据库管理员要去设置数据库资源的大小，有多少 CPU，多少 Memory，多少 IO 等等。这就导致企业须要破费很大老本去雇佣数据库管理员，对于很多大公司或者云数据库的服务商，可能要治理几千个、几十万个数据库，如果每一个数据库都要调配一个数据库管理员的话，就很不事实。 供＜求，驱动数据管理思维变更当今时代曾经对数据驱动、数据密集型利用的部署造成了很多挑战，目前也有很多的解决办法。在数据库行业倒退的很多年里，各个厂商、研究员开发了很多帮忙数据管理的工具。但在工具应用的场景中，还须要借助很多人为的力量去应用这些工具。比方一个数据管理员想设置数据库的索引，或者设置一些参数。他先要筹备一个具备代表性的数据库负载(workload)，同时还要筹备一些空余的硬件，而后再在硬件下来复制一些数据库的内容。要在空余的硬件上和筹备好的 workload 上，去运行数据库调优、或者是举荐索引的工具。拿到这些举荐之后，在各种各样举荐的索引当中抉择一个比拟好的或者最优的索引，最初决定什么工夫更改，这都须要人为的更改。通常这些更改都须要在数据库负载比拟低的时候，比方凌晨三四点，对于数据库管理人员来说，这种流程很是苦楚。 之前这些大部分管理工具都是关注在数据库的某一个方面。比如说有的工具关注索引，有的工具关注怎么和用户协同，不同的数据放到不同的分区，而后很多工具进行参数的调整。很多工具要一遍一遍的反复这个过程，不同的工具都要用一遍是十分繁琐的过程。正因而，我明天为大家带来一种新思路。 我在另一篇论文中对数据库的自主帮忙治理、主动部署的等级进行了辨别(Make Your Database System Dream of Electric Sheep: Towards Self-Driving Operation, VLDB 2021)。 最低级，所有的数据都须要数据管理员本人用。有一些不同的厂商，会在两头档次帮忙数据库进行自我管理的工具，比如说去管制某一个小的局部。然而咱们在这里的我的项目就是心愿达到最高等级——主动驾驶（self-driving）或者是自治的级别。意思是数据库能够齐全主动治理不同的方面，包含索引、参数等等，通过一个对立的要害框架去治理，这个自治数据库不仅仅是给 DBA 去进行一些举荐，而且能预知之后的事件，就比如说数据库的负载是什么？怎么去进行数据库的主动调优、扭转安顿，并且齐全能够主动的进行，不须要人为干涉，这是咱们要达到的指标。 简略定义下自治数据库：自治数据库是一个能够齐全可能设置调优并且优化零碎的各个方面，也不须要任何人为干涉的数据库。 具体来说就是它能够主动优化任何跟数据库性能相干的方面。比如说 physical design(索引)，或者冷热拆散、调参数、资源配置。然而有一些设置还是须要人去进行价值判断，比如说数据库的哪一个表，或者哪一列，什么人会有权限去操作，数据库的自身依然不能确定。 为什么在这个时代有可能做自治数据库？有几方面起因。 首先，在数据驱动的时代，不光是数据库自身能够存储很多客户的数据，同时数据库能够去对数据库自身的运行状态，去记录很多的指标、参数、运行状态的历史记录，还有数据库自身的运行状态。咱们也能够尝试去挖掘反对、帮忙数据库进行主动优化。第二，咱们这里有很多更好的硬件，能够存储更多这样的数据，也能够更疾速地解决这些数据，并且实现数据库的主动优化。最初，当初这个时代有很多不便的人工智能、机器学习方面的库和工具，来帮忙咱们去部署这些主动调节的算法。 自治数据库的挑战听起来有很多的机会、趋势去帮忙咱们实现这个工作，甚至感觉将一个现成的人工智能算法往数据库的零碎上一套，就能实现齐全的“主动驾驶”，但在事实当中还是有一些挑战。 第一，数据库自身是一个非常复杂的零碎，如果你想要一个对立的框架去齐全的去管制数据库各个方面复杂度很高。 第二，在数据库当中的很多操作，比如说想应用机器学习这些算法去训练模型、去管制智能化的数据库，须要数据去训练这些模型，然而数据库当中的很多操作，它其实是要花很多工夫的，获取这些模型的训练数据也要花很多工夫。比如说建一个索引，如果这个表上有几十亿个行，建一个可能就要好几个小时，好几天。 第三，你在实验室或者开发环境当中训练了一些模型，而后去部署这个智能数据库。但模型不是百分之百精确的，很难保障在这个开发环境当中训练的这些模型，在部署当中还能有好的成果。 ...

2022 年 8 月 10 日，OceanBase 将在北京、上海、深圳，以“三地分布式大会”的模式举办「2022 年 OceanBase 年度发布会」。OceanBase 4.0 行将重磅公布，咱们邀您一起见证 OceanBase 的产品冲破与翻新，分享 OceanBase 的策略思考和倒退方向，探讨分布式数据库前沿的技术趋势，感触全新的 OceanBase！ 想来参加这场分布式数据库顶尖科技头脑风暴吗？想同业内翻新人才一起见证分布式数据库大会的精彩吗？快扫描海报二维码报名吧！ 为了回馈宽广粉丝，小编特意申请了 50 个线下收费参会名额，邀您现场观看泛滥数据库行业专家的精彩分享。 50 个收费席位还有神秘礼品等您哦“small is new big ”！ 8 月 10 日，咱们不见不散！  2022 OceanBase 年度发布会

系列文章导读OceanBase 是100% 自主研发，间断9年稳固撑持双11，翻新推出“三地五核心”城市级容灾新规范，是寰球惟一在 TPC-C 和 TPC-H 测试上都刷新了世界纪录的国产原生分布式数据库，于 2021 年 6 月份正式凋谢源代码。查问优化器是关系数据库系统的外围模块，是数据库内核开发的重点和难点，也是掂量整个数据库系统成熟度的“试金石”。为了帮忙大家更好地了解 OceanBase 查问优化器，咱们将撰写查问改写系列文章，带大家更好地把握查问改写的精华，相熟简单 SQL 的等价性，写出高效的 SQL。本文是 OceanBase 改写系列第六篇，将重点介绍谓词推导，欢送探讨～ 专栏作者介绍OceanBase 优化器团队，由 OceanBase 高级技术专家溪峰、技术专家山文等领衔，致力于打造寰球当先的分布式查问优化器。 系列内容形成本次查问改写系列不仅包含子查问优化、聚合函数优化、 窗口函数优化、 简单表达式优化四大模块，本文将会针对谓词的推导形式进行具体论述，还有更多模块内容，敬请期待。 欢送关注 OceanBase 开源用户群 （钉钉号：33254054），进群与 OceanBase 查问优化器团队一起交换。 一、为什么须要谓词推导业务在拜访数据库时通常只会读取局部数据，因而会指定一些谓词来过滤掉不须要的数据。实现一个查问语义时，咱们能够采纳多种不同的谓词组合。 例如：Q1 和 Q2 都是从数据库中读取编号为 1024 排片的余票信息。这两条查问应用了不同的谓词汇合，实现了雷同的查问成果。从查问的性能而言，Q2 的过滤谓词写的更好。Q2 中的 T.play_id = 1024 是一个基表过滤谓词。它能够提前过滤掉一批数据，缩小参加连贯的数据量。进一步的，当 TICKETS 表上存在 (play_id, sale_date, seat) 的索引时，查问优化器一方面能够确定出一个十分好的数据扫描范畴；另一方面还能够利用索引序打消 ORDER BY 产生的排序操作。最终，整个查问最多只须要读取 T 表的 10 行数据。 Q1:SELECT P.show_time, T.ticket_id, T.seatFROM PLAY P, TICKETS TWHERE P.play_id = T.play_id AND P.play_id = 1024 AND T.sale_date is NULLORDER BY T.seat LIMIT 10;Q2:SELECT P.show_time, T.ticket_id, T.seatFROM PLAY P, TICKETS TWHERE T.play_id = 1024 and P.play_id = 1024 AND T.sale_date is NULLORDER BY T.seat LIMIT 10;为了保障良好的查问性能，数据库内核须要有能力为 Q1 来查问推导出 T.play_id = 1024 这样的谓词。这种能力咱们称之为“谓词推导”。在 OceanBase 中，咱们针对不同的谓词应用场景，设计和实现了多种谓词推导的策略。下文将次要介绍这些推导策略。 ...

近些年，数据库在技术畛域已倒退成熟，诸多类别趋于细分，焕发新的生机。泛滥新生数据库诞生并以迅猛之势关上市场，同时很多数据库也以开源凋谢的模式布局国内外市场。 对于全新阶段的数据库时代，一些新型数据库对 DBA 在产品学习和业务场景体验上面临新的挑战，到底将来该如何选型新数据库产品，DBA 的倒退该如何抉择？ 《对话 ACE》第二期流动便以“新数据库时代，DBA 倒退之路该如何抉择”为背景，邀请到 OceanBase 解决方案部总经理师文汇，dbaplus 社群联结发起人、竞技世界资深 DBA、Oracle ACE 杨建荣，独特摸索“DBA 将来倒退之路”。以此推动国产数据库技术、人才及生态建设的倒退。（* 戳下方视频看残缺精彩回放~ ） 直播干货满满没工夫看视频没关系！小编对直播的内容也进行了汇总分享欢送大家浏览、珍藏！ Q:您认为 DBA 更应该参加哪方面的工作（比方内核开发，调优，交付等）？ A师文汇：大略分几个群体。对于刚毕业的学生，激励大家多做内核或者技术相干的开发工作，会有好的技术积淀。数据库其实是处在整个业务的最外围的环节，既能做深层次技术的积攒，也能够将技术和业务更好地联合。无论学习内核，还是学习业务，对 DBA 都是有十分大的帮忙和成长。 对于一些资深的 DBA，倡议大家多理解行业或业务知识。比如说金融、运营商畛域，如何应用数据库，在业务场景下的外围痛点。对于 DBA 的倒退，能够去做对外的商业化解决方案类，也能够架构师方面的工作。 数据库开发方向，后期能够理解一些常见的开源数据库，比方 OceanBase，其实是很好地学习数据库的动手我的项目。能够基于其社区版做一些凋谢的 project，通过这样一些实际，疾速的进入到社区一起交流学习。 对于传统数据库的开发者，例如 MySQL 或者 PostgreSQL，如果投入到 OceanBase 分布式的学习，人造是有很多劣势，比方在事务上的了解。OceanBase 是一个分布式关系数据库，通过学习，在分布式、一致性协定等畛域，是可能帮忙大家疾速成长去实现自我晋升的。大家如果违心入手花工夫去学习和实际，比方简略的一些代码批改和编译，通过这些实际，会有新的播种。 Q:大家都在谈内卷和躺平，对于这两方面，是否给 DBA 们一些倡议？ A师文汇：我同时也在负责蚂蚁数据库和存储团队，我感觉一方面从业务角度看，很多事件能够去做甚至能够做到更好。比如说单 TB 存储老本，每天在蚂蚁都有上千 G 的这种业务须要公布，咱们如何能做到效率更高。当你去认真学习业务或者去了解零碎的时候，总是能发现还有很多问题能够去欠缺。 什么是内卷，以前大家常常说，做事件要去突破边界，互相补位，其实从这个角度去做事件，就是真正的为了一个独特的指标，在大家都能承受的正当空间，去做一些跨畛域或者跨边界的事件。这样的话可能对本人包含最终的业务后果都有很大的帮忙。 另一个方面，对于本身成长来说，我感觉是不能躺平的。大家能够看到，整个社会和业务倒退有多迅速。在 2014 年的时候，没有这么多的分布式数据库和国产数据库，然而在过来的几年里，不光从数据库，TP 或 AP，包含计算、算法，AI 畛域，其实都涌现了很多新的技术和产品。这个时代其实在用很快的速度后退，咱们必须保障本人的成长和竞争力。 Q:面对不同类型的 DBA 倒退方向（参谋、技术支持、运维）将来如何正确抉择？ A师文汇：我感觉 DBA 是一个十分有竞争力的职业或者角色。我意识的很多 DBA 都去做守业了，而且倒退都很好。那么这些人是如何倒退的这么好？因为他十分懂业务和数据库，面向最终的用户，理解用户的明确需要。所以可能去帮忙用户做一些设计，积淀，行为，想法。还有的 DBA 抉择去做商业化解决方案或者交付，同样能够做的很好，因为他们能够帮助业务把解决方案帮忙到例如传统银行外围零碎的迁徙的我的项目上。 对于 DBA 这个角色，上游是根底技术，上游是业务，两头是数据。所以这个角色其实是有能力成为任何一个类型的人才。当你把根底技术做扎实积攒后，在职业上的抉择是十分多的。DBA 想成长应该做什么，学习业务和技术，又要懂数据。最终的倒退方向取决于本人想去做什么，而后做好这些方向的积攒。 Q:国产数据库的迅猛发展，产品泛滥，对于 DBA，应该如何抉择才有利于集体职业倒退？ A杨建荣：国产数据库其实在行业内会打一些标签，目前有几个类别。 ...

自从证监会公布《客户交易结算资金治理方法》以来，券商的次要经营方式由网点营业部模式变动为总部集中模式，在集中交易系统的建设背景下，关系型数据库的重要性更加突出，以 Oracle、DB2 为代表的数据库产品简直占据了整个券商的各类外围业务零碎。 证券基金行业的外围零碎整体上可分为两类，一类是以股票交易为核心的在线类业务，另一类是以基金/资管为核心的“T + 1”业务。对于数据库而言，前者强调极致的低提早与高可用；后者则通常波及批处理、大事务、简单查问、备份复原，对数据库的综合能力有较高要求。 本文重点形容近年来在基金/资管场景下，OceanBase 整体解决方案与落地实际。 基金资管的业务架构与数据库实际 业务模型 典型的资管场景业务架构如下： 对客查问零碎：终端用户通过券商/基金的直销渠道或互联网分销渠道执行买入、卖出、查问等申请； TA 注销过户零碎：注销用户交易申请，在每笔交易链路中，依据资产估值计算用户的理论买入份额与卖出金额；在用户与交易两个维度进行批处理； 估值零碎：计算资产的净值、利息收入，资产维度批处理； 投资交易系统：交易外围账务解决；高并发低提早，满足 ACID； 投资剖析零碎：统计分析，包含大量大事务，简单查问。 容灾要求 机房切换演练：在线类交易业务对业务连续性有较高的要求，以银行外围做比照，产生劫难时，银行账务外围需优先保 RPO，确保数据统一，在此前提下，能承受肯定工夫的零碎不可用；而证券外围交易系统须要优先确保业务可用，其交易期间的零碎不可用损失往往以秒为单位计算。因而证券行业须要定期做各类高可用切换演练。 疾速数据恢复：T+1 类交易业务则对数据一致性有较高要求，一旦跑批呈现谬误，须要将数据恢复到某个工夫点进行重跑，同时须要在跑批工夫窗口实现批量工作，因而一方面须要跑批稳固，尽量不出错，一旦出错还须要数据能牢靠且疾速地实现工夫点复原。 针对业务模型的数据库计划实际 对客查问零碎：在自有销售渠道预期增长的背景下，为了撑持将来高并发场景，局部头部企业开始专库专用，将对客查问模块从数仓平台中抽出，独自运行在分布式关系型数据库。 资管零碎的对客查问模块，尽管 SQL 根本都带有“用户 ID ”这类信息作为等值条件，但其 SQL 往往不是简略的点查，而是带有去重排序等各类计算以及多表 join 的中等简单 SQL。在此状况下，OceanBase 的分区表+TableGroup+复制表可尽量将 join 中的雷同数据放在同一个节点，缩小分布式系统下带来的跨机 RPC 申请，同时 OceanBase 的一体化设计能尽量避免计算过程中的数据 merge。综合多方面个性，OceanBase 在此类场景下可能提供高并发低提早的查问能力。 对于写入负载，若数据来源于数仓平台，倡议在数仓平台实现数据进行荡涤后再导入；若抉择间接在对客查问零碎进行数据荡涤，则倡议管制事务尺寸，尽量避免一条 SQL 解决一整段工夫的数据（如一个月），只管 OceanBase 3.X 曾经反对大事务，但为了放弃零碎继续久远运行的健壮性，倡议固定事务尺寸，否则随业务增长，按工夫维度的事务大小也将持续增长，在达到临界点后，还是须要回头调整业务逻辑。 TA 注销过户零碎：引入分布式数据库并且借助其可扩展性，可在放弃业务架构不变的状况下，较好应答将来基金用户数、交易数大幅晋升的需要。 该零碎波及用户记录与交易记录两个维度，同时局部清理必须以串行形式实现，因而架构上较好计划是单元化，行将业务拆分为若干个可能独立实现要害业务流程的数据单元，单元之间防止 DB 间的交互，将不同业务单元以租户或用户维度进行部署，并将其主节点置于不同主机，从而晋升整体批处理效率并且保障硬件资源利用率。 在每个单元内，须要确保其数据绝对平均并且执行效率相当，因为零碎整体的解决工夫实质上就是最初一个单元实现清理的工夫，这须要数据库具备良好的租户资源隔离能力。 绝对于分片单元而言的是汇聚单元，汇聚单元内有所有的数据，负责承载全局剖析类负载，这须要数据库具备良好的 AP/TP 负载隔离能力。 估值零碎：该零碎只波及资金维度，其批处理逻辑较为简单，通过热点大表分区 +TableGroup，可将负载均匀分布到各个节点，达到较高的性能成果，以后 Oracle 生产环境运行在一套高配 Oracle 数据库中，跑批工夫在小时级别，高峰期 CPU 达到满负荷，OceanBase 采纳了比生产多一倍的数据进行跑批压测，在国产芯片的 2-2-2 集群环境中，可在 6 分钟内实现。 ...

来做 OceanBase 社区版 3.1.2 全面测试和点评吧，手把手帮你调优，助你上线，让性能极速，快到飞起。2022 年 1 月 6 日， OceanBase 社区版 3.1.2 正式公布。新版本进一步优化内核、晋升电商场景性能、减速晋升生态适配、推出社区版工具体系，在夯实可用性的同时大幅晋升易用性。 在此，特邀请社区小伙伴参加新版本性能测试体验流动，测试范畴不设限度，欢送大家体验和倡议。 OceanBase 社区版 3.1.2版下载地址，曾经在应用OceanBase的同学能够点击查看版本升级操作（OBD cluster upgrade）。在测试过程中有任何技术问题，咱们会有技术专家进行领导，帮助一对一做性能优化，为有需要的企业做技术支持，帮助顺利上线。 《可用性和易用性双重飞跃 | OceanBase社区版3.1.2正式公布》，咱们为您筹备了性能测试、最新公布的社区版工具 OCP、ODC、OMS，以及部署和测试工具 OBD 的相干文档，心愿能够为您的测试提供帮忙和参考。点我查看《OceanBase 社区版 3.12 测试流动参考宝典》如果您曾经足够相熟 OceanBase 社区，能够主动跳过。 参加形式提交性能体验报告OceanBase 社区最新版3.1.2版本公布已有些时日了，你有哪些爽点或者槽点，都能够通知咱们。欢送大家聊聊感触和倡议，包含但不限于：现有文档优化倡议、期待的新内容、产品优化意见、社区应用反馈等。 如果不晓得从何说起，能够参考内容倡议，点我查看《体验报告内容倡议》，当然咱们更欢送文思如泉涌，下笔如有神，欢送自由发挥，畅所欲言。每篇体报告将取得 100 积分和 OceanBase 社区精美周边礼品。 如果你想挑战更硬核、更 hard 的模式，在下一个社区版里看到你的名字： 能够在体验报告的根底上提交性能测试报告，点击查看《测试报告参考模板》 另外，如果在应用、测试OceanBasen时，如果发现文档或代码 bug，欢迎您提交。咱们会依据 bug 的数量和品质进行加分，并在下个版本的 release note 中向您致谢。 无论是提交测试报告，还是 bug，咱们都会依据您的内容予以额定加分。每周会在问答区颁布本周积分排名榜及问答区人气排行榜。 流动工夫：2022 年 3 月 1 日- 4 月 15日 报名形式：一、点击注销报名，如果你须要一对一的技术支持，请注销。 二、在社区官网-问答区-【社区活动与用户】板块公布性能体验报告。点这里提交体验/测试报告 另，可扫码退出社区钉钉群（群号：33254054），不便前期体验、测试时技术交换。 流动流程装置部署 OceanBase 社区版试用、体验 -> 在问答区提交体验报告 -> 关注问答贴热度及排名-> （可选）参加hard 模式：提交测试报告，或提交 bug -> 取得积分及礼品 ...

一、参考链接阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 oceanbase镜像-oceanbase下载地址-oceanbase装置教程-阿里巴巴开源镜像站 OceanBase 社区版 obdeploy: A deployer and package manager for OceanBase open-source software 二、OceanBase介绍OceanBase是由蚂蚁团体齐全自主研发的金融级分布式关系数据库，始创于2010年。OceanBase具备数据强统一、高可用、高性能、在线扩大、高度兼容SQL规范和支流关系数据库、低成本等特点。 OceanBase 社区版是一款开源分布式 HTAP（Hybrid Transactional/Analytical Processing）数据库管理系统，具备原生分布式架构，反对金融级高可用、通明程度扩大、分布式事务、多租户和语法兼容等企业级个性。OceanBase 内核通过大规模商用场景的考验，已服务泛滥行业客户，现面向未来继续构建内核技术竞争力。 三、OceanBase安装操作本试验基于CentOS 7.9零碎进行演示操作[root@oceanbase ~]# cat /etc/redhat-releaseCentOS Linux release 7.9.2009 (Core)装置后期筹备本试验采纳<font color=red>单机模式</font> 的部署形式，在同一台机器上装置服务端和客户端进行测试。 须要内存大小<font color=red>8GB </font>以上；（本试验内存大小 10 GB） 磁盘空间大小<font color=red>65GB</font>以上；（本试验磁盘大小 95 GB） 参考链接 【PostgreSQL】基于CentOS零碎装置PostgreSQL数据库_xyb的博客-CSDN博客 OceanBase 社区版 1、通过 YUM 软件源下载并装置 OBD执行以下三种命令。 # yum install -y yum-utils# yum-config-manager --add-repo https://mirrors.aliyun.com/oceanbase/OceanBase.repo# yum install -y ob-deploy[root@obd ~]# yum install -y yum-utilsLoaded plugins: fastestmirrorLoading mirror speeds from cached hostfilePackage yum-utils-1.1.31-54.el7_8.noarch already installed and latest versionNothing to do[root@obd ~]# yum-config-manager --add-repo https://mirrors.aliyun.com/oceanbase/OceanBase.repoLoaded plugins: fastestmirroradding repo from: https://mirrors.aliyun.com/oceanbase/OceanBase.repograbbing file https://mirrors.aliyun.com/oceanbase/OceanBase.repo to /etc/yum.repos.d/OceanBase.reporepo saved to /etc/yum.repos.d/OceanBase.repo[root@obd ~]# yum install -y ob-deployLoaded plugins: fastestmirrorLoading mirror speeds from cached hostfilePackage ob-deploy-1.2.1-9.el7.x86_64 already installed and latest versionNothing to do[root@obd ~]#或者 ...

历经近12个小时酣畅淋漓的在线直播，DC 2021分布式数据库开发者大会于1月6日早晨21:00圆满结束。本次大会以“数聚将来”为主题，由中国电子技术标准化研究院领导、CSDN主办、OceanBase承办，木兰开源社区、开源中国、51CTO、思否、极客邦科技、稀土掘金协办。 大会由中国电子技术标准化研究院研究室主任杨丽蕴女士收场致辞，并特地邀请了MySQL之父、MariaDB 创始人 Michael“Monty”Widenius 与 PostgreSQL 寰球开发组联结创始人 Bruce Momjian 带来深度的行业解析。同时 OceanBase 创始人阳振坤、CEO杨冰、CTO 杨传辉、巨杉首席架构师 & 研发副总裁陈元熹、PingCAP 公司副总裁刘松，以及腾讯分布式数据库 TDSQL 首席架构师李海翔、华为云数据库首席架构师冯柯等多位重磅嘉宾也都光临直播间，为开发者们奉献了一场分布式数据库畛域的技术“盛宴”。 大会干货之多，嘉宾之丰盛能够称得上是 2022 头一份了，为了更好的让读者们理解本次开发者大会的精彩，小编特意从这场大会里精选出8个关键词和大家分享。 分布式-Key Word 1中国电子技术标准化研究院研究室主任杨丽蕴：我国互联网等新利用场景的疾速倒退背景下，具备大规模横向扩大能力的分布式数据库随之成长起来，且并不落后于寰球的当先产品。分布式、云数据库等新一代数据库类型，没有传统数据库存量市场的旧有包袱，因而近年来在国内如雨后春笋般涌现。在近年国家科技倒退之下，分布式数据库在互联网大规模场景下疾速倒退之后，正走向更广大的市场，例如金融、通信、政务、物联网等企业级利用场景，都有分布式数据库承当翻新业务的身影，并在逐渐进入外围零碎畛域。 主观上，与传统集中式数据库相比，分布式数据库在产品成熟度和技术遍及度上还存在差距。所以分布式数据库在疾速倒退同时，也在一直应答挑战，打磨产品。我置信，在国家科技倒退策略下，以及云计算和 AI 智能化深刻利用下，我国分布式数据库软件适应了数字化倒退的需要，必将获得疾速翻新和倒退。 PingCAP公司副总裁刘松：分布式数据库就是数据库技术和分布式架构的一个联合。所以新一代的分布式数据库既具备经典数据库有的联机交易和在线剖析的能力，同时要具备新一代分布式架构有的高扩展性、主动运维，包含新一代的云原生这种承接能力。 华为云数据库首席架构师冯柯：分布式数据库六大关键技术方向：寰球多活高可用、软硬深度协同、企业级混合负载、云原生、数据安全与可信、AI-Native 论述了华为 GaussDB 的根技术能力打造之路。 OceanBase CTO杨传辉：11年来咱们始终是原生分布式数据库的信仰者和开拓者，我认为原生分布式数据库的几个外围个性为：有限扩大，永远在线，在一套引擎同时反对 TP 和 AP 的混合负载，保障强一致性。 OceanBase 原生分布式数据库经验了三次技术迭代，从最早的 NoSQL 零碎走向第一代分布式数据库，第二代分布式数据库采纳搭积木的形式，在 NoSQL 的根底之上，引入了 SQL 的反对，反对根本的 SQL 性能，但往往都就义了单机的性能和老本。目前，谋求极致的第三代原生分布式数据库反对残缺的企业级性能，并且做到单机性能与集中数据库根本相当。 开源、生态-Key Word 2PostgreSQL 寰球开发组联结创始人 Bruce Momjian：他认为开源对于寰球的开发者而言都是一个绝好的时机，在开源的整体环境下，开发者的作品可能在寰球范畴内失去认可，其自己可能有机会在国际性会议上发言。谈到分布式数据倒退，他认为随着市场成熟与价值的露出，会有越来越多的人将眼光投向分布式，而对于从业者而言，更多是要投入到翻新与保障整体我的项目的衰弱度之上，这样能力做到真正的市场后行。 PingCAP 公司副总裁刘松：分布式数据库开源化这个潮流势不可挡。将来数据库最大的使命就是让各行各业数字化，这也是最大的利用需要。而在这个需要之上的技术演进要靠开源，源源不断的给更多的技术引擎供应。与此同时想要服务企业客户，还须要新一代云基础设施，尤其是跨云的云原生来承载。利用需要+开源+云基础设施这就是一个三角形，挪动互联网时代，分布式数据库的架构演进到明天，甚至到将来十年，都可能是在这一个三角形的框架外面持续倒退。 华为云数据库首席架构师冯柯：分布式数据库符合以后中国的倒退阶段，是由中国的人口红利驱动的流量使用下产生的一种新的数据库状态。分布式数据库就像是高铁，单机就像是轿车。开发分布式只管简单，就像咱们没方法把高铁做成像轿车那样不便灵便，但二者都是通向同样的智能化指标。 云、开放性-Key Word 3CSDN 创始人&董事长，极客帮创投开创合伙人蒋涛：咱们看到分布式的外围价值之一是可扩大，这点咱们原有技术架构难以满足。其次是高可用，当初不论是云上还是在混合云，多地多核心部署曾经成为常态。所以这个外围价值的外围是什么呢？在蒋涛眼里，是开放性，这点值得每个分布式数据库开发者长铭于心。 PingCAP 公司副总裁刘松：咱们开始进入到散布数据库的下一个时代，从最后的互联网需要到金字塔顶端的数字化需要，是驱动全社会关注散布数据库行业的最大背景之一。当初很多云端数据库不肯定满足高并发、高扩大的需要，跨云问题始终悬而未决，但新一代的云原生利用场景对分布式数据库的需要十分强烈，分布式数据库将来最大使命便是促成千行百业实现数字化指标。 一致性-Key Word 4腾讯分布式数据库 TDSQL 首席架构师李海翔：在演讲中他回溯了数据库体系建设以来对于数据异样的定义与概括，并具体论述了数据异样与整个事务处理畛域对于数据异样、隔离级别与一致性三者之间的关系。TDSQL 的钻研团队通过定义抵触关系，构建抵触图，建设图与异样的映射并进一步对数据异样进行分类的形式，胜利建设了体系化的钻研数据异样的框架，并初步形容了并发拜访算法。当数据异样之后，以向环图为例，顶点和边的个数是无穷多个的，这意味着数据异样是有无穷多个的。对于无穷的咱们怎么去加以认知呢？所以咱们要对数据异样进行分类。对数据异样分类可能概括总结就失去一个表格，这个表格概括了所有的数据异样。而后当咱们对所有的数据异样进行了拆散之后，咱们就能够去定义什么叫做隔离级别，什么叫做一致性了。简略来说，有数据异样即不满足一致性，满足一致性等于无数据异样。 ...

OceanBase 开发者核心（OceanBase Developer Center，ODC）在通过了新一轮的优化与晋升后，迎来了 V3.2.0 新版本。 ODC V3.2.0 版本的外围指标是建设权限模型，向平安管控迈出第一步。自本版本起，ODC 反对权限管控，管理员可配置普通用户的权限（包含是否容许创立集体连贯、是否有公共连贯的拜访权限，以及对公共连贯的读写管制）。 同时在稳定性和易用性方面，本版本已更上一个台阶（在 SQL 执行、对象交互、后果集查看与编辑方面做出大量优化工作并已修复 100+ 的存量缺点），旨在为用户享有更好的应用体验。 ODC V3.2.0 新增性能及利用场景 为满足不同场景的业务需要，ODC 一直晋升产品性能和个性，以满足集体开发者疾速上手应用 OceanBase 并晋升开发人员与 DBA 的合作效率。 新增公共资源治理，保障资源平安 作为企业数据库开发平台，ODC 提供公共资源管控台的服务，不便 ODC 管理员进行用户的治理与权限和资源的调配。 被授予管理员角色的 ODC 用户可在 ODC 首页查看公共资源管控台页签，非管理员用户首页不会显示此页签。 管控台中提供用户治理、角色治理、公共连贯治理、资源组治理和零碎设置等服务。其中用户须要通过角色授予公共资源和集体资源权限。同时应用资源组能够批量授予或回收公共连贯的权限。 日常工作中，数据库管理者常常会碰到此类痛点。心愿开发同学可能有权限拜访或操作某些库时，不心愿这类同学获取数据库账号密码，同时如需禁止这类用户持续拜访，可能实时回收他们的权限。如单纯依赖数据库的账号体系，则无奈满足需要，这种状况下只能依赖平台联合数据库账号来实现上述需要。 ODC V3.2.0 提供了公共资源管控台的能力。仅某些有管理员角色的用户才可登录公共资源管控台。管理员进入管控台后可新建用户，并通过角色为用户赋权。同时对已存在的用户，管理员同样可对他们进行根本信息批改、权限调整以及删除操作。 经典应用案例 客户环境共有数据库 200 套，其中有 30 套属于领取业务，50 套属于生态业务，残余 120 套属于信用业务。客户共有研发员工 150 名，其中领取部门员工 25 名，生态部门员工 35 名，信用部门员工 90 名。公司共有 DBA 团队 1 个，共计 5 人。因为公司的研发成员数量远远大于 DBA 数量，DBA 需为本人减负，如容许研发同学自行保护开发环境，并授予其生产环境读取数据的权限。为保障数据库的可维护性，DBA 不能将数据库账号密码间接提供给研发同学。其中数据库的细节信息如下： 因为客户环境中已应用 ODC ，可间接利用 ODC 来解决客户的权限调配问题。具体操作如下： ...

近期，OceanBase 迁徙服务（OceanBase Migration Service，OMS）公布了 V3.1.0 版本。 上面，咱们就为大家揭开 OMS V3.1.0 版本的神秘面纱，看一看，OMS V3.1.0 版本除了新增反对 OBServer V3.1.0 版本之外，还新增、欠缺了哪些性能。 欠缺数据迁徙服务从本版本开始，OMS 反对 Oracle 12C 至 19C的可插拔数据库 PDB 到 OceanBase Oracle 数据库的数据迁徙。欠缺了反对的数据迁徙利用场景，可能将利用更加平滑的迁徙到 OceanBase 数据库上。 欠缺数据同步服务一）OMS V3.1.0 反对同步 MySQL 数据库的数据至 DataHub DataHub 是流式数据处理平台，提供对流式数据的公布、订阅和散发性能。应用 OMS V3.1.0，除了 OceanBase 数据库、Oracle 数据库之外，您还能够将 MySQL 数据库中的存量和增量数据同步至 DataHub，帮忙您疾速实现应用流计算等大数据产品对数据进行实时剖析。 二）欠缺逻辑表汇聚同步性能 新增反对分库不分表场景下的逻辑表到物理表的实时同步，帮忙您疾速构建企业外部 BI、交互查问、实时报表等零碎。 三）反对通过文本导入对象 OceanBase 数据同步到音讯队列数据终端时，反对通过文本导入对象。 输出须要迁徙的对象后，单击 测验合法性，OMS 会主动查看增加对象的合法性，疾速实现迁徙对象的增加操作。 欠缺高可用性能 高可用性能，即 HA 性能。高可用性能是保障业务连续性的无效解决方案，为了最大水平保障同步链路的稳定性和继续可用，OMS 设计了能够秒级切换的集群高可用架构。 在 OMS V3.1.0 之前的版本，OMS 的 HA 性能仅反对主动守护日志拉取组件。从 OMS V3.1.0 版本开始，HA 性能新增反对主动守护 OMS 的同步写入组件，当OMS 产生单点故障等导致同步服务不可用时，OMS 的 HA 服务会主动将故障节点的增量流量切换到 OMS 集群内的其余可用资源节点上，同步链路不受到任何影响。同时本版本的 HA 性能还欠缺反对了 MySQL 主备切换利用场景。 ...

引言在数据库 OceanBase 3.0 峰会上，OceanBase 发表正式开源，并成立 OceanBase 开源社区https://open.oceanbase.com/， 300 万行外围代码向社区凋谢。开源的 OceanBase 社区版代码因为通过多年的迭代与变动，新人上手殊为不易。为了帮忙大家理清脉络欢快上手，自己将利用碎片工夫围绕“源码解读”写个系列介绍。将通过一系列文章进行论述，帮您理清数据库的外在实质。 本系列将从以下六大模块进行介绍： 一、数据库的整体架构：梳理 OceanBase 数据库代码的整体架构和模块形成，以及各模块的各自性能。 二、SQL 的毕生：介绍 OceanBase 数据库中任意一条 SQL 的执行流程，包含接管、解决、返回后果给客户端的过程。 三、分区的毕生：解说 OceanBase 数据库存储层的相干常识。 四、事务的毕生：解析 OceanBase 数据库事务的内部接口。 五、租户的毕生：论述 OceanBase 数据库多租户的个性。 六、虚构表：拆解 OceanBase 数据库虚构表的实质。 （注：各位看官，本系列是代码导读，不是设计解读，肯定要联合代码来看，并且最好配上入手实际，否则就是把辅导手册当教材看了。） 通过本系列的源码解读文章，您首先能够理解 OceanBase 数据库的基本原理，轻松 get 数据库的实现步骤。推而广之，您也能够把 OceanBase 的实现原理利用到其余数据库，这对您学习其余的数据库也将带来帮忙。其次，在相熟了 OceanBase 的代码之后，如果有须要，您能够间接在后续工作中应用咱们的代码，或者为 OceanBase 社区奉献您的代码。 注释 本文为《带你读源码系列》第一篇，次要为大家介绍 OceanBase 数据库代码的整体架构和模块形成，以及各模块的性能。 顶层目录 上图为顶层目录。主体代码在 src 目录下，单元测试代码在 unittest 目录下。unittest 目录下单测的目录构造与 src 目录下的构造和命名形式雷同。例如，src/sql/abc.cpp 对应的单测文件是 unittest/sql/test_abc.cpp，单测应用 gtest 和 gmock 框架。unittest 目录下也蕴含一些重要组件的集成测试。 test 目录下则是零碎测试，这里的测试对象是残缺启动的 observer。其中 test/mysql_test 目录下蕴含的各种测试用例是利用批改后的 mysql_test 框架运行的测试用例。它次要用 SQL 来测试零碎性能正确性。 ...

为了帮忙大家疾速入门分布式数据库的开发、运维和性能诊断技能，OceanBase 开源团队正式推出原生分布式数据库 OceanBase 社区版的第一本教程——《OceanBase 社区版入门到实战》，深入浅出地解说如何疾速把握 OceanBase 实际技能，晋升职场外围竞争力。 本期教程全副收费！ 扫码即可开启学习之旅！ 为期近三个月的工夫，每周教程连载+视频解析+直播互动，率领咱们疾速建设零碎的 OceanBase 分布式数据库思维。 1、 教程学习的正确姿态参加直播学习 实现视频学习打卡 社群内答题交换 课堂练习 参加越多，更有机会取得由 OceanBase 开源团队颁发的教程结业证书。原生分布式数据库 OceanBase 社区版的第一本教程，速来入群学习吧！ 2、为什么要学OceanBaseOceanBase 100%自主研发，间断8年稳固撑持双11，翻新推出“三地五核心”城市级容灾新规范，是寰球惟一在TPC-C和TPC-H测试上都刷新了世界纪录的国产原生分布式数据库，具备高可用、高扩大、高兼容、易治理、部署灵便、高性价比等特点 ，已助力200+行业客户实现外围系统升级。 自往年6月1日开源以来，数以万计的用户开始下载、学习和测试 OceanBase 企业版和社区版。 3、你当初面临的挑战OceanBase 装置部署不胜利的问题 OceanBase 数据导入报错或性能慢问题 MySQL 数据迁徙到OceanBase 的问题 OceanBase 业务测试的性能问题 4、谁适宜学这门课程本教程适宜对数据库根底有肯定理解，并且接触过一门数据库的开发者、DBA 或者数据库爱好者。 DBA ：你有做数据库运维的教训，但目前遇到了一些问题，比方感觉调优效率不够高，无奈零碎排查性能问题等； 数据库开发者：心愿对 OceanBase 数据库有一个全局的意识，从源码层面理解 OceanBase 的架构设计； 数据库爱好者：你关怀数据库畛域呈现的新机遇和新方向，有待业、投资、学习等诉求。 本教程侧重于实际操作，须要有 OceanBase 演练环境，也是对 OceanBase 培训课程OBCA、OBCP的补充。 5、 残缺学习安顿为期近三个月的集中式学习，助你疾速成为分布式数据库领域专家； 轻松应答当数据量增大，应用传统数据库所带来的运维复杂度和故障解决危险问题； 保障简洁解决方案的性能稳固，晋升职场外围竞争力。 6、 学完课程你将播种本教程次要蕴含上面内容，打算按周逐渐推出。 教程内容公布后，咱们也会按周为频次举办系列直播，由 OceanBase 导师团在线演示教程，互动教学。 所有相干的实际操作还会有视频前期放出供大家学习参考。除了直播外，课程还设置了相应的题目供大家练习，并在 OceanBase 社区版官网问答区开设培训探讨交换专区（open.oceanbase.com/answer ）。 7、退学后能取得什么海量视频课，每天可随时观看 一套可复制、可学习的结构化 OceanBase 实战指南，蕴含九大章节，循序渐进，带你解锁 OceanBase 从入门到运维到调优的最佳学习门路 ...