Timescale Cloud:性能、规模、企业级
自托管产品
MST
在 Timescale 上,次要软件更新是自动处理的,您无需执行任何操作。
您的 Timescale 服务上执行的大多数更新都会在您可以根据工作负载定义的维护时段内应用。但是,如果存在影响您的严重安全漏洞,则可能需要在预定的维护时段之外进行维护。
重要
维护更新后,DNS 名称保持不变,但其指向的 IP 地址通常会发生变化。
在大多数情况下,在维护时段内发生的更新不需要任何停机。这意味着在升级期间您的服务不会中断。但是,升级期间所有进行中的连接和事务都会被重置。通常,数据库连接在重置后会自动恢复。
有时,在您的维护时段内发生的更新需要一些停机时间。在这种情况下,停机时间通常在 30 秒到 5 分钟之间。如果需要停机,我们会尽力在升级前通过电子邮件通知您,以便您能相应地进行计划。但在某些情况下,我们可能无法这样做。重要的是您应安排好维护时段,以最大程度地减少短暂停机对您的工作负载可能造成的影响。
要跟踪维护事件的状态,请参阅 Timescale 状态页面。
注意
要手动应用更改而不是等待维护时段,请 暂停
然后 恢复
您的服务。维护更改会在您的服务恢复时自动应用。
具有副本的服务在维护期间需要最小的写入停机时间,而只读查询在维护期间仍可继续工作。维护最多需要两次自动故障转移,每次耗时不到几秒钟。
在维护事件期间,具有副本的服务会独立地对每个节点执行维护。当主节点进行维护时,主节点需要重启。如果重启时间超过一分钟,则副本节点会被提升为主节点,前提是副本没有复制延迟。如果主节点上的维护在一分钟内完成并重新上线,则副本仍将作为副本。
当主节点开始维护并导致副本节点提升时,维护会按照相同的顺序在新提升的副本上继续进行。如果新提升的副本重启时间超过一分钟,则原主节点会被重新提升。总而言之,此过程可能导致长达两分钟的写入停机时间和两次故障转移事件。
有关副本的更多信息,请参阅副本部分。
非关键升级在 Timescale Cloud 自动执行升级之前可用。要手动升级 TimescaleDB,请在您的 Timescale Cloud 服务中运行 ALTER EXTENSION timescaledb UPDATE
,或者 暂停
和 恢复
服务。如果用户不采取任何操作,升级将在下一个可用的维护时段触发。您可以配置维护时段,以便这些升级在每周的特定日期和时间开始。
如果在常规维护时段内没有待处理的可用升级,则不会执行任何更改。
在考虑维护时段安排时,您可能更喜欢选择活动量非常低的时段,例如凌晨或周末。这有助于最大程度地减少短期服务中断的影响。或者,您可能更喜欢在办公时间进行维护时段,以便在升级期间监控您的系统。
登录您的 Timescale 账户
。点击您想要管理维护时段的服务名称。
在
Operations
选项卡中,导航到Environment
>Maintenance
,然后点击Change maintenance window
。选择您希望维护时段开始的星期几、时间和时区。维护时段最长可持续四个小时。
- 如果您希望将相同的维护时段设置应用于所有 Timescale 服务,请勾选
Apply new maintenance window to all services
。 - 点击
Apply
。
必要时,关键升级和安全修复会在常规维护时段之外安装,有时需要短暂中断。在这种情况下,停机时间通常在 30 秒到 5 分钟之间。如果需要停机,我们会尽力在升级前通过电子邮件通知您,以便您能相应地进行计划。但在某些情况下,我们可能无法这样做。
您也可以从服务概览页面手动升级到最新支持的 PostgreSQL 版本。
升级到较新版本的 PostgreSQL 可以让您利用新功能、增强功能和安全修复。它还确保您使用的 PostgreSQL 版本与最新版本的 Timescale 兼容,让您可以充分利用 Timescale 提供的一切。
下表显示了 PostgreSQL 和 TimescaleDB 的兼容版本。
TimescaleDB 版本 | PostgreSQL 17 | PostgreSQL 16 | PostgreSQL 15 | PostgreSQL 14 | PostgreSQL 13 | PostgreSQL 12 | PostgreSQL 11 | PostgreSQL 10 |
---|---|---|---|---|---|---|---|---|
2.20.x | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
2.19.x | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
2.18.x | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
2.17.x | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
2.16.x | ❌ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
2.15.x | ❌ | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ |
2.14.x | ❌ | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ |
2.13.x | ❌ | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ |
2.12.x | ❌ | ❌ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ |
2.10.x | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ |
2.5 - 2.9 | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ | ❌ | ❌ |
2.4 | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ | ❌ | ❌ |
2.1 - 2.3 | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ | ❌ |
2.0 | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ | ❌ |
1.7 | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ |
我们建议不要将 TimescaleDB 与 PostgreSQL 17.1、16.5、15.9、14.14、13.17、12.21 配合使用。
这些次要版本引入了破坏性的二进制接口更改,该更改在被识别后,已在随后的 PostgreSQL 次要版本 17.2、16.6、15.10、14.15、13.18 和 12.22 中回滚。当您从源代码构建时,最佳实践是使用 PostgreSQL 17.2、16.6 及更高版本进行构建。Timescale Cloud 用户以及 Linux、Windows、MacOS、Docker 和 Kubernetes 平台包用户不受影响。
有关版本之间功能更改的更多信息,请参阅 PostgreSQL 发布说明 和 Timescale 发布说明。
警告
您的 Timescale 服务在升级完成前将不可用。这可能需要长达 20 分钟。建议您先在分叉(fork)上进行测试以获得更好的预估时间。
为了获得流畅的升级体验,请确保您
- 提前计划。升级会导致停机,因此理想情况下应在流量较低的时段执行升级。
- 分叉您的数据库,并在生产系统上运行升级之前,先在分叉上进行升级测试。这可以帮助您很好地了解升级过程中会发生什么以及可能需要多长时间。有关分叉的更多信息,请参阅分叉部分。
- 如果您担心数据丢失,请保留一份包含旧版本和数据的数据库副本。您可以不升级分叉地复制您的数据库以保留一个 Timescale 服务副本。您可以立即暂停此分叉,以便只为存储付费,直到您确定可以删除它为止。
重要
带有副本的 Timescale 服务无法升级。要升级带有副本的服务,您必须首先删除副本,然后升级该服务。
- 在 Timescale 控制台中,导航到
Services
并点击您要升级的服务。 - 导航到
Operations
>Service Upgrades
。 - 如果有新的 PostgreSQL 版本可用,点击
Upgrade service
并确认您已准备好开始升级。在升级完成之前,您的 Timescale 服务将不可用。 - 升级完成后,您的服务将自动恢复正常运行。如果升级不成功,服务将返回到您开始升级之前的状态。
注册 Timescale
关键词