点击上方蓝字关注我们

1
Klustron简介:

弹性伸缩的计算和存储能力 数据分区(partition): hash, range, list 任意数量和类型的分区列 数据分布(distribution) auto, random, mirror, table grouping 自动、柔性、不停服、无业务侵入、终端用户无感知 金融级高可靠性 自动处理软硬件和网络故障和机房整体故障 数据不丢不乱,服务持续在线 确保RTO < 30秒 & RPO=0 自动发现主节点故障并选主和主备切换 HTAP: OLTP & OLAP 互不干扰 OLTP为主:对应用软件等价于使用MySQL或PostgreSQL OLAP为辅:多层级并行查询实现高性能 多语言存储过程的弹性计算:ML,隐私计算 生态兼容性 支持PostgreSQL和MySQL 两种连接协议和SQL 语法 支持MySQL 常用DDL语法 支持JDBC,ODBC,常见编程语言的PostgreSQL和MySQL 客户端connector 全方位多层级安全性 加密存储和传输 多层级访问控制机制
2WHY
Why?
可能的故障 主节点硬件故障,断电,OS重启,误杀进程; 主备节点磁盘坏块,磁盘全毁 网络分区、断连、拥塞 金融级高可靠性的要求 故障时数据库集群可以读写(自动探测主节点状态,发现主节点故障时自动选主和主备切换) 故障时不丢失数据 高性能,低延时 集群长期不间断工作,自维护
Semisync 主节点故障后不可以重新加入集群--- 集群节点数量无法快速恢复 备机ACK超时自动退化为异步,一致性(Consistency) < 可用性(Availability)无法实现金融级强一致性 备机ACK前没有fsync relay log, 备机OS重启(例如 机房/机架/服务器断电)会导致已确认事务的binlog丢失 占用工作线程等待备机ACK,连接较多时需要启动大量线程 不完备,需要外部组件配合实现高可用,不能完成主节点故障发现,选主和主备切换 MySQL Group Replication 备机确认收到binlog后,主节点才写入binlog到binlog文件,事务提交前持锁等待时间很长,显著增大本事务延时 占用工作线程等待备机ACK,连接较多时需要启动大量线程
3
Fullsync & HA
主节点上事务完成提交后等待备机收到其binlog的ACK才返回给客户端(kunlun-server) 主节点上完成提交的任何事务都有至少1个备机(可配置)收到其完整的binlog并持久存储 等待ACK的时机:主节点上事务完成提交流程后返回状态给客户端之前已经完成提交流水线 备机汇集多个事务的binlog一次性写入relay log文件并且刷盘(fsync)然后发送ACK 需要等待fullsync ACK的语句 所有做binlog事务提交语句 DDL语句,autocommit DML语句 commit,XA COMMIT ... ONE PHASE XA PREPARE

主节点上事务等待Fullsync ACK的细节 等待的内容:本事务已经被足够的备机收到并刷盘,ACK的binlog位置 >= 本事务的binlog位置 等待的方法:不阻塞占用工作线程,挂起会话(THD)直到ACK到来,工作线程继续去处理其他连接的请求 等待ACK 超时后的处理:Fullsync HA更加健壮可靠灵活,即:考虑网络或者IO 随机偶发的抖动,支持选择优先 Consistency 或者 Availability 收到ACK的处理:某个后台工作线程执行目标会话(THD)的事务提交流程中的剩余操作,发送OK包给客户端,客户端语句返回 等待ACK超时的处理:在会话中返回 “fullsync等待超时” 错误给客户端 备机接收binlog的处理逻辑 在磁盘负载、性能以及数据一致性 之间取得平衡 以事务为单位write&fsync binlog fsync:断电或者OS重启后binlog仍然持久保存 ACK:主节点binlog上的一个位置。备机发送ACK:该位置之前的binlog已经持久保存,其所属事务可以返回成功 ACK的发送方法:SQL 语句 或者 扩展的 client API (发送命令) SLAVE server_id CONSISTENT TO file_index offset(general log默认不记录该语句) mysql_send_binlog_ack() (COM_BINLOG_ACK)(更快,但是需要KunlunBase的mysql client lib)
通过批量处理的方式加速了事务提交的速度; 通过异步处理的方式,主节点工作线程无需等待备机ACK,使得主节点处理事务的效率得到加速。



4
Q&A
通过批量处理的方式加速了事务提交的速度; 通过异步处理的方式,主节点工作线程无需等待备机ACK,使得主节点处理事务的效率得到加速。

文章转载自KunlunBase 昆仑数据库,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。
评论
相关阅读
100+项!YashanDB与Oracle全面对比 详解YashanDB如何做到1:1替代Oracle
YashanDB
83次阅读
2025-03-19 11:20:49
中免日上使用阿里云向量检索服务 Milvus 版搭建在线推荐系统
阿里云大数据AI技术
46次阅读
2025-03-11 14:13:34
openGauss 学习之路:集群部署实战探索
openGauss
44次阅读
2025-03-21 10:34:13
迈向云原生:理想汽车 OLAP 引擎变革之路
镜舟科技
36次阅读
2025-04-01 20:22:16
记一次oracle 19c RAC集群重启单节点DB启动异常(一)
Digital Observer
33次阅读
2025-03-11 09:49:53
Redis Cluster集群模式:构建大规模高性能分布式存储系统
老王两点中
29次阅读
2025-03-17 09:00:28
图形数据库Neo4J简介
鲁鲁
28次阅读
2025-03-18 10:31:45
对话泽拓科技赵伟:数据库公司深陷的“自研军备竞赛”,用户真的在意吗?
KunlunBase 昆仑数据库
27次阅读
2025-03-13 09:52:34
GoldenDB 与创新 AWR 报告生成方法:助力分布式数据库高效运维
吾亦可往
26次阅读
2025-03-26 09:42:58
数据库集群技术漫谈
luyingjun
24次阅读
2025-03-29 20:42:10