维护和升级

在 Timescale 上，次要软件更新是自动处理的，您无需执行任何操作。

在您的 Timescale 服务上执行的大多数更新都在您可以定义的维护窗口期间应用，以适应您的工作负载。但是，如果存在影响您的严重安全漏洞，则可能需要在计划的维护窗口之外进行维护。

重要提示

维护更新后，DNS 名称保持不变，但它指向的 IP 地址通常会更改。

在大多数情况下，在您的维护窗口期间发生的更新不需要任何停机时间。这意味着在升级期间您的服务不会中断。但是，升级期间正在进行的所有连接和事务都将被重置。通常，数据库连接会在重置后自动恢复。

有时，在您的维护窗口期间发生的更新需要一些停机时间。在这种情况下，停机时间通常在 30 秒到 5 分钟之间。如果需要停机，我们会在升级前通过电子邮件通知您，以便您能够相应地计划。但是，在某些情况下，我们可能无法做到这一点。重要的是，您要安排您的维护窗口，以最大限度地减少短暂停机可能对您的工作负载造成的 disruption。

要跟踪维护事件的状态，请参阅 Timescale 状态页面。

注意

要手动应用更改而不是等待维护窗口，请先暂停然后恢复您的服务。维护更改会在您的服务恢复时自动应用。

具有副本的服务在维护期间需要最少的写入停机时间，而只读查询在整个维护过程中保持工作。维护最多需要两次故障转移，自动执行，每次耗时不到几秒钟。

在维护事件期间，具有副本的服务会独立地对每个节点执行维护。当主节点进行维护时，主节点需要重新启动。如果重启时间超过一分钟，则副本节点将被提升为主节点，前提是副本没有复制延迟。如果主节点上的维护在一分钟内完成并恢复在线，则副本仍然是副本。

当主节点上的维护开始并导致副本节点升级时，维护将继续在新升级的副本上进行，遵循相同的顺序。如果新升级的副本重启时间超过一分钟，则前主节点将被重新提升。总的来说，该过程可能会导致最多两分钟的写入停机时间和两次故障转移事件。

有关副本的更多信息，请参阅副本部分。

非关键升级会在自动执行升级之前提供。在此期间，您可以单击应用升级以随时开始升级。但是，在时间到期后（通常大约一周），升级会在您服务的下一个可用维护窗口中自动触发。您可以配置维护窗口，以便仅在特定时间、在一周的设定日期开始这些升级。如果在常规维护窗口期间没有可用的待处理升级，则不会执行任何更改。

当您考虑维护窗口计划时，您可能更喜欢选择通常活动非常低的一天和时间，例如在清晨或周末。这可以帮助最大限度地减少短暂服务中断的影响。或者，您可能更喜欢在工作时间进行维护窗口，以便您可以在升级期间监控您的系统。

关键升级和安全修复程序会在必要时在正常维护窗口之外安装，有时需要短暂中断。在这种情况下，停机时间通常在 30 秒到 5 分钟之间。如果需要停机，我们会在升级前通过电子邮件通知您，以便您能够相应地计划。但是，在某些情况下，我们可能无法做到这一点。

Timescale 当前支持 PostgreSQL 14、15、16 和 17。您可以从 Timescale 服务概览页面查看您的 PostgreSQL 和 Timescale 版本。

您还可以从服务概览页面手动升级到最新的受支持 PostgreSQL 版本 (PostgreSQL 16)。

升级到较新版本的 PostgreSQL 允许您利用新功能、增强功能和安全修复程序。它还可以确保您正在使用与最新版本的 Timescale 兼容的 PostgreSQL 版本，从而使您能够充分利用 Timescale 提供的所有功能。有关版本之间功能更改的更多信息，请参阅 PostgreSQL 发行说明 和 Timescale 发行说明。

警告

在升级完成之前，您的 Timescale 服务不可用。这可能需要长达 20 分钟。建议先在 fork 上进行测试，以便更好地估算时间。

为了获得顺畅的升级体验，请确保您

• 提前计划。升级会导致停机，因此最好在低流量时段执行升级。
• Fork 您的数据库，并在生产系统上运行升级之前在 fork 上试用升级。这使您能够很好地了解升级期间会发生什么以及可能需要多长时间。有关 fork 的更多信息，请参阅有关 forking 的部分。
• 如果您担心丢失数据，请保留一份包含旧版本和数据的数据库副本。您可以 fork 您的数据库而不升级 fork，以保留重复的 Timescale 服务。您可以立即暂停此 fork，仅支付存储费用，直到您确信可以删除它为止。

重要提示

具有副本的 Timescale 服务无法升级。要升级具有副本的服务，您必须先删除副本，然后再升级服务。