PolarDB-X企业版物理机部署实战：Paxos三副本与组件初始化指南

看到这个标题大概率是准备在物理机或者自建机房环境里把 PolarDB-X 企业版老老实实跑起来。公有云上点几下滑鼠就能开集群但到了线下环境所有东西都得自己编排组件依赖、网络规划、初始化顺序一个搞错就得回头排查半天。这篇东西就按我实际部署的经验来写把那些文档里没细说、但实操一定会撞上的点捋一遍。1. 为什么部署 PolarDB-X 企业版先要把“Paxos 三副本”这条主线想清楚很多第一次部署分布式数据库的人容易被一堆名词搞晕——GMS、CN、DN、CDC每个都是英文缩写看着像好几个独立产品。实际上它们都是一个分布式集群里的不同角色而整条部署链路的主线就是围绕Paxos 多副本展开的。先把这个架构用大白话拆开。GMSGlobal Meta Service集群的大脑负责全局元数据管理、DDL 调度、崩溃恢复等。它自己也是一个独立的 Paxos 组通常部署三副本。CNCompute Node计算节点就是 SQL 入口负责解析、优化、分发请求到后端存储。CN 是无状态的可以横向加节点。DNData Node数据节点真正存数据的地方。每个 DN 分片也不是单点内部同样是三副本 Paxos。CDC负责生成全局一致性的 Binlog供下游消费或数据同步用。物理机部署的核心逻辑很简单列表里每个角色不是一台机器而是一个 Paxos 组。GMS 三台一组每个 DN 分片三台一组。所以规划资源的时候不能按“角色数”算机器要按“Paxos 组数乘以副本数”算。这也是很多人第一次部署时最容易翻车的地方以为一个集群 GMS 一台 CN 两台 DN 两台实际跑起来才发现少了 Paxos 那套多数派机制整个集群根本起不来或者起了也经不起任何一台机器宕机。企业版和社区版最大的不同不只是多了商业化组件而是它的部署方式更偏“可运营”——带可视化的管控、监控、备份恢复等能力。但这些能力恰恰要求底层 Paxos 组初始化得干净、节点角色划分得清晰。所以动手之前先在纸上把“哪台机器充当哪个角色的哪个副本”画清楚比急着敲命令重要得多。2. 拓扑规划端口、资源、网络延迟三件事让后面的故障少一半部署分布式数据库最怕的不是不会敲命令而是机器资源乱配、端口互相打架、网络延迟超标。这三件事在初始化阶段就要定死。2.1 角色与端口规划提前锁死禁止默认以企业版 3.x 的常见约定为例不同版本端口可能有差异但规划逻辑是一样的。我习惯的做法是先把每台机器的角色、内网 IP、端口列成一张表贴在部署环境旁边后面所有配置都以这张表为准。角色默认端口说明建议GMS3306集群元数据库端口三副本互通不建议改周边组件默认都记这个端口CN8522SQL 接入端口应用连接用这个可自定义但要确保安全组放通DN3306每个分片的数据端口三副本互通与 GMS 互不影响但同一机器上端口不能冲突CDC4885全局 Binlog 服务端口专门留给同步链路我见过一个线上事故三台机器上既跑了 GMS 又跑了 DN结果初始化时把 DN 的端口误配成 3307后续所有心跳检查都异常日志里全是连接超时。最后就是重新初始化才解决。所以端口表一定要提前定死别默认。2.2 资源配比别让 CN 吃满内存DN 反而饿死分布式数据库的资源分配和传统单机 MySQL 完全不同。CN 做计算、缓存、连接管理是内存大户DN 做存储是磁盘 IO 大户。如果一台物理机上同时放 CN 和 DN要特别注意资源隔离。我的建议配比按一台物理机 64C/256G 内存为例单台机器只跑一种角色是最稳的。必须混部时CN 最多分到 40% 内存DN 分到 50% 以上剩下留给 OS。磁盘必须 SSD/NVMeDN 的 Paxos 日志和 Binlog 对 IO 延迟极敏感机械盘跑三副本几乎必出同步延迟告警。提示PolarDB-X 的 Paxos 多数派机制对网络延迟要求很高。GMS 三副本之间的 RT往返时延如果超过 5ms底层就会频繁出现选主抖动。跨机房部署风险极高同机房内网才是合理选择。2.3 操作系统前置项这几条不做后面日志全是坑系统层面有些配置虽然不起眼但漏了之后问题会非常隐蔽时钟同步所有机器必须配置 NTP/Chrony三副本间时间差超过阈值Paxos 选主会直接失败。文件句柄上限ulimit -n至少要 65535否则高并发时连接数一上来句柄不够报错就像随机故障。swap 策略vm.swappiness建议调低5 左右尤其是 DN 节点swap 频繁换页会导致 IO 抖动触发 Paxos 心跳超时。网卡 IRQ 绑定高负载业务建议把网卡中断分别绑到不同 CPU 核上避免单核打满。这一步做不做Sysbench 压测时能差 20% 以上。这些前置项做完拓扑规划这块才算合格。接下来才能碰初始化命令。3. GMS 元数据集群初始化实操GMS 是整个集群的大脑初始化顺序必须是第一优先。它起不来后面所有的 CN、DN 都注册不了。3.1 安装包与目录结构企业版安装包一般以 tar.gz 提供解压后会包含bin/、conf/、tools/等目录还有一个部署脚本名称可能随版本变比如install.py或deploy.sh。拿到包先别急着跑先做两件事确认安装包 md5防止传输损坏。阅读包内的docs/或README确认依赖的 JDK 版本、Python 版本以及是否依赖特定的 glibc 版本。企业版常会附带自己的 JDK避免系统 JDK 版本不一致导致启动崩溃。解压tar -zxvf polardb-x-enterprise-3.x.x.tar.gz -C /opt/polardb-x cd /opt/polardb-x3.2 初始化 GMS 三节点假设三台 GMS 机器的主机名分别为gms01、gms02、gms03内网 IP 为10.0.0.11、10.0.0.12、10.0.0.13执行初始化命令的形式大致如下./install.py --role gms \ --cluster-id polardbx_cluster_demo \ --hosts 10.0.0.11,10.0.0.12,10.0.0.13 \ --port 3306 \ --root-password YourStrongPassword注意几个参数的含义--cluster-id给整个集群起一个逻辑 ID后面 CN、DN、CDC 注册时全要用它相当于集群的“家族姓氏”务必一次定好不要带特殊字符。--hosts三个 IP 的顺序要固定它决定 Paxos 节点的优先级。第一台就是 Initial Leader 候选后面涉及灾备策略时这台的地位要特殊对待。--root-password初始化时会生成根账号密码务必用强密码并且初始化完成后通过加密方式保存。3.3 验证 Paxos 状态初始化完成后别急着部署下一层。先验证 GMS Paxos 组是否健康。通常可以连接 GMS 的 3306 端口执行SHOW GLOBAL STATUS LIKE paxos%来查看状态或者看日志里是否出现“paxos has elected a leader”字样。验证命令示例mysql -h10.0.0.11 -P3306 -uroot -pYourStrongPassword -e SHOW GLOBAL STATUS LIKE %paxos%;重点关注几个指标paxos_role当前节点是 Leader 还是 Follower。paxos_commit_times提交次数是否持续增长。三台机器上各执行一次确认只有一个 Leader另外两台是 Follower。如果出现多个 Leader或者没有一个节点成为 Leader大概率是网络延迟或时钟漂移问题。这时候不要去改配置重启先把三台机器之间的 ping 时延和时钟差都测一遍。3.4 初始化失败的常见排查链路初始化失败是新手最容易耗费整晚的问题。我梳理一个排查顺序先看安装包日志目录下的gms.log和install.log找“ERROR”字样。如果日志里有connection refused检查端口是否被防火墙挡住或者 selinux 是否拦截。如果日志里有paxos timeout优先查网络延迟和时钟同步而不是查配置。如果初始化中途失败再次初始化前必须清理现场——删掉数据目录、日志目录、残留进程否则第二次初始化会因为已有元数据而冲突。经验GMS 初始化最可能失败的环节其实是“三台机器之间的免密/互信没打通”。很多部署脚本初始化 Paxos 时要求节点之间能互相通过 SSH 访问提前在所有机器上配好ssh-copy-id能省掉一半报错。4. DN 数据节点初始化与分片设计的几个关键决策GMS 起来了接着就是数据面——DN。这是真正存数据的地方也是后续容量规划最需要动脑子的一环。4.1 单个 DN 分片的初始化DN 的初始化思路和 GMS 类似一个分片就是一个三副本 Paxos 组。假设第一个分片三台机器是dn01、dn02、dn03./install.py --role dn \ --cluster-id polardbx_cluster_demo \ --shard-id shard_001 \ --hosts 10.0.1.21,10.0.1.22,10.0.1.23 \ --port 3306 \ --meta-host 10.0.0.11 --meta-port 3306 \ --root-password YourStrongPassword这里多出来的参数是--meta-host和--meta-port指向 GMS 的地址。DN 初始化完成后会自动向 GMS 注册自己并且上报自己的存储容量、Paxos 角色等元数据。初始化好一个分片后同样要验证 Paxos 状态。如果后续要扩容分片就按同样的方式初始化第二个shard_002、第三个shard_003……有多少数据量就先准备多少个分片。4.2 分片数量与拆分键部署时就该想明白很多人把 PG 上的“分布式部署”误解成“装完软件就行”实际上DDL 怎么写、拆分键怎么选直接决定了集群后续能不能扛住流量。在 PolarDB-X 里创建一个分布式逻辑表时必须指定拆分键CREATE TABLE orders ( order_id bigint NOT NULL, user_id bigint NOT NULL, amount decimal(10,2) DEFAULT NULL, create_time datetime DEFAULT NULL, PRIMARY KEY (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 PARTITION BY HASH(order_id) PARTITIONS 16;这条语句背后的含义是按照order_id做 Hash 拆分把数据分散到 16 个物理分片。拆分键的选择有几个经验优先选高基数、分布均匀的字段比如订单 ID、用户 ID。千万不要选只有几个枚举值的字段做拆分键比如status、gender否则数据会全部堆到某一个分片上出现“数据倾斜”整个集群只有一个节点在忙其余节点空闲。如果表有主键拆分键通常就是主键或主键的前缀这样可以保证查询能精确定位到分片避免全表扫描所有分片。4.3 建库、建表后的数据分布检查做完初始化和建表之后建议用一条 SQL 验证数据分布是否均匀SHOW SHARDS FROM orders;这条命令会展示每个分片的位置、状态、大小等。如果某个分片的大小异常大说明拆分键选得有问题趁生产流量还没进来改表还来得及。等跑了几个月再改拆分键就要做在线迁移复杂度完全不是一个量级。5. CN 计算节点接入让 SQL 能路由到正确的地方GMS 和 DN 都就绪数据有了存放地接下来要加一个“翻译官”——CN 计算节点让应用通过 MySQL 协议发 SQL被正确路由到对应分片。5.1 注册并启动 CN初始化 CN 的命令大概长这样./install.py --role cn \ --cluster-id polardbx_cluster_demo \ --hosts 10.0.2.31 \ --port 8522 \ --meta-host 10.0.0.11 --meta-port 3306 \ --cpu-nums 16 --mem-size 64CN 启动后会主动向 GMS 注册自己的计算能力。注册完成后应用就可以通过 MySQL 协议连接 CN 的 8522 端口了mysql -h10.0.2.31 -P8522 -uroot -pYourStrongPassword连接成功后执行SHOW DATABASES应该能看到information_schema、__polardbx_catalog__等系统库。__polardbx_catalog__是元数据目录库CN 就是靠它获取所有表的分片拓扑。5.2 多 CN 的注意事项CN 是无状态节点可以水平扩展。加第二个、第三个 CN 时同样执行上面的初始化命令指向同一个 GMS 即可。但这里有个隐藏问题应用连接多个 CN 时需要做连接层面的负载均衡。PolarDB-X 本身不提供 VIP 漂移或接入层负载均衡需要在前端挂一个 LVS/HAProxy/Nginx 四层代理把连接分摊到多个 CN 上。如果写死了单个 CN IP这台 CN 挂了整个应用就断连了。所以生产环境无论如何都要有一个接入层的负载均衡。另外CN 的参数有几个值得关注max_connections单个 CN 能承载的并发连接数默认值通常偏保守需要根据应用连接池大小调大。net_read_timeout/net_write_timeout大查询场景下这些超时时间太短会导致连接被中途掐断报“读写超时”错误。6. CDC 同步链路企业版最容易被忽略的一环CDC 不是必须对所有业务都启用但如果下游有数仓、消息队列或者要做跨集群复制它才是整个链路的出口。部署顺序在 CN 之后但在数据正式写入之前。6.1 初始化 CDC初始化 CDC 需要知道 GMS 的地址和集群 ID本质上是让 CDC 从 GMS 获取全局 Binlog 位点然后持续消费所有分片的变更./install.py --role cdc \ --cluster-id polardbx_cluster_demo \ --hosts 10.0.3.41 \ --port 4885 \ --meta-host 10.0.0.11 --meta-port 3306CDC 初始化完成后需要检查一下同步位点是否在推进。连接 GMS 或 CDC 提供的管理端口执行相关命令查询位点如果位点一直不增长说明下游消费没起来或者拉取链路有故障。6.2 全局 Binlog 与下游消费CDC 对外提供的是全局一致性的 Binlog它把所有分片的 Binlog 按时间戳做了归并排序所以下游从任何一个位置开始消费都能看到全局统一的变更序列。实际使用中下游 Canal、Flink CDC、自研消费程序都可以像连接普通 MySQL Binlog 一样连接 CDC。但要注意CDC 拉取 Binlog 会占用主库的 IO 资源如果分片多、写入大查一下 GMS 的 binlog 拉取延迟指标避免让同步拖垮主链路。7. 上线前验证与一次故障切换复盘所有组件部署完毕之后不是立刻接生产流量而是要做一轮完整的验证同时搞一次故障演练。这一步做好上线后的稳定性会高一大截。7.1 验证清单按照分级校验缺一项都不算部署完成检查项操作预期结果组件状态查看 GMS/CN/DN/CDC 进程是否都在各节点角色明确无孤儿进程Paxos 健康SHOW GLOBAL STATUS LIKE %paxos%每个组只有一个 LeaderFollower 状态正常SQL 路由创建测试表插入数据查询数据数据能正常读写无报错全局 Binlog查询 CDC 位点位点持续增长分片均衡SHOW SHARDS FROM 表名各分片数据量近似均衡连接代理通过负载均衡端口连接 CN连接成功多 CN 之间流量有分发7.2 第一次故障演练宕掉一个 DN 副本我在实际部署中做过一次故障演练直接 kill 掉一个 DN 节点观察集群反应。过程如下确认 GMS 节点已将该 DN 标记为不可用。三副本中剩余两个副本自动协商选出新的 Leader只要不是集群超过半数不可用服务不中断。业务侧观察到少量写入延迟升高约 200~500ms但无连接中断。将宕掉的节点重新拉起数据自动补齐观察SHOW SHARDS确认该分片恢复为健康状态。这个演练验证了 Paxos 多副本的价值也暴露了问题业务侧数据库连接池的闲置连接不够健壮在 Leader 切换的瞬间旧连接返回的错误码没有及时触发重连。后来在应用配置里调低了连接池的connectionTimeout并启用了testOnBorrow有效检查切换期的报错率就降到了零。经验故障演练不是为了证明系统“永远不挂”而是为了提前暴露“挂了之后谁能感知、谁需要人工介入”。建议每次部署完都做一次把结果记录下来配到告警规则里去对照。7.3 日常维护的几个隐藏操作集群上线后日常维护有几个容易忽略的地方内核参数和文件句柄的变更改完必须重启对应角色的进程否则只改系统配置不重启等于没改。备份与恢复策略要提前测不要等出事故了才第一次做恢复演练。PolarDB-X 企业版提供备份工具但备份出来的数据要在测试环境完整恢复一次确认可用。监控大屏不要只看 CPU、内存分布式数据库真正的核心指标是 Paxos 的提交延迟、分片间的延迟差异、Binlog 拉取位点滞后。这几个指标异常往往意味着问题已经开始扩散了。这套部署流程走下来一个基本可用的 PolarDB-X 企业版集群就立住了。整个过程最花时间的其实不是敲那几条初始化命令反而是前期的端口规划、资源配比、网络延迟检查还有后面的故障演练。把这两块做扎实后面维护会省心很多。