关于数据库:分布式1024节点1天玩转PolarDBX超大规模集群

40次阅读

共计 5616 个字符，预计需要花费 15 分钟才能阅读完成。

架构简介

PolarDB-X 采纳 Shared-nothing 与存储拆散计算架构进行设计，零碎由 4 个外围组件组成。

  • 计算节点（CN, Compute Node）计算节点是零碎的入口，采纳无状态设计，包含 SQL 解析器、优化器、执行器等模块。负责数据分布式路由、计算及动静调度，负责分布式事务 2PC 协调、全局二级索引保护等，同时提供 SQL 限流、三权分立等企业级个性。
  • 存储节点（DN, Data Node）存储节点负责数据的长久化，基于多数派 Paxos 协定提供数据高牢靠、强统一保障，同时通过 MVCC 保护分布式事务可见性。
  • 元数据服务（GMS, Global Meta Service）元数据服务负责保护全局强统一的 Table/Schema, Statistics 等零碎 Meta 信息，保护账号、权限等平安信息，同时提供全局授时服务（即 TSO）。
  • 日志节点（CDC, Change Data Capture）日志节点提供齐全兼容 MySQL Binlog 格局和协定的增量订阅能力，提供兼容 MySQL Replication 协定的主从复制能力。

开源地址：[https://github.com/polardb/polardbx-sql]

试验阐明

PolarDB- X 在 22 年 11 月份，公布开源 v2.2 新版本，这是一个重要的里程碑版本，重点推出合乎分布式数据库金融规范下的企业级和国产化适配，共包含八大外围个性，全面晋升 PolarDB-X

分布式数据库在金融、通信、政务等行业的普适性。版本公布文档：PolarDB-X v2.2: 企业级和国产 ARM 适配 开源重磅降级分布式数据库最重要的个性就是线性扩大，目前 PolarDB- X 现有用户生产部署有 64~256 节点的规模，思考将来 5~10 年的倒退诉求，冀望分布式能至多撑持 4~5 倍的容量扩大，因而咱们须要验证下分布式下更大规模的扩展性。

本试验次要通过 polardbx-operator，借助阿里云 ACK 容器服务，疾速部署和体验 PolarDB- X 的大规模分布式 (1024 节点)，通过常见的 sysbench/tpc- c 等 benchmark 工具来初步验证大规模节点下的稳定性。

部署架构

阐明：

PolarDB- X 采纳存储计算拆散的架构，CN 和 DN 是能够独立部署，本实验设计部署 1024 个 DN 节点，比方私有云 PolarDB- X 单个 DN 节点可反对 3TB，那超大规模节点下可反对 1024 * 3TB = 3PB 本实验设计为了可低成本的复现，节点规格上采纳了压缩部署的模式，比方 DN 节点抉择了最小的 1C8GB (1024 节点下也须要 8TB 的内存)，通过 k8s 的多租户 cgroup 技术，采纳 24 台高配 ECS 进行部署，单个 ECS 均匀须要承载 40+ 的 PolarDB-X CN/DN 节点。本实验所须要的测试资源的老本，24 台 ECS 按量付费 288 元 / 小时，测试工夫 1 天左右，预计破费 7000 元。

1. 部署 k8s 集群 (阿里云 ACK)

创立 ACK 托管 (k8s 集群)

创立集群节点池 (24 个高配 ECS 节点)

k8s 集群配置

通过 kubectl get nodes，返回了 ECS 集群列表，阐明 k8s 环境已装置结束

主机参数配置

批改 sysctl.conf 和 limits.conf 的内容。倡议通过 ansible 工具对每个主机进行批改。

sysctl.conf

配置内容：

net.ipv4.neigh.default.gc_stale_time=120

# see details in https://help.aliyun.com/knowledge_detail/39428.html
net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.default.arp_announce = 2
net.ipv4.conf.lo.arp_announce=2
net.ipv4.conf.all.arp_announce=2

# see details in https://help.aliyun.com/knowledge_detail/41334.html
net.ipv4.tcp_max_tw_buckets = 5000
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 1024
net.ipv4.tcp_synack_retries = 2

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

kernel.sysrq=1

net.core.somaxconn = 256
net.core.wmem_max = 262144

net.ipv4.tcp_keepalive_time = 20
net.ipv4.tcp_keepalive_probes = 60
net.ipv4.tcp_keepalive_intvl = 3

net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_fin_timeout = 15

#perf
kernel.perf_event_paranoid = 1

fs.aio-max-nr = 1048576

将文件保留为 /etc/sysctl.conf，而后执行

sysctl -p /etc/sysctl.conf

limits.conf

配置内容：

#*               hard    rss             10000
#@student        hard    nproc           20
#@faculty        soft    nproc           20
#@faculty        hard    nproc           50
#ftp             hard    nproc           0
#@student        -       maxlogins       4

# End of file
root soft nofile 655350
root hard nofile 655350

* soft nofile 655350
* hard nofile 655350
* soft nproc 655350
* hard nproc 655350

admin soft nofile 655350
admin hard nofile 655350
admin soft nproc 655350
admin hard nproc 655350

alidb soft nofile 655350
alidb hard nofile 655350
alidb soft nproc 655350
alidb hard nproc 655350

将文件保留到 /etc/security/limits.conf

2. 装置 polardbx-operator

helm repo add polardbx https://polardbx-charts.oss-cn-beijing.aliyuncs.com
helm install --namespace polardbx-operator-system --set imageRepo=docker.mirrors.sjtug.sjtu.edu.cn/polardbx polardbx-operator polardbx/polardbx-operator

3. 创立 polardb-x 实例

将以下内容保留为 polardbx.yaml 文件 kind:

PolarDBXCluster
metadata:
  name: p1024
spec:
  config:
    cn:
      static:
        EnableCoroutine: true
        RPCProtocolVersion: 2
        ServerProperties:
          galaxyXProtocol: 0
      dynamic:
        TRANSACTION_POLICY: TSO
        CONN_POOL_XPROTO_STORAGE_DB_PORT: 0
        CONN_POOL_XPROTO_MAX_CLIENT_PER_INST: 8
        CONN_POOL_XPROTO_MAX_SESSION_PER_CLIENT: 256
        CONN_POOL_XPROTO_MIN_POOLED_SESSION_PER_INST: 32
        CONN_POOL_XPROTO_MAX_POOLED_SESSION_PER_INST: 128
        XPROTO_MAX_DN_WAIT_CONNECTION: 1000
        XPROTO_MAX_DN_CONCURRENT: 2000
        RECORD_SQL: "false"
        SHARD_DB_COUNT_EACH_STORAGE_INST: 1
        MPP_METRIC_LEVEL: 0
  topology:
    rules:
      components:
        dn:
          rolling:
            replicas: 1
    nodes:
      gms:
        template:
          image: docker.mirrors.sjtug.sjtu.edu.cn/polardbx/polardbx-engine:80-8.0.18-20221208170957
          hostNetwork: false
          resources:
            limits:
              cpu: 16
              memory: 32Gi
          imagePullPolicy: IfNotPresent
      cn:
        replicas: 16
        template:
          image: docker.mirrors.sjtug.sjtu.edu.cn/polardbx/polardbx-sql:5.4.15-20221129135549
          hostNetwork: false
          resources:
            limits:
              cpu: 16
              memory: 16Gi
          imagePullPolicy: IfNotPresent
      dn:
        replicas: 1024
        template:
          image: docker.mirrors.sjtug.sjtu.edu.cn/polardbx/polardbx-engine:80-8.0.18-20221208170957
          hostNetwork: false
          resources:
            limits:
              cpu: 1
              memory: 8Gi
          imagePullPolicy: IfNotPresent
      cdc:
        replicas: 2
        template:
          image: docker.mirrors.sjtug.sjtu.edu.cn/polardbx/polardbx-cdc:5.4.15-2022110310
          hostNetwork: false
          resources:
            limits:
              cpu: 16
              memory: 16Gi
          imagePullPolicy: IfNotPresent

执行创立命令：

kubectl apply -f polardbx.yaml

可通过如下命令查看创立进度：

kubectl get pxc -w

创立实现后，可参考 连贯 PolarDB- X 数据库 连贯数据库 阐明：如果遇到个别节点 POD 长时间创立不进去，能够尝试 kubectl delete pod xx 触发从新创立

4. 数据库体验和压测

PolarDB- X 提供了 benchmark 一键压测工具，可参考文档：应用 Benchmark Boot 进行压测

一键装置命令：

在前端机器的浏览器上，拜访 http://{前端机器 IP}:4121/，呈现 Benchmark-Boot 首页，证实部署胜利。参考 benchmark boot 工具的操作指南，通过页面实现：配置数据库连贯 -> TPCC 数据导入 -> TPCC 压测

失常的 TPC- C 运行日志

show stats 查问运行指标，均匀 RT 在 0.67ms，体现比拟安稳

数据库验证体验项：

阐明：本试验采纳了 24 台 ECS 部署，并非关注性能摸高，重点模仿 1024 节点下的数据库稳定性，比方 30~50 万 tps 下的均匀 rt、以及 12 小时的低压长稳测试，仅供用户参考和复现试验操作。

图 4.1

图 4.2

图 4.3

图 4.4

图 4.5

总结

分布式数据库主打线性扩大的能力，能够在满足 OLTP 高并发下提供海量 PB 级别的存储能力，在超大规模的集群架构下会带来蛮多技术挑战，比方：

元数据收缩。治理大规模的 1024 个物理节点，须要关注节点高可用、以及元数据的存储，比方分布式的 DAL、DDL，在工作执行上下文以及分布式聚合时会带来更大的内存开销。比方，batch insert 场景下的分布式事务，会波及 1024 个节点的分支事务管理，分布式事务的上下文和并发提交都会带来肯定的挑战。

TCP 连贯风暴。分布式 share-nothing 架构，不可避免会产生数据分片路由和转发，这里就会波及节点之间的相互拜访，比方 PolarDB- X 每个 CN 节点都要和 DN 节点建设 RPC 申请，在低压并发下节点之间须要 RPC 的连接池来晋升性能 (比方 8~16 个 TCP 连贯)，通过 1024 个 DN 节点的放大，每个 CN 节点可能会呈现几万的 TCP 连贯，须要对 RPC 连贯进行无效治理。本试验中，PolarDB-X CN 配置 16GB 的内存来撑持 1024 节点的 RPC 连贯。

分布式并发死锁。分布式下不带分片条件的查问，因为无奈命中分区裁剪，会带来全分片的查问 (简称为：跨分片查问)。比方 10 个并发的跨分片查问，通过 1024 个 DN 节点的放大，会产生刹时几万的分片并发查问，简单的并发申请会产生相互期待的并发死锁的状况，造成更大的爆炸半径。比方，DDL 操作的 MDL 锁获取，会因为个别长事务未提交而始终卡主，进一步阻塞后续其余的 SQL，因为跨分片查问下的个别查问被锁住，在大规模节点下容易放大影响。

CDC 多流日志合并。分布式数据库会通过 CDC 组件，向上游提供相似 mysql binlog 的机制，技术实现上都须要采集集群中的所有节点日志，进行采集和归并解决。通过 1024 个 DN 节点的放大，本来 1024 分之的归并排序无奈满足性能和稳定性要求，须要引申出多流归并、以及内存 swap 机制。

实际是测验真知的唯一标准，通过本试验的设计，联合阿里云的云服务，能够疾速且低成本的验证 PolarDB- X 在超大规模 1024 节点，在百万级别的 TPS 下满足业务应用的稳定性。

作者：七锋、不俗

原文链接

本文为阿里云原创内容，未经容许不得转载。

正文完
数据库
发表至： 数据库
2023-03-07
 0
关于数据库:OpenMLDB-v08-新功能离线引擎数据源支持-Amazon-S3
关于数据库:大咖说图书分享｜数字化转型架构方法论与云原生实践
关于数据库:白鲸开源贡献-Apache-SeaTunnel-Web-界面
关于数据库:峰会回顾-阿里云与StarRocks合作开放共赢