参与

最近在做大数据和容器的工作,晚些时间再回归到citus。大家可以注册帐号进行更新。

9.3 版本主要升级内容

协调器节点向worker连接时,若是瞬间业务量比较大,会出现达到最大连接数的错误,不太友好。

9.3 版本修复了这个问题,新增如下参数进行控制

citus.max_shared_pool_size(int)
允许连接到每一个worker节点的连接数量,默认 0

0:自动设置。即不会出现超过最大连接数错误的。
-1: 禁用该功能
其他:设置为该值

自动设置时,会将协调器节点的max_connections作为连接数的参考指标,因此协调器与worker的内存和最大连接数不一致的时候,自动设置的功能便不适合。

强制删除Citus节点

在某些情况下,比如worker节点宕机等情况发生时,允许丢失部分数据,以使服务可用时可能会用到。

  • 删除节点报错
test=# select master_remove_node('localhost', '1602');
ERROR:  you cannot remove the primary node of a node group which has shard placements
  • 查询节点的groupid
test=# select * from pg_dist_node;
 nodeid | groupid | nodename  | nodeport | noderack | hasmetadata | isactive | noderole | nodecluster | metadatasynced | shouldhaveshards 
--------+---------+-----------+----------+----------+-------------+----------+----------+-------------+----------------+------------------
      1 |       1 | localhost |     1601 | default  | f           | t        | primary  | default     | f              | t
      2 |       2 | localhost |     1602 | default  | f           | t        | primary  | default     | f              | t
(2 rows)

  • 删除关联信息
test=# delete from pg_dist_placement where groupid = 2;
-- 这个地方在删除前,也可以把pg_dist_placement备份一下
-- pg_dist_shard 最好也删除一下,要不全表扫描的时候也会报错
  • 删除节点
test=# select master_remove_node('localhost', '1602');
 master_remove_node 
--------------------

(1 row)

PostgreSQL容灾和新型两地三中心

本文将简诉PostgreSQL容灾方案,新型两地三中心的方案

PostgreSQL容灾方案

容灾可以选择同步或是异步模式。同步模式下无丢失数据风险,会损失一点点性能。异步模式下,会少量丢失数据,不会损失性能。

通常的方案(同步/异步模式均可):

  1. 一主一备流复制 ...Read more...

LSN 和 Wal日志的相关性

LSN 和 Wal日志的相关性

LSN :Log Sequence Number

  • 查看当前LSN
test=# select pg_current_wal_lsn();
 pg_current_wal_lsn 
--------------------
 1/37000140
(1 row)

  • LSN 组成
    Datum
    pg_lsn_out(PG_FUNCTION_ARGS) //保留主要内容
    {
      XLogRecPtr  lsn = PG_GETARG_LSN(0); // typedef uint64 XLogRecPtr;
      uint32      id,
                  off;
    
      /* Decode ID and offset */
      id = (uint32) (lsn >> 32);
      off = (uint32) lsn;
    
      snprintf(buf, sizeof buf, "%X/%X", id, off);
    }
    

    LSN 由64位(8字节)数据类型表示,ID 和 offset 各用 32bit。我们清晰的知道了 / 分割线的意义。 ID使用32bit(4字节)表示, offset使用32bit(4字节)表示 ...Read more...

cluster table using index 根据索引重排表的物理存储顺序

最近家里有些事情,才开始进行更新

重排表物理存储顺序

语法

CLUSTER [VERBOSE] table_name [ USING index_name ]
CLUSTER [VERBOSE]

描述

根据索引的信息,编排表的物理存储顺序。操作是一次性的,意味着当操作结束后,新产生的数据,不会进行编排,当表依据索引进行编排后,PostgreSQL会记录该索引,当执行 CLUSTER table_name 时,会自动引用先前的索引。当 CLUSTER 不加任何参数时,会对该数据库下该用户的所有表(编排过的表)进行编排,若是超级用户,则会对所有表进行编排。此操作不能在事务中使用。操作过程中会加 ACCESS EXCLUSIVE 锁。

作用

当随机只读取一条记录时,表的物理存储顺序是不重要的。如果你访问很多数据并通过索引分组,或是根据索引键进行范围查询,或是一个索引有多条记录,重编排数据会很有用,因为当根据索引读取表的第一条数据时,其他所需数据也存在于改page中,这节省了磁盘和内存的使用,从而提高性能。

该 CLUSTER 会根据统计信息等内容选择索引扫描或顺序扫描对表数据进行重排序。

当根据索引进行扫描,会对表数据和索引数据进行临时copy处理,因此磁盘需要table size+index size的空间进行临时数据存储。

当进行顺序扫描时,会产生排序的临时文件,因此需要 table size * 2 + index size的空间进行临时数据存储,当然可以使用 enable_sort 禁止使用次方法。

示例

test=# create table aa(id int primary key);
CREATE TABLE
test=# select relname,relfilenode from pg_class where relname ~ 'aa';
 relname | relfilenode 
---------+-------------
 aa      |       33007
 aa_pkey |       33010
(2 rows)

test=# cluster aa using aa_pkey ;
CLUSTER
test=# select relname,relfilenode from pg_class where relname ~ 'aa';
 relname | relfilenode 
---------+-------------
 aa      |       33012
 aa_pkey |       33015
(2 rows)
-- relfilenode发生了改变