苏宁citus架构演进之路

扬帆起航苏宁citus架构演进之路目录l Citus的架构演进l Citus扩容的方案演进l 痛点分享如今的Citus在苏宁支撑了哪些业务 TP业务物流订单的定价、结算业务数据库的性能监控数据 AP业务大数据分析平台金融,物流,商户等的BI分析业务缘起——为了支撑某业务的10倍扩容性能要求高负载类型多样Spark任务分析平台明细表报表维表报表计算200+聚合/min业务系统1业务系统2…抽取明细更新5w/s(400+字段2.5KB/row)90%UPDATE+10%INSERTn扩容前的数据库(DB2)硬件：24C/256GB/4800GBSSD平时：45%CPU利用率大促：80%+CPU利用率(不堪重负！)DB2分布式数据库选型（2017年)方案优点缺点结论Greenplumüüü支持列存支持压缩SQL兼容好üü更新慢并发低不符合明细更新的性能要求postgres_fdw+pg_pathmanüSQL兼容好üüü不支持聚合下推(PG10以后支持)不支持并行查询分片表管理不便不符合明细表查询性能要求PG-XLüSQL兼容好üüüüGTM对性能的影响？稳定性，维护成本？社区不活跃版本更新慢未深入评估citusüüüJustaextension分片表管理方便成功案例较多üü部分SQL不支持不支持全局一致性读基本匹配业务场景最初为了应对业务系统的复杂负载需求,做了如下的一些比较,最终选择了citus初期的部署架构(含连接池)App(普通)App(A普pp通)…worker1worker2PostgreSQLCitus插件PostgreSQLCitus插件CoordinatorPostgreSQLCitus插件pgbouncer(wk1)pgbouncer(wk2)…系统表（元数据)系统表（元数据)系统表（元数据)系统表（元数据)系统表（元数据)系统表（元数据)系统表（元数据)系统表（元数据)系统表（元数据)系统表（元数据)系统表（元数据)系统表（元数据)架构的变更史2017/51CN+4Worker(PG9.6+Citus6.1)1CN+4Worker(PG9.6+Citus7.1)升级1CN+8Worker+2只读CN(PG9.6+Citus7.1)扩容升级1CN+8Worker+2只读CN(PG10.2+Citus7.2)1CN+16Worker+4只读CN(PG10.2+Citus7.2)扩容2018/10(双11前)该系统上线以来成功实施了多次升级和扩容第一套系统已上线数十个系统约1500实例2018年上半年试点阶段开始普及痛点CoordinatorApp(普通)App(A普pp通)…worker1worker2PostgreSQLCitus插件PostgreSQLCitus插件PostgreSQLCitus插件pgbouncer(wk1)pgbouncer(wk2)…workerNPostgreSQLCitus插件不断扩容…出现单CN瓶颈Pgbouncer部署在CN上阻碍分片间通信(分片修复和分片迁移)多CN部署架构PostgreSQLPostgreSQLAApppp((普普通通))App参

考:/ChenHuajun/chenhuajun.github.io/blob/master/_posts/2018-06-11-citus实战系列之四多CN部

署.mdworker1pgbouncerworker2pgbouncerPostgreSQLCoordinator扩展worker(MX

node)pgbouncer扩展worker(MX

node)pgbouncermetadata tb1PostgreSQLworker4pgbouncerPostgreSQLmetadata tb1PostgreSQLmetadata tb1tb1_1tb1_2tb1_3tb1_4…包含元数据包含参考表数据不包含分片表数据实时同步CN的DDL变更扩展worker为可选组件应用通过JDBC多主机URL访问扩展workerjdbc:postgresql://${扩展worker1},${扩展worker2}[,...]/${dbname}?targetServerType=any&loadBalanceHosts=true&…支持DDL

&

DMLPgbouncer在WK节点Citus插件Citus插件Citus插件Citus插件woCrkiteru3s版本升级pgb到oun7ce.r4PostgreSQL支持部追分D加ML了新的节点身份:扩展WK多CN架构的现状

集群规模这套架构上线1年多，截止到2019年双11，已经有311套citus集群（约3000PG实例)，其中大部分是1CN4WK或者8WK的规模，其中规模最

大的几套库，有1个CN节点，3个扩展WK节点和32个普通WK节点

数据量数据量最大的两套库，整个集群的数据总量有30T和15T左右，其他的库

基本单个WK的数据量也在400G左右新的痛点（需求)Coordinator(主)Worker2

(主)Worker1(主)Worker3

(主)Coordinator(备)…Worker1(备)Worker2(备)Worker3(备)Worker4(备)流复制流复制流复制流复制流复制写流量读流量App写业务

读业务Worker备库资源闲置,仅仅是作为HA而已Worker4(主)抽数业务影响交易业务,AP和TP业务在同时跑读写分离的新架构Coordinator(主)Worker2

(主)Worker1(主)Worker3

(主)Worker4

(主)Coordinator(备)…Worker1(备)Worker2(备)Worker3(备)Worker4(备)流复制流复制流复制流复制写流量读流量App写业务App读业务CN通过PG流复制保持数据

同步，那么如何在一份元

数据的前提下，实现CN备

库到WK备库流量划拨呢?流复制/etc/hosts主机名称映射通过在/etc/hosts中配置主机名的映射来先实现CN备库到WK备库流量的划拨CN主库#

citus集群各WK主库的IPcitus_wk1xxx.xxx.xxx.xxxcitus_wk2

xxx.xxx.xxx.xxx...CN备库#

citus集群各WK备库的IPcitus_wk1xxx.xxx.xxx.xxxcitus_wk2

xxx.xxx.xxx.xxx...Citus元数据1

|1

|citus_wk1

|6432

|default

|f|t|primary|

default2

|2

|citus_wk2

|6432

|default

|f|t|primary|

defaultCN主备节点上的元数据均为下面的形式,nodename中以主机名来代替早期架

构中使用的vippostgres=#select*frompg_dist_node;nodeid|groupid| nodename |nodeport|noderack|hasmetadata|isactive|noderole|nodecluster----------+-----------+------------------------+-------------+--------------+-------------------+------------+------------+-----------------1

|1

|

|6432

|default

|f|t|primary|

default2

|2

|

|6432

|default

|f|t|primary|

default主备库分别识别各自映射的WKippostgres=#select*frompg_dist_node;nodeid|

groupid| nodename |nodeport|noderack|hasmetadata|isactive|noderole|

nodecluster----------+-----------+------------------------+-------------+--------------+-------------------+------------+------------+-----------------新架构支持跨机房部署CN(主)WK1(主)WK1(中继)WK2(中继)CN(备)WK1(备)WK2(备)WK1(备)WK2(备)流复制流复制WK2

(主)流复制流复制流复制CN(中继)CN(备)流复制写流量读流量/etc/hostscitus_wk1

citus_wk2

/etc/hostscitus_wk1

citus_wk2

机房1机房2目录l Citus的架构演进l Citus扩容的方案演进l 痛点分享扩容（基于物理复制)适用架构

目前的三种架构均可使用这种方案扩容适用条件每个WK上的分片数必须是2的整数倍扩容后的WK数量是扩容前的2倍扩容步骤预先将删除冗余分片sql分发到各WK计算分片的分布逻辑流复制全量备份WK1和2的数据每个WK保留一半的分片WK1(备)WK1(主)shard_1Shard_3Shard_5Shard_7WK2(备)WK2(主)shard_2Shard_4Shard_6Shard_8WK3(备)shard_1Shard_3Shard_5Shard_7WK4(备)shard_2Shard_4Shard_6Shard_8扩容步骤WK1(备)WK1(主)shard_1Shard_3Shard_5Shard_7WK2(备)WK2(主)shard_2Shard_4Shard_6Shard_8WK3(主)shard_1Shard_3Shard_5Shard_7WK4(主)shard_2Shard_4Shard_6Shard_8停止业务访问数据库停止所有CN和Worker备库

提升新Worker为"主”恢复业务读写DROP新老Worker上的冗余分片修改元数据添加新Worker到Citus集群--

更新分片表已迁移到新worker的shard位置updatepg_dist_shard_placement…--

插入参考表在新worker上的shard位置insertintopg_dist_shard_placement…selectmaster_add_node($worker_ip,$port);select

master_add_node($worker_ip,$port);…回退步骤提升扩容前的所有备库为主库起动扩容前的所有备库停止扩容前的所有主库恢复业务访问恢复备库WK1(旧主)WK2(旧主)WK2(新主)shard_2Shard_4Shard_6Shard_8WK3(主)shard_1Shard_3Shard_5Shard_7WK4(主)shard_2Shard_4Shard_6Shard_8重建备库重建备库WK1(新主)shard_1Shard_3Shard_5Shard_7优势与不足优适

用

目

前

所

有

的

架

构ü物

理

复

制

可

以

保

证

数

据

准

确

性ü回退速度快，

且可保证能恢复到扩容前的状态劣对机器资源需求很大（

必须成倍扩容)扩容步骤繁琐，

手动操作出错的概率高业务需要短时间停机，

且只能扩容不能缩容需要业务停读写，

不够平滑解决方案——基于逻辑复制的分片迁移策略

用PG的逻辑复制同步数据，省去物理复制带来的配置变更等操

作

迁移粒度从整库迁移缩小到表级别，对业务影响更小，风险更

可控

业务可连续运行，仅在变更元数据的瞬间有锁表（访问排他锁)

自定义元数据记录迁移状态，便于平台管理迁移任务新的方案能做什么

任意数量的WK节点扩容

集群缩容WK节点的迁移（遇到虚机故障，磁盘资源不足等等情况)

集群内分片的再平衡一次迁移任务的流程开启任务创建一个分片迁移任务将新WK节点加入到集群中任务管理结束任务selectmaster_add_node($worker_ip,$port);select

master_add_node($worker_ip,$port);sn_create_rebalance_job()sn_start_shard_migration_task(jobid,taskid)sn_complete_shard_migration_task(jobid,taskid)sn_task_cleanup(jobid,taskid)sn_monitor_shard_migration_task(jobid,taskid)sn_cancel_shard_migration_task(jobid,taskid)监控迁移进度取消迁移任务任务出错后的重试环境清理变更citus元数据清理旧分片副本变更迁移任务的元数据WK数据迁移场景再平衡场景缩容场景创建迁移任务逻辑（再平衡场景下)每个WK上的分片按亲和关系分组，互相亲和的分片捆绑一起迁移计算每个WK上分片数的均衡值，算法：分片数/WK数<=WK上分片数<=(分片数+WK数-1)/WK数WK上分片数大于均衡值的就是迁移源WK，小于均衡值的则为迁移的

目标WK生成的迁移任务写入任务元数据表（pg_citus_shard_migration)中，

用于管理限制PG逻辑复制本身的限制（replicaid，HA切换后的管理，复制

延迟，PG10不支持truncate)

分片表名长度的限制（PG限制63字节，分片之后有shardid后

缀，表名长度被进一步压缩)

同源/同目的的迁移任务不可并行（实现工具的限制，未来可解)

有迁移任务的情况下，不可再创建分片表，不可执行变更现有

分片表的DDL（用事件触发器实现)目录l Citus的架构演进l Citus扩容的方案演进l 痛点分享Pgbouncer后端连接不足原因：业务有不带分片字段的查询或者更新（

抽数，

导数这类业务)，citus默认的执行

器（real-time)会对每个分片建一个连接。通常这类SQL执行时间也较长，

当有

多个并发的时候，

就出现pgbouncer后端连接不足的情况。解决：1. 改大pgbouncer后端连接数的配置2. 尽可能让SQL带上分片字段.用读写分离的新架构.新版citus支持adapterexecutor有所改进查询的中间结果集过大问题:ERROR:theintermediateresultsizeexceedscitus.max_intermediate_result_size(currently1048576kB)影响:业务每2个小时下载一次数据集，因为临近双11，数据量增大，出