KunLunDB_Linda的博客

【明晚直播】赵伟|KunlunBase 1.1版本发布&丁奇|KunlunBase Fullsync 机制优化实践

KunlunBase产品使用和评测指南

KunlunBase功能体验范例

KunlunBase 1.0 发布了！

并且无论在使用PostgreSQL协议的连接还是MySQL协议的连接中，都可以执行昆仑数据库支持的任何语法，包括这些MySQL私有DML语法，也包括标准的SQL语法，以及昆仑数据库支持的任何其他PostgreSQL私有语法。昆仑数据库的计算节点基于PostgreSQL研发，因而直接可以支持PostgreSQL的连接协议，所以使用JDBC、ODBC等通用的数据库连接协议以及使用各类编程语言的PostgreSQL专有的连接库的软件都可以连接到昆仑数据库集群并且正常工作。......

在演示的环境中，数据集群由两个shard组成（shard1,shard2),shard1的shard_id=1,shard1包含3个副本（id为1，2，3，id为1的是主节点，id为2和3的是备机。备机的存储节点的硬件配置与主节点一致，在一般的生产使用过程中，备机节点的主要目的是作为主机出现故障后的替换节点，不接受应用程序的直接数据处理请求，因此，在非故障切换的情况下，备机的存储节点资源利用率相对较低。只读语句将被路由到从备机节点，降低了主节点的IO资源利用率，系统整体性能获得提升。......

kunlun-0.9.1的性能测试主要使用Sysbench进行，分为oltp测试和olap测试两大部分。对于oltp测试，主要包含4种操作read&write、writeonly、update_non_index、update_index，测试目的主要是检查新推出的强一致性模式(rbr)，对比MySQL的官方强一致性方案(mgr)性能有多大提升。由于网络不是瓶颈，主要在内网的机器中进行。对于olap测试，则主要包含。......

KunlunBase具备完善的容灾和错误处理机制，通过分布式事务两阶段提交算法，以及Fullsync和FullsyncHA机制，可以确保在集群运行期间任意计算节点、存储节点、cluster_mgr等组件发生宕机、重启等故障或者发生网络分区（networkpartition）或者断连时，集群管理的用户数据以及元数据都会是一致的和完整的，不会丢失用户已提交事务的任何数据更新，也不会发生事务部分提交部分回滚等不一致情况，以及发生用户的元数据与用户数据不一致等情况。分布式事务处理两阶段提交机制和原理）。......

在一些业务场景中，用户需要插入、更新、删除一行或者多行目标数据行，然后获得自己刚刚插入、更新、删除之后的行或者其部分字段的值，包括部分字段构成的任意合法的表达式的值。对于MySQL用户来说，要做到这一点，用户通常需要在一个显式的事务中执行update语句，然后使用相同的查询条件把update的语句取出来。之所以要在显式事务中做，是为了防止其他并发的事务update了本连接刚刚update的行，那样的话，随后的select语句得到行就不是本连接刚刚update之后的行了，因为这些行又被其他事务更新过了。...

KunlunStorage是泽拓科技基于Percona-mysql-8.0.26优化的数据库存储服务器，作为KunlunBase分布式数据库的存储节点，我们对percona-mysql做了大量性能增强，补足了其在XA事务处理的容灾和错误处理方面的空白，并增加了一些昆仑数据库集群整体需要的功能，包括fullsync复制，update/delete…returning语句等。1.2.3.PostgreSQL在负载动态变化过程中，有明显的延迟抖动，而Kunlun-Storage性能曲线相对平稳.点击阅读原文。..

为了让MySQL的应用更为便捷地迁移到KunlunDB，我们做了很多兼容MySQL的工作。本篇章主要介绍KunlunDB现在已经支持的MySQL常用的私有DML语法，以及这些语法与原生MySQL的差异。

上述执行计划首先将几个维度表做join（dates和supplier和part),得到的结果再与事实表lineorderjoin,因而得出了一个超级大的中间结果集，数据量达到10的15次方的数量（查询计划第五行返回的rows），最终导致临时文件耗尽磁盘空间而未能完成查询。PostgreSQL自动采用最优的join次序，大大减少了最后排序的数据量，并且启动了3个并行分割数据集，因此执行的性能比手动优化后的MySQL还快10倍。4张维度表customer，part，supplier，dates。...

昆仑数据库的Fullsync机制是一种存储集群的高可用机制，它用于确保一个存储集群在发生节点故障、网络分区等问题时，该集群中存在可用的备机含有所有向用户确认提交成功的事务的binlog，以便可以按需选举出新的主节点，确保集群持续可以写入，实现高可用。昆仑数据库的Fullsync机制基于MySQL久经考验的RowBasedReplication（RBR）binlog复制机制，实现了主备复制的强同步，也就是确保主节点上提交的每一笔事务。...

集群备份恢复介绍

集群管理功能介绍

计算机管理功能介绍

XPanel管理系统主要用于管理Kunlun Databases Cluster，监控集群节点当前的QPS和计算机的cpu等信息。

在OGG中，异构数据库之间的数据同步需要为源端创建定义文件。32x86_64HeapSizeFileSize\*7Nullneutral最后，将定义文件从oracle服务器/dirdef/KUNLUNTEST.def复制到KunlunBase服务器的./dirdef/KUNLUNTEST.def。

对于在线实时数据同步，KunlunBase支持OracleGoldenGate，可以使用OracleGoldenGate将数据从PostgreSQL或其他数据库（Oracle/SQLServer/MySQL等）同步到KunlunBase。由于KunlunBase在插入数据时要求表存在主键，为确保数据迁移的成功，要求在原生PostgrSQL数据库导出数据的过程中分两步执行（第一步，导出数据结构，第二步，导出实际数据）。在恢复过程先恢复数据结构，在导入数据，下面将分两个场景演示具体操作指令。...

一、了解对等部署KunlunDB是计算&存储分离的分布式数据库，支持海量数据处理，可以解决传统数据库分库&分表带来的复杂性问题。KunlunDB的核心组件如下图所示，由计算引擎和存储引擎组成。计算引擎主要负责数据处理计算，是CPU资源密集型服务器，而存储引擎是IO资源密集型服务器，在实际生产环境部署过程中，可以将计算引擎和存储引擎部署在同一台服务器上，以获得资源的有效利用，同时通过不同节点间的组件冗余来实现高可靠性。典型的对等部署结构下图所示：.

一、分布式数据库的基础核心能力-水平扩容（ScaleOut）数据库系统架构的演变，如实的反映了信息社会不断发展所带来的数据处理规模不断变大这一基本事实。如今，分布式数据库产品已成为各行各业信息系统的存储服务中，应用越来越广泛的技术选型。究其原因，是因为其在海量数据存储管理的扩展能力和性价比方面，较单机数据库有着压倒性的优势。在我们对昆仑分布式数据库的扩容功能正式开始介绍之前，我们首先回顾一下数据库管理系统扩容的常见模式。数据库的扩容大体上分为如下两种模式：垂直扩容（Vertically Sc

KunlunDB在0.9版本之后，增加了运维监控平台(Xpanel), 通过集群管理（Cluster_mgr）的HTTP命令接口，可以实现对整个集群环境进行管理和监控。以下是详细的命令接口介绍：获取cluster工作状态，POST接口：curl -d "{\"job_type\":\"get_status\",\"job_id\":\"uuid999\"}" http://127.0.0.1:57000由于创建集群，和恢复一个新集群，会生成新的集群名称，通过get_status这个命令获

KunlunBase是一个开源、高性能的分布式关系数据库，支持混合负载（HTAP）、PB级数据量管理并提供毫秒延迟的新一代数据库解决方案。1.1.1 集群组件架构图1.2 KunlunBase主要组件：1.1.2 KunlunServer(计算节点）计算节点运行无状态计算&查询引擎，与Kunlun Storage进行交互执行SQL 任务，采用异步通信模式，一个计算节点可以协调多个存储节点执行数据处理（增删改查）任务。计算节点从元数据集群获取集群元数据并在本地持久化。Kunlun Server的SQL层兼容

如果在正常的多租户的应用中，你想要去使用分布式数据库，那么你会考虑哪些重要需求呢？答案不言而喻：性能、安全性、可管理性，可扩展性。这四个需求无非是所有的多租户应用中的共通需求且重要。 为什么？基本原则：性能保证：不跨数据库操作，避免跨节点操作。安全性：用户之间隔离性。可管理性：支持应用的灵活性，业务调整，数据迁移，备份恢复。可扩展性：支持业务弹性扩容。...

全局一致性物理备份&恢复基本概念物理备份：数据库的物理文件（数据文件，交易日志文件，参数文件）的备份。物理备份又可以分为脱机备份（冷备份）和联机备份（热备份）。KunlunBase集群支持联机备份，备份过程中，数据库处于运行状态，应用程序读写不会阻塞，由于备份操作发生在主从节点的从节点上，对应用程序的性能基本没有影响。一、备份恢复架构备份恢复目标：存储集群和元数据集群备份恢复调度中心：Cluster manager备份数据保存：备份存储池集群备份执行单元：Node Manager二、基本原理KunlunBa

前面2篇文章我们介绍KunlunBase的查询优化原理和Project和Filter下推演示（KunlunBase，KunlunBase），本节讲述排序查询优化之排序下推。一条含有order的SQL的执行计划在如下生成过程中，Sort被下推到RemoteScan算子里面。Sort下推的操作是异步方式，指令在各个数据节点并行执行，过滤数据后，将排序后的结果反馈给计算节点，降低了计算节点的负载。下面我们来测试查看查询下推的执行计划为支持排序下推，需要在KunlunBase设置如下如下参数为true： ..

上一篇讲述了KunlunBase的查询优化原理（KunlunBase），本篇讲述Project和Filter下推演示。1.1 测试环境本次测试演示投影和过滤操作的下推。测试环境的数据库集群共有四个数据节点（DN), 配置为两个shard (shard1和shard2)，每个shard节点由一个主节点和一个从节点构成（shard1两个节点为数据复制关系，shard2两个节点也是数据复制关系，shard1 和shard2 存放数据表的不同分片数据）。如下图： 可以通过下面语句显示集群环境的节点信息结果如

前面介绍了KunlunBase的架构以及技术，应该会有朋友好奇其查询优化的过程吧，本篇章带来的是查询优化这一块的具体流程介绍，后续也会出一篇实例来举例演示。当然后续也会对KunlunBase的其它技术方面（比如数据分片这些）做实例演示，以方便大家去了解KunlunBase。...

看了标题会不会诧异，怎么昆仑分布式数据库玩起了分布式文件系统？因为昆仑分布式数据库0.9版本起，要增加HDFS分布式文件备份功能，所以开发小哥哥工作中，就顺便把学习的过程分享出来。HDFS（HadoopDistributed File System）是Hadoop项目的核心子项目，是分布式计算中数据存储管理的基础。是基于流数据模式访问和处理超大文件的需求而开发的，可以运行于廉价的商用服务器上。...

本篇文章就来阐述说明下昆仑数据库独特的读写分离功能详细介绍

一个分布式计算和存储系统的任何节点都可能因为节点负载过重，节点的计算、存储资源不足，网络延时，网络短暂不可达而导致操作超时。分布式系统的任何操作在等待远程节点返回期间，通常会持有各种资源，不可以无限制等待下去，否则系统整体运行都会因此被阻塞而逐步停滞。所以超时控制是所有分布式系统需要去解决好的问题，而解决不好就会导致系统运行停滞，无法正常工作。通常情况下用户并不需要修改这些变量，因为我们已经针对常规情况最优化了计算节点和存储节点的配置参数。不过在特殊场景下还是需要修改这些超时变量的。...

昆仑分布式数据库（下文简称昆仑或者昆仑数据库）的计算节点源自PostgreSQL，因此继承了PostgreSQL的Sequence功能，本文介绍昆仑分布式数据库的Sequence的功能用法、用例和实现。用法和用例昆仑数据库的Sequence与MySQL的autoincrement（自增列）相比，其功能更加强大和灵活。主要体现在以下几方面：1.昆仑的Sequence与表是多对多的关系，而MySQL的自增列与表是1对1关系具体来说，昆仑数据库的每个表可以有任意数量的sequen.

​这些年，由于数据规模和业务访问负载越来越大，越来越多的公司无法依赖单台数据库服务器支撑其业务，越来越多的公司不得不做数据分区存储，也就是所谓的分库分表，但大量的烦恼与困惑也随之而来。 令人“头都大了”的分库分表中间件 10多年前阿里因此原因不得不把淘宝后台系统从Oracle RAC切换到数百个 MySQL集群构成的分库分表集群，不过那时的淘宝仅仅使用一个分库分表中间件，名为tddl（又名：头都大了，江湖上现在还有tddl的传说），而不是分布式数据库，这两者之间的区别，也可能正是tddl让

背景笔者在过去经典的两阶段提交算法过程中，发现会遇上部分节点在执行事务提交期间发生故障，导致如下的错误，这些错误都会导致用户数据丢失或者出错。错误如下：1、一个分布式事务的一部分事务分支被提交，另一部分事务分支被回滚2、应答给客户端事务提交成功，但是分布式事务所有分支全部被回滚3、应答给客户端事务被回滚，但是分布式事务部分或者全部分支被提交4、存储节点故障恢复时，某个存储节点的事务分支不能被正确地恢复。在上面这些错误源中，第#4类错误处理由存储节点自身负责，分

笔者和团队在昆仑分布式数据库中的两阶段提交方式，可以成功避免经典的两阶段提交算法的缺陷。而在此分布式事务处理两阶段提交机制和原理上，笔者和团队增强其容灾能力和错误处理能力，可以做到任意时刻昆仑数据库集群的任意节点宕机或者网络故障、超时等都不会导致集群管理的数据发生不一致或者丢失等错误。本文会详述分布式事务对于两阶段提交算法的错误处理原理和机制及延时损耗~在生产环境的分布式数据库集群的工作场景中，通常只有不到0.01%的分布式事务提交会发生错误，但是我们仍然需要处理所有可能发生的错误。因为哪怕执行了100亿笔

笔者在上篇文章中回顾了经典的两阶段提交算法原理及缺陷，有兴趣可点击查看原文《「技术讨论」经典的两阶段提交算法原理及缺陷》，此篇不做详述。为避免经典的两阶段提交算法缺陷的发生，昆仑分布式数据库的分布式事务处理机制基于经典的两阶段提交算法，并在此基础上增强了其容灾能力和错误处理能力。故此可以做到任意时刻昆仑数据库集群的任意节点宕机或者网络故障、超时等都不会导致集群管理的数据发生不一致或者丢失等错误。二、昆仑数据库如何分布式事务处理两阶段提交？昆仑数据库分布式事务处理功能涉及的模块分布在计算节点，存储集群...

该文档仅供参考，详细请查看：https://gitee.com/zettadb/kunlun_scripts/blob/main/cluster/README.cn.md在安装完所有的库和依赖情况下，相比于手动安装 kunlun cluster 需要30分钟到一个小时的时间安装，一键快速安装只需要10分钟就可以玩起来。在安装之前，要确保安装环境满足以下要求：1、所有节点所在机器须为Linux, 安装了bash, sed, gzip, python2, python2-dev等

昆仑分布式数据库集群（下文简称昆仑数据库）是一个分布式关系数据库管理系统，面向TB和PB级别海量数据处理，以高吞吐量和低延时处理海量数据高并发读写请求。它提供健壮的事务ACID保障，高效易用的分布式查询处理，高可扩展性，高可用性和透明的分库分表数据处理功能，业务层和终端用户无感知的水平扩展能力，是典型的 NewSQL分布式数据库系统。应用软件开发者按照使用单节点关系数据库相同的方法使用昆仑数据库，就可以得到所有上述NewSQL数据库的优点，完全不需要考虑数据的分区方式等存储细节。这样，应用开发者就可...

上章节介绍了昆仑分布式数据库的架构，这章节接着介绍昆仑分布式数据库的技术特点！

上章节介绍了昆仑分布式数据库的技术特点，这章紧接上文带来数据库的技术优势。一、开源、扬众长避众短1.1集3大主要数据库Oracle、MySQL、PostgreSQL的强项于一身并产生1+1>>2的放大效应，可以广泛汇聚社区能量，产生长久的价值和生命力。 Oracle:存储引擎，查询处理。 innodb完全遵从Oracle的存储引擎的设计。 MySQL:innodb存储引擎和 binlog 复制(RBR)。 PostgreSQ.