constzl的博客

AntDB基于PGXC开发，保留了原PGXC的重分布逻辑，本文记录了常见的重分布流程。集群环境coordinator节点：cd1、cd2 datanode节点：dn1、dn2、dn3案例1概述 重分布前 重分布后 重分布CASE 重分布SQL 分片方式 分片函数 分片字段 分片节

AntDB重分布（rebalance）性能对比记录一AntDB集群环境postgres=# table pgxc_node; node_name | node_type | node_port | node_host | nodeis_primary | nodeis_preferred | node_id -----------+-----------+----

AntDB 重分布性能测试记录二 接上篇《AntDB重分布（rebalance）性能对比记录一》，AntDB在重分布方面有优化的空间，本文通过记录一组数据，验证优化方案的可能性。优化方案描述重分布对各个数据节点（datanode）来说，主要包含两个操作：删除不属于自己的数据，这部分数据其他节点需要。插入属于自己的数据，这部分数据可能在其他节点上。由通过插入一张新

比较AntDB Cluster Plan与PGXC Remote Query Plan的区别 AntDB 3.1版本引入Cluster Plan，区别于原PGXC的执行计划，通过Reduce Plan支持数据的实时动态分布，将原本PGXC无法下沉到Datanode执行的执行计划做了优化，使得执行计划的执行压力分散到各个Datanode节点，一方面减轻Coordinator节点的性能压力，另

AntDB日常调试GDB脚本 为了更方便的调试AntDB，生成gdb调试脚本。gdb调试脚本gengdb.sh# !/bin/bash# Author Sunny# Version 2016-11-11function Usage(){ echo "\Help Just keep enum NodeTag which read from

AntDB Reduce死锁与驱动 AntDB的集群计划（Cluster Plan）类似并行计划（Parallel Plan），通过序列化（Serialize）和反序列化（Restore）执行计划（Plan Statement），并发送到各个相关节点（Node），以保证各个节点的执行计划一致（基本一致，Restore时可能略微改动）。 AntDB引入Reduce Plan用于动态

由 MySQL 的 ON UPDATE CURRENT_TIMESTAMP 带来的启发，AntDB 是否可以实现 UPDATE 时自动更新字段值。方案方案1：尝试为需要自动更新的字段自动创建 TRIGGER。方案2：尝试通过 DEFAULT EXPRESSION 来实现字段值的自动更新。实现方案1​ PostgreSQL之时间戳自动更新方案...

分布式集群下数据可见性问题分析记录1. 问题背景介绍 AntDB 3.1在做benchmarksql压测时，一直有个core down 问题。起初一直以为是触发器问题，因触发器的逻辑不太熟悉，一直先紧着别的问题修正。最近定位这个问题时，根据core文件的堆栈信息发现，是foreign key检查的问题。 可通过如下脚本复现该问题。1-1. 集群搭建​ 为...

问题现象最近，一同事执行alter table脚本（表很多，7万多张表），执行完毕后，发现部分表无法访问，报错信息如下：ERROR: could not find tuple for relation xxx通过gdb调试发现，是通过主表查找toast表时出了问题，找不到对应的toast表信息。通过查询pg_class表，发现如下图所示的异常。 如上图所以，pg_class...