扩缩容

ClickHouse Managed Postgres 提供灵活扩缩容选项，以满足您的工作负载需求。提供 50 多种采用 NVMe 的实例类型，您可以独立对 CPU、内存和存储进行扩缩容，从而根据具体用例优化性能和成本。

ClickHouse Managed Postgres 提供丰富的实例类型，可针对不同的工作负载特征进行优化：

• 提供 50 多种实例类型，涵盖计算优化、内存优化和存储优化等配置
• 所有实例类型均配备 基于 NVMe 的存储，可提供稳定、高性能的磁盘 I/O
• 独立资源扩缩容：可根据工作负载选择合适的 CPU、内存和存储组合

不同的工作负载适合不同的资源配置：

当您更改实例类型时，ClickHouse Managed Postgres 会执行垂直扩缩容操作，创建新的基础设施资源，并在将停机时间降到最低的情况下迁移您的数据库。

扩缩容工作流会基于备份创建一个新的备用实例，并执行受控故障转移：

1. 备用实例预配：创建一个采用目标实例类型 (CPU、内存和存储配置) 的新备用实例

2. 从 S3 备份恢复：通过恢复存储在 S3 中的最新备份来初始化该备用实例

3. 并行 WAL 回放：备用实例使用由 WAL-G 提供支持的并行恢复机制，应用自备份以来的所有预写日志 (WAL) 变更

   • WAL-G 可实现快速的并行恢复操作
   • WAL-G 的创建者所在的 Ubicloud 团队也是我们的合作伙伴，这确保了深厚的专业能力和优化支持

4. 复制追平：备用实例通过流式传输并应用持续产生的 WAL 变更来追上主节点

5. 故障转移：备用实例完全同步后，系统会执行受控故障转移，将其提升为新的主节点

   • 这是唯一会导致停机的步骤 (约 30 秒)
   • 所有活动连接都会在故障转移期间中断
   • 故障转移完成后，客户端必须重新建立连接

6. 旧实例退役：原始实例会在故障转移完成后退役

扩缩容所需的总时间主要取决于数据库的大小，以及需要从备份中重放的 WAL 数据量：

• 备份恢复：将最新的全量备份从 S3 恢复到新实例所需的时间
• WAL 回放：自上次全量备份以来，回放增量 WAL 变更所需的时间
• 并行恢复：WAL-G 的并行恢复机制可显著加快这一过程

恢复时间可能从几分钟到几小时不等，但维护/停机时间非常短 (仅约 30 秒) 。

ClickHouse Managed Postgres 使用 WAL-G 在扩缩容期间加速备份恢复。值得一提的是，WAL-G 的创建者是我们合作伙伴 Ubicloud 团队的成员，这也为恢复过程带来了深厚的专业经验。

WAL-G 提供：

• 并行下载和解压：从 S3 同时拉取多个备份分段并解压
• 高效的 WAL 回放：在条件允许时并行应用增量 WAL 变更
• 优化的流式传输：直接从 S3 存储流式读取，无需中间副本
• 快速恢复：虽然总耗时取决于数据量，但并行化方式可显著加快整个过程

这些优化显著缩短了拉起新备用实例所需的时间。更重要的是，整个恢复过程都在后台进行——你的应用只会在大约 30 秒的短暂故障转移窗口内出现停机。

如需扩缩容您的 ClickHouse Managed Postgres 实例：

1. 前往实例的 Settings 选项卡
2. 在 Scaling 部分中，向下滚动到 Service size
3. 选择目标实例类型
4. 确认更改后，点击“Apply changes”

垂直扩缩容 (更改实例类型) 是 ClickHouse Managed Postgres 中调整资源的主要方式。这种方式可提供：

• 精细控制：可从 50 多种实例类型中选择，精细调整 CPU、内存和存储
• 工作负载优化：可选择针对特定工作负载优化的配置 (计算密集型、内存密集型或存储密集型)
• 成本效率：只为所需资源付费，避免资源过度配置

对于读密集型工作负载，可考虑使用只读副本来横向扩展读取能力：

• 将读查询分流到专用的只读副本实例
• 每个只读副本都是一个完全独立的 Postgres 实例，拥有各自的计算资源和内存
• 只读副本通过流式读取对象存储中的 WAL 变更来实现高效复制

这种方式非常适合读写比高的应用，例如报表仪表盘、分析查询或读密集型 API 端点。

如果你使用 ClickPipes 将数据复制到 ClickHouse，则可以独立调整 CDC (变更数据捕获) 管道的扩缩容：

• 将 CDC 工作线程的规模调整为 1 到 24 个 CPU 核心
• 内存会按 CPU 核心数的 4 倍自动扩缩
• 通过 ClickPipes OpenAPI 调整扩缩容

这样，你就可以在不受 Postgres 实例资源影响的情况下，单独优化复制吞吐量。

ClickHouse Managed Postgres 会监控磁盘使用率并自动扩展存储空间，避免您的实例磁盘空间耗尽：

• 磁盘使用率达到 85%：您会通过 Cloud Console 和电子邮件收到通知。
• 磁盘使用率达到 90%：自动扩缩容开始。存储容量将扩展至您的实例家族可用的下一个更大规格。CPU 和内存保持不变；但如果当前实例规格不支持更大磁盘，实例规格也会随之提升。只读副本会与主节点一同扩缩容。
• 磁盘使用率达到 95%：切换会在新服务器就绪后立即执行，无需等待。

如果您的实例已处于最大可用配置，自动扩缩容将无法继续扩展。请释放磁盘空间或联系支持。

存储不会原地调整大小。自动扩缩容遵循与手动更改实例类型相同的扩缩容流程：预配一台具有更多存储空间的替换服务器，从最新备份恢复，追赶 WAL，然后通过受控切换将其提升为新的主节点。启用了高可用性的实例也会在同一操作中获得采用新规格的替换备用实例。

切换是唯一会导致停机的步骤，通常不到一分钟。已配置的计划升级窗口不会延迟切换：该窗口适用于平台维护，而不适用于扩缩容。切换期间，现有连接会断开，进行中的事务会回滚。连接字符串不会改变：DNS 会更新为指向新的主节点，具有标准重连逻辑的应用程序会自动恢复。

如果写入导致磁盘空间耗尽的速度快于自动扩缩容完成的速度，实例将进入只读模式，以防止磁盘被完全占满。触发条件取决于剩余可用空间：

读取仍可正常进行，而写入会因标准 Postgres 错误 cannot execute INSERT in a read-only transaction 而失败。如果可用空间继续减少，现有连接将被终止，以确保每个会话都采用只读设置；客户端重新连接后，读取即可恢复正常。可用空间恢复后，系统会自动解除只读模式，通常是在扩容切换完成后立即解除。

一个存储容量为 1024 GB 的实例运行写入密集型工作负载：

1. 已使用 870 GB (85%) 时，您会收到存储空间通知。
2. 已使用 922 GB (90%) 时，自动扩缩容启动。系统会预配一台存储容量为 2048 GB 的替换服务器，并从最新备份恢复数据，同时您的实例继续处理流量。
3. 替换服务器追赶完成后，系统将执行切换。连接会中断不到一分钟，您的应用会重新连接到同一主机名，使用率将回落至约 45%。
4. 如果在切换完成前可用空间降至 2% 以下 (约 20 GB) ，实例将进入只读模式。完成向更大磁盘的切换后，写入会自动恢复。

• 设置和配置
• 只读副本
• 高可用性