Vertica Spread 配置最佳实践

编译：JiangChong

原文：Spread Configuration Best Practices

📝 文章说明：本文基于 Vertica 官方 KB 原文翻译整理。原文仅讨论了 Enterprise 模式下 Spread 的两种控制模式（Broadcast / Pt2pt）、spread.conf 配置和日志管理，未涉及 Eon 模式。译者根据 Vertica v26.2 官方文档 和 vault 已有技术笔记，补充了 Eon 模式下 Spread 架构变化、大集群模式（Large Cluster）在 Eon 子集群中的配置、Spread 分段与分片的关系、Eon 云环境 Spread 配置指南、以及 Enterprise vs Eon 方案对比与决策框架。新增内容位于「Eon 模式下的 Spread 架构与配置」章节。

重要提示：Spread 是 Vertica 数据库管理系统的一个关键组件。手动更改 spread 配置时必须极其谨慎。任何拼写错误或不正确的配置都可能导致数据库无法使用或无法启动/正常运行。

当语句被执行时，Vertica 通过数据通道（data channel）使用 TCP 协议与其他节点通信以传输数据。例如，当查询执行 COPY 语句时，加载并在节点间发送的行由数据通道控制。

Spread 进程使用控制通道（control channel）协调集群中所有节点间的消息和通信。例如，节点状态、查询计划执行和 COMMIT 语句都由控制通道控制。控制通道不协调数据流。

下图展示了这种架构：

Spread 提供节点间关于节点状态的控制消息。由于 Vertica 数据库管理系统基于主动-主动冗余（active-active redundancy）高可用范式，Spread 为数据库管理系统提供了针对性的高可用性（基于 K-Safety 级别）。Spread 通过控制活动进程并可靠地将消息传递给数据库组中所有成员/节点来提供容错能力。

更改通信模式（广播或点对点）

Spread 配置存储在 Vertica 目录（catalog）中，配置的人类可读版本存储在 spread.conf 文本文件中。可以使用更新 spread.conf 文本文件的 Vertica SQL 函数来更改 spread 配置。手动更改 spread.conf 不会持久保存，必须始终避免。

可以将 spread 配置为以两种方式之一运行：使用广播（broadcast）或点对点（point to point）。

UDP 广播

IPv4 广播协议是控制通道的默认配置。在此配置中，节点在目标网络交换机上广播一条消息，并将其分发到所有节点。

要将 spread 控制模式设置为广播，请使用以下语句：

=> SELECT set_control_mode ('broadcast');
 set_control_mode
---------------------------
 Control mode set to broadcast
(1 row)

UDP 点对点

在点对点配置中，拓扑结构与广播相同。但节点可以向每个节点发送带有报头的数据包（IPv4 单播协议），交换机可以将该数据包路由到相应节点。如果交换机上只有 Vertica 节点，此选项可能会产生更多流量。但是，如果交换机上有其他应用或节点，使用此选项可降低数据包丢失的可能性。当节点间网络跳数较多，或目标网络共享而非专用于此任务（例如在云中运行集群）时，更推荐使用点对点模式。

要将 spread 控制模式设置为点对点，请使用以下语句：

=> SELECT set_control_mode ('pt2pt');
 set_control_mode
---------------------------
 Control mode set to pt2pt
(1 row)

更改 Spread 日志配置

Spread 日志记录默认处于禁用状态。为获得最佳效果，请保持 spread 日志记录禁用状态，以便 spread 专注于通信消息。在某些情况下，可能需要启用 spread 日志记录以调试特定问题。

使用以下语句设置 spread 附带参数：

=> SELECT set_spread_options ('logfile', 'debugflags', 'extras');

使用以下语句禁用 spread 日志记录：

=> SELECT set_spread_options('/dev/null/', 'EXIT', 'ExitOnIdle = yes');

使用以下语句启用 spread 日志记录：

=> SELECT set_spread_options('/opt/vertica/log/spread.log', 'MEMBERSHIP PRINT CONFIGURATION GROUPS SESSION EXIT',
'ExitOnIdle = yes');

查看和重新加载 Spread

Spread 使用位于 catalog 文件夹中的 spread.conf 文件。如果更改了 spread 配置，必须生成新的 spread.conf 文件，并重新加载 spread 以使更改生效。

使用以下语句查看 spread 配置的目录视图：

=> SELECT generate_spread_config ();

使用以下语句在发起节点（initiator node）上写出 spread.conf：

=> SELECT write_spread_config('');

使用以下语句重新加载 spread 守护进程：

=> SELECT reload_spread (true);
 reload_spread
---------------
 Reloaded
(1 row)

重新加载 spread 守护进程后，必须停止数据库并重新启动，以使新的 spread 配置生效。

spread.conf

以下是 broadcast 和 point-to-point 模式下 spread.conf 文件的示例条目。

广播模式

注意此示例中有一个 Spread_Segment 向多个节点发送消息：

# 7
# Auto-generated by vertica - do not edit
ActiveIPVersion = IPv4
Spread_Segment 198.51.100.255:4803 {
 N0119851100202    198.51.100.202 {
  198.51.100.202
 }
N0119851100203    198.51.100.203 {
  198.51.100.203
 }
N0119851100204    198.51.100.204 {
  198.51.100.204
 }
N0119851100205    198.51.100.205 {
  198.51.100.205
 }
}
# begin end matter
EventLogFile = /dev/null
EventTimeStamp = "[%a %d %b %Y %H:%M:%S]"
DebugFlags = { PRINT EXIT }
ExitOnIdle = yes

点对点模式

注意此示例中有多个 Spread_Segment 向单个节点发送消息：

# 7
# Auto-generated by vertica - do not edit
ActiveIPVersion = IPv4
Spread_Segment 198.51.100.42:4803 {
 N011985110042    198.51.100.42 {
 198.51.100.42
 }
}
Spread_Segment 198.51.100.59:4803 {
 N011985110059 198.51.100.59 {
 198.51.100.59
 }
}
Spread_Segment 198.51.100.156:4803 {
 N0119851100156    198.51.100.156 {
 198.51.100.156
 }
}
Spread_Segment 198.51.100.189:4803 {
 N0119851100189 198.51.100.189 {
198.51.100.189
 }
}
# begin end matter
EventLogFile = /dev/null
EventTimeStamp = "[%a %d %b %Y %H:%M:%S]"
DebugFlags = { PRINT EXIT }
ExitOnIdle = yes

---

Eon 模式下的 Spread 架构与配置

以上内容基于 Enterprise 模式（所有节点参与 Spread 控制消息传递，通过 buddy projection 实现副本）。Vertica 自 9.x 引入 Eon 模式（计算-存储分离，数据存公共存储），Spread 的角色也随之发生根本性变化——从管理 buddy projection 的节点依赖，转向支撑分片订阅机制下的控制消息传递。本节补充 Eon 模式下 Spread 的架构变化、大集群模式、Spread 分段与分片的关系、以及配置指南。

架构差异：Enterprise vs Eon 下的 Spread

Enterprise 模式下，所有节点的 Vertica 进程通过 Spread 守护进程协调集群成员资格、COMMIT 语句、查询计划执行等控制消息。节点宕机时，Spread 检测到令牌超时后将其从成员资格中移除，K-safety 依赖环（buddy pair）决定集群是否继续运行。

Eon 模式下，Spread 仍然负责集群成员资格和节点间控制消息，但数据保护模型从 buddy projection 变为 分片订阅（Shard Subscription）。这意味着 Spread 成员资格变更的场景解释发生了变化：

维度	Enterprise 模式	Eon 模式
Spread 角色	管理所有节点 + buddy projection 依赖	管理所有节点 + 分片订阅依赖
节点退出后果	buddy pair 相邻宕机 → 数据库 shutdown	分片订阅丢失 → 集群 READONLY
所有节点运行 Spread？	默认所有节点运行；可在 50~80 节点手动启用大集群（仅控制节点运行）；集群 ≥120 节点时自动启用大集群	取决于子集群创建时的配置：≤16 节点所有节点运行；>16 节点创建时自动启用大集群，仅控制节点运行（后续扩容触发的跨阈值不自动启用）
节点关系决定因素	Buddy projection 物理副本分布	分片订阅（Primary/Secondary）分布
控制模式推荐	单子网广播，多子网/云环境点对点	S3/AWS 强制 pt2pt，云环境优先 pt2pt

Eon 模式下分片订阅机制的完整说明见 K-Safety 最佳实践 §Eon 模式章节，分片订阅系统表见 NODE_SUBSCRIPTIONS、SHARDS。

大集群模式（Large Cluster）—— Eon 与 Enterprise 的关键差异

随着集群规模增长，Spread 广播消息的负载呈指数级上升。Vertica 的 大集群模式（Large Cluster） 通过引入 控制节点（Control Node） 概念来应对这一挑战。

什么是大集群模式？

当大集群模式启用后，集群中仅一部分节点（称为 控制节点）直接参与 Spread 消息交换；其余节点（称为 依赖节点 / Dependent Nodes）向一个控制节点注册，通过该控制节点中转控制消息。

大集群禁用（所有节点 = 控制节点）：        大集群启用（仅控制节点运行 Spread）：

  Node1──Spread──Node2                    Node1(dep)           Node2(dep)
    │              │                         │                   │
  Node3──Spread──Node4                    Node3(Ctrl)──Spread──Node4(Ctrl)
                                             │                   │
  所有节点直接参与 Spread Ring               Node5(dep)           Node6(dep)

来源：Vertica 26.2.x Administrator's Guide

Enterprise 与 Eon 的关键差异：

维度	Enterprise	Eon
自动触发阈值	集群 ≥120 节点	子集群创建时 ≥16 节点（每个子集群独立）
控制节点范围	全局（整个集群）	子集群级别（每个子集群有独立的 control-set-size）
依赖节点归属	同 Fault Group 内的控制节点	始终同子集群内的控制节点（维护子集群隔离）
推荐手动启用	50~80 节点（本地）/ 16 节点（云）	16 节点（云环境 pt2pt 模式下 Spread 扩展性更差）
控制节点数默认值（大集群启用后）	总节点数的平方根（如 121 节点 → 11）	子集群节点数的平方根（如 25 节点 → 5）；≤16 节点时所有节点均为控制节点
120 控制节点上限	集群全局上限	集群全局上限（所有子集群合计 ≤120）

Eon 模式大集群的关键行为（来源：v26.2 官方文档）：

1. 创建子集群时若 ≥16 节点，Vertica 自动启用大集群并设置控制节点数为 sqrt(节点数)
2. 可通过 --control-set-size 在 admintools -t db_add_subcluster 时指定控制节点数
3. 若所有子集群控制节点合计已达 120 个，无法再添加新子集群（每个子集群至少需要 1 个控制节点）
4. 依赖节点始终分配在同一子集群内控制节点数最少的那个
5. 主子集群应分配更多控制节点（主子集群维护 K-safety，控制节点故障影响更大）

控制节点故障的影响：

当控制节点宕机时，其所有依赖节点与集群的通信中断，这些依赖节点也被数据库视为宕机。在 Eon 模式下，这可能导致：

• 该控制节点下依赖节点所订阅的分片失去 primary 订阅者 → 触发 READONLY
• 依赖节点上的查询会话全部中断

因此在规划 Eon 集群时，必须确保同一分片的 primary 和 secondary 订阅者不在同一控制节点下（即不共享同一个控制节点），避免单点控制节点故障导致分片订阅丢失。

Spread 分段与 Eon 分片的关系

这是两个不同层面、相互独立的概念：

概念	层面	定义	作用域
Spread_Segment	控制面（Control Plane）	spread.conf 中定义的 UDP 消息传递组，决定节点如何参与 Spread Ring	集群/子集群
Shard（分片）	数据面（Data Plane）	Eon 公共存储上数据的哈希分桶，决定数据在节点间的分布单位	命名空间（Namespace）

Spread 分段配置与 Eon 分片的关系：

• Broadcast 模式：一个 Spread_Segment 包含所有控制节点，消息广播到该段内所有节点
• Pt2pt 模式：每个控制节点有独立的 Spread_Segment（如原文 spread.conf 示例），消息点对点发送
• Eon 分片：由哈希边界（lower_hash_bound / upper_hash_bound）、节点订阅关系（NODE_SUBSCRIPTIONS）决定——与 Spread 分段配置无直接对应关系

但在大集群模式下存在间接关联：控制节点宕机会导致其下所有依赖节点（以及控制节点自身）同时失去与集群的通信。如果某个分片的 primary 和 secondary 订阅者恰好都在同一控制节点管辖下，该分片将失去所有订阅者 → 集群 READONLY。

❌ 错误分布（同分片订阅者共享控制节点）：

  ControlNode1 ──Spread── ControlNode2
  │         │             │         │
Node1    Node2           Node3    Node4
(Pri:A)  (Sec:A)        (Pri:B)  (Sec:B)

⚠️ ControlNode1 宕机：
  → Node1、Node2 同时失联
  → 分片 A 失去 Pri + Sec → READONLY


✅ 正确分布（分片订阅者跨控制节点）：

  ControlNode1 ──Spread── ControlNode2
  │         │             │         │
 Node1    Node2           Node3    Node4
(Pri:A)  (Pri:B)        (Sec:A)  (Sec:B)

  ✅ 任意控制节点宕机：
    → 仅影响一个分片的 Pri 或 Sec
    → 另一个控制节点下的副本接管

注意：控制节点自身也是 Vertica 节点——例如上图中 ControlNode1 既是控制节点，也持有分片订阅。分片订阅面向所有节点，控制面层级不影响订阅关系本身。

最佳实践：在 Eon 大集群模式下，确保同一分片的 primary 和 secondary 订阅者分布在不同控制节点下，避免控制节点单点故障导致分片覆盖丢失。

-- 查看控制节点分布（来源：LARGE_CLUSTER_CONFIGURATION_STATUS）
SELECT control_node_name, node_name, spread_host_name
FROM v_catalog.large_cluster_configuration_status
ORDER BY control_node_name, node_name;

-- 交叉检查：分片订阅节点是否共享控制节点
WITH ctrl AS (
  SELECT node_name, control_node_name
  FROM v_catalog.large_cluster_configuration_status
)
SELECT ns.shard_name,
       ns.node_name AS subscriber,
       ns.is_primary,
       c.control_node_name
FROM v_catalog.node_subscriptions ns
JOIN ctrl c ON ns.node_name = c.node_name
ORDER BY ns.shard_name, ns.is_primary DESC;

Eon 模式下的 Spread 配置指南

1. 控制模式选择（Control Mode）

Eon 模式对控制模式的选择比 Enterprise 模式更严格：

部署环境	推荐控制模式	原因
AWS S3 / 云环境	pt2pt（点对点）	云 VPC 不支持 UDP 广播，pt2pt 是唯一选择
HDFS 本地集群	broadcast 或 pt2pt	取决于网络拓扑；单子网建议 broadcast
MinIO / Pure Storage	pt2pt	兼容 S3 协议，需 unicast
混合部署	pt2pt	跨网段通信必须 pt2pt

⚠️ 关键约束（来源：v26.2 官方文档）：Enterprise → Eon 迁移到 S3 时，若原集群使用 broadcast 模式必须将 controlmode 改为 pt2pt（云 VPC 不支持 broadcast），否则 Eon 数据库无法启动。使用 admintools -t re_ip -d dbname -T 修改。

-- 查看当前控制模式
SELECT get_config_parameter('ControlMode');

-- Eon 云部署推荐配置
SELECT set_control_mode('pt2pt');
SELECT write_spread_config('');
SELECT reload_spread(true);
-- 随后需重启数据库

2. 子集群控制节点数配置

在 Eon 模式下，每个子集群有独立的控制节点数（control-set-size），通过以下方式配置：

创建子集群时指定：

# 创建 20 节点子集群，手动指定 5 个控制节点
admintools -t db_add_subcluster \
  -d verticadb -p 'password' \
  -c analytics_cluster \
  --control-set-size=5 \
  -s node01,node02,...,node20

已有子集群调整控制节点数（来源：v26.2 官方文档 SET_CONTROL_SET_SIZE）：

-- Eon 模式下调整子集群的控制节点数
SELECT set_control_set_size(8, 'subcluster_name');
-- 参数：(控制节点数, '子集群名称')
-- 注意：子集群必须处于运行状态才能修改

⚠️ SET_CONTROL_SET_SIZE 在 Enterprise 模式下作用于整个集群；在 Eon 模式下作用于指定子集群（必须提供子集群名）。其他子集群不受影响。

大集群启用阈值建议：

部署环境	建议启用节点数	建议控制节点数
云环境（Eon + S3）	16	sqrt(N)，上限 16
本地 HDFS（Eon）	50~80	sqrt(N)
本地 HDFS（Enterprise）	50~80	sqrt(N)，按机架均匀分布

sqrt(N) - N的平方根

3. Spread 令牌超时在 Eon 云环境中的调整

在云环境中（Azure/AWS），虚拟机可能因计划维护被暂停（Azure 内存保留更新可暂停 VM 最长 30 秒）。此暂停不中断节点，但可能触发 Spread 令牌超时导致节点被踢出集群。

-- 查看当前 Spread 令牌超时（仅控制节点上有效）
-- Enterprise 模式在所有节点查询；Eon 大集群仅在控制节点查询

-- 云环境建议：将超时从默认 8s 提升到 35~60s
SELECT set_spread_options('/dev/null', 'EXIT', 'TokenTimeout = 35000, ExitOnIdle = yes');
-- TokenTimeout 单位：毫秒。默认值取决于 Spread Segment 数量（v9.2+）：
--   1 个 Spread_Segment（broadcast 模式） → 8000ms（8 秒）
--   >1 个 Spread_Segment（pt2pt 模式）   → 25000ms（25 秒）
SELECT reload_spread(true);

Eon 模式下此调整仅影响运行 Spread 守护进程的控制节点，依赖节点通过控制节点间接受益。

4. Eon Spread 配置完整操作流

-- 步骤 1：确认当前配置
SELECT get_config_parameter('ControlMode');
SELECT * FROM v_catalog.large_cluster_configuration_status;

-- 步骤 2：设置控制模式（云环境选 pt2pt）
SELECT set_control_mode('pt2pt');

-- 步骤 3：调整子集群控制节点数（如需）
SELECT set_control_set_size(5, 'subcluster_name');

-- 步骤 4：生成 spread.conf 并重载
SELECT write_spread_config('');
SELECT reload_spread(true);

-- 步骤 5：重启数据库使配置生效
-- admintools -t stop_db -d <dbname> -F
-- admintools -t start_db -d <dbname> -F

Enterprise vs Eon：Spread 配置方案对比

Spread 控制面行为（Broadcast / Pt2pt / Pt2pt+LargeCluster）是数据库模式无关的——Enterprise 和 Eon 在相同配置下 Spread 行为一致。Eon 的主要差异在于大集群触发阈值更低（子集群 ≥16 节点 vs Enterprise ≥120 节点）和控制节点按子集群隔离。

维度	Broadcast	Pt2pt	Pt2pt + Large Cluster
控制面负载	每个节点发 1 条广播，交换机 fan-out 到全组	每个节点向其他 N−1 个节点独立发消息	仅 K 个控制节点参与 Spread ring；每个依赖节点与其控制节点点对点通信
控制节点故障影响	无控制节点概念；任一节点丢令牌即从 ring 移除	同左	控制节点宕机 → 其下所有依赖节点失去通信、被数据库视为宕机
Spread 参与节点上限	~120（MTU 1472 字节理论最大；IP 地址连续如 1.1.1.1~1.1.1.120 时可达）； 实际环境 IP 不连续时 50~80 节点即可能超出 MTU	同左	120 控制节点（总节点数可远超 120）
最大集群规模	~120 节点	~120 节点	数百节点
子集群/故障域隔离	不适用（Enterprise 无子集群）	不适用	依赖节点与控制节点始终同子集群/Fault Group，实现故障域隔离
令牌超时默认值	8 秒（1 个 Spread_Segment）	25 秒（多个 Spread_Segment）	同 pt2pt（25 秒）；云环境建议升至 35~60 秒
启动依赖	—	—	控制节点必须先启动； Eon Catalog >20GB 需设 TSCatalogInvite=0

Eon 专属差异：① 大集群自动触发阈值为子集群 ≥16 节点（非 Enterprise 的 120 节点）；② 控制节点数按子集群独立配置（SET_CONTROL_SET_SIZE 须指定子集群名）；③ Eon 主子集群建议分配更多控制节点（控制节点故障影响 K-safety）。

决策框架：Eon 模式下如何选择 Spread 配置

部署环境？
├── 本地 HDFS（Eon）
│   ├── 单子网 + 总节点 <50？
│   │   └── broadcast + 每子集群所有节点运行 Spread
│   └── 跨子网 或 总节点 >50？
│       ├── pt2pt + 手动启用 Large Cluster（50~80 节点）
│       └── 子集群 >16 节点 → Large Cluster 自动启用
│           └── 控制节点数 = sqrt(子集群节点数)，可按需手工调整
│
└── 云环境（Eon + S3/Azure）
    ├── 强制 pt2pt（S3 不支持 broadcast）
    ├── ≥16 节点/子集群 → 自动启用 Large Cluster
    │   └── 主子集群分配更多控制节点（控制节点故障影响 K-safety）
    ├── 建议 ≤16 控制节点（云环境性能平衡点）
    └── 调整 Spread Token Timeout → 35秒+（应对云平台维护暂停）

更多 Eon 模式架构差异对比见 K-Safety 最佳实践，节点恢复与分片订阅故障见 Vertica 集群网络性能优化与诊断最佳实践。

---

扩展阅读

• Spread Debugging — Spread 故障排查与调试
• K-Safety 最佳实践 — Eon 分片订阅机制完整说明
• NODE_SUBSCRIPTIONS — 分片订阅系统表参考
• SHARDS — 分片系统表参考
• LARGE_CLUSTER_CONFIGURATION_STATUS — 大集群控制节点配置视图
• Vertica 集群网络性能优化与诊断最佳实践 — 网络性能诊断（含 Spread 令牌超时排查）