共计 2573 个字符,预计需要花费 7 分钟才能阅读完成。
KunlunBase 数据库集群在数据库外部反对读写拆散,并且对利用通明,用户应用程序不须要做任何批改就能够应用数据库的读写拆散性能,从而进步整个零碎性能及投资回报率。
一、产品架构
KunlunBase 的整体架构次要由计算层和存储层形成,计算层负责 SQL 响应、解释、执行等,存储层负责数据的存储管理,存储层的数据采纳多正本存储机制,备机(从正本)通过强同步技术保持数据与主节点一致性。
备机的存储节点的硬件配置与主节点统一,在个别的生产应用过程中,备机节点的次要目标是作为主机呈现故障后的替换节点,不承受应用程序的间接数据处理申请,因而,在非故障切换的状况下,备机的存储节点资源利用率绝对较低。
KunlunBase 的读写拆散计划是通过路由只读操作到备节点,从而能够缩小计算节点的资源竞争,升高主节点负载。
二、实现原理
KunlunBase 的读写拆散在计算层的近程查问优化器内实现的,当用户的 SQL 同时满足如下条件:
- 以后 SQL 类型为 select;
- SQL 中不蕴含用户自定义函数(即 create function 语句创立的函数), 除非以后事务为只读事务;
-
如果不在事务中(autocommit=on),则容许读写拆散;如果语句在显示事务中,则要满足:
- 如果在只读事务中,则容许读写拆散;
- 如果在读写事务中,则该事务尚未更新过任何数据;
近程查问优化器就会将相应的 SQL 执行打算下发到从备机的节点上执行
KunlunServer 会依据以下规定抉择发送 select 语句到指标存储集群的哪个备机节点:
- 依据节点权重值抉择(ro_weight)
- 依据网络提早 (ping)
- 依据主从正本的数据一致性提早(latency)
三、配置施行
场景阐明 :某 OLTP 业务零碎有大量的查问操作,在业务高峰期数据库响应速度变慢,导致了业务的性能问题。经查看发现存储节点主节点的存储节点的 IO 资源利用达到瓶颈,但备机节点的 IO 资源利用率低。
以上场景能够通过读写拆散计划解决零碎性能问题,不须要批改利用,不须要减少硬件配置,通过读写拆散的施行,能够解决性能问题。
施行步骤:
第一步 :设置参数,启用读写拆散。(依据状况选一种级别)
设置 enable_replica_read = on (on 开启读写,off 敞开)。
用户级别开启 :(用户登录后失效)
alter user abc set
enable_replica_read = true;
Session 级别开启:(以后 session 失效)
set enable_replica_read=on;
数据库级别开启:(对该计算节点的所有 session 无效)
在 pg_hba.conf 文件中设置
enable_replica_read=on;
第二步 :登录数据库,配置读写拆散策略。
设置如下参数,启动读写拆散策略:
replica_read_ping_threshold
,计算节点到备节点的 ping 提早阈值,0 示意不关怀;replica_read_latency_threshold
,主备同步提早的阈值,0 示意不关系;replica_read_order
,抉择备机优先级:0,按权重;1、按 ping 提早;2、按主备同步提早;replica_read_fallback
,备机抉择的回退策略 (如果备机不能拜访);replica_read_fallback=0
,间接报错,replica_read_fallback=1
,任意抉择一个备机进行拜访,replica_read_fallback=2
,抉择主机进行拜访。
第三步 :查看 & 设置权重(可选)。
在演示的环境中,数据集群由两个 shard 组成(shard1 , shard2) ,shard1 的 shard_id=1, shard1 蕴含 3 个正本(id 为 1,2,3,id 为 1 的是主节点,id 为 2 和 3 的是备机。
通过配置,能够设置只读操作的首先备机
设置 Shard1 的 node3 主机的作为首先备机 (因为 node2 节点位于不同机房,提早太高):
update pg_shard_node set ro_weight=2 where
port=6006;
Select * from pg_shard_node ;
Shard1 的 node3 的权重最高(ro_weight=2)
第四步 :执行查问, 验证读写拆散(可选)。
通过设置 log_min_messages to‘debug1’
能够将 SQL 语句的执行信息输入到日志中,以不便查看 SQL 下发的指标存储节点(生产零碎不要设置,否则影响性能)。
查看计算节点的日志,确认读写拆散。
SQL 只读语句(select ti.id from t1) 被下发到 shard1, 节点 3 上(该正本权重最高),而 update 语句 (update t1 set id=3) 是在主节点 shard1 节点 1 上执行。
论断
以上过程验证了该用户的读写操作拆散实现。只读语句将被路由到从备机节点,升高了主节点的 IO 资源利用率,零碎整体性能取得晋升。
END
昆仑数据库是一个 HTAP NewSQL 分布式数据库管理系统,能够满足用户对海量关系数据的存储管理和利用的全方位需要。
利用开发者和 DBA 的应用昆仑数据库的体验与单机 MySQL 和单机 PostgreSQL 简直完全相同,因为首先昆仑数据库反对 PostgreSQL 和 MySQL 双协定,反对规范 SQL:2011 的 DML 语法和性能以及 PostgreSQL 和 MySQL 对规范 SQL 的扩大。同时,昆仑数据库集群反对程度弹性扩容,数据主动拆分,分布式事务处理和分布式查询处理,强壮的容错容灾能力,欠缺直观的监测剖析告警能力,集群数据备份和复原等 罕用的 DBA 数据管理和操作。所有这些性能无需任何利用零碎侧的编码工作,也无需 DBA 人工染指,不停服不影响业务失常运行。
昆仑数据库具备全面的 OLAP 数据分析能力,通过了 TPC- H 和 TPC-DS 规范测试集,能够实时剖析最新的业务数据,帮忙用户发掘出数据的价值。昆仑数据库反对私有云和公有云环境的部署,能够与 docker,k8s 等云基础设施无缝合作,能够轻松搭建云数据库服务。
请拜访 http://www.zettadb.com/ 获取更多信息并且下载昆仑数据库软件、文档和材料。
KunlunBase 我的项目已开源
【GitHub:】
https://github.com/zettadb
【Gitee:】
https://gitee.com/zettadb