本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 维护 Amazon Neptune 数据库集群 Neptune 会定期对其使用的所有资源执行维护，包括： + **必要时更换底层硬件。**这种情况发生在后台，您无需采取任何行动，而且通常不会影响您的操作。 + **更新底层操作系统。**数据库集群中实例的操作系统升级是为了提高性能和安全性，因此，通常应尽快完成升级。通常而言，更新大约需要花费 10 分钟。操作系统更新不会更改数据库实例的数据库引擎版本或数据库实例类。 通常最好先更新数据库集群中的读取器实例，然后更新写入器实例。在发生失效转移时，同时更新读取器和写入器可能会导致停机。注意，在操作系统更新之前，数据库实例不会自动备份，因此，请务必在应用操作系统更新之前进行手动备份。 + **更新 Neptune 数据库引擎。**Neptune 定期发布各种引擎更新，以引入新特征和改进并修复错误。 ## 引擎版本号 ### 引擎版本 1.3.0.0 之前的版本编号 在 2019 年 11 月之前，Neptune 一次仅支持一个引擎版本，引擎版本号均采用 `1.0.1.0.200` 形式，其中 `xxx` 为补丁号。所有新引擎版本均作为早期版本的补丁发布。 自 2019 年 11 月起，Neptune 开始支持多个版本，使客户能够更好地控制他们的升级路径。因此，引擎版本编号发生了变化。 从 2019 年 11 月到[引擎版本 1.3.0.0](engine-releases-1.3.0.0.md)，引擎版本号分为 5 个部分。以版本号 `1.0.2.0.R2` 为例： + 第一部分始终是 1。 + 第二部分 `0`（在 `1.0.2.0.R2` 中）是数据库的主要版本号。 + 第三部分和第四部分 `2.0`（在 `1.0.2.0.R2` 中）都是次要版本号。 + 第五部分 `R2`（在 `1.0.2.0.R2` 中）是补丁号。 大多数更新都是补丁更新，补丁和次要版本更新之间的区别并不总是很清楚。 ### 自引擎版本 1.3.0.0 起的版本编号 从[引擎版本 1.3.0.0](engine-releases-1.3.0.0.md) 开始，Neptune 改变了引擎更新的编号和管理方式。 引擎版本号现在有四个部分，每个部分对应于一种版本类型，如下所示：     *product-version***.***major-version***.***minor-version***.***patch-version* 以前作为补丁发布的那种不间断的更改现在作为次要版本发布，您可以使用 [`AutoMinorVersionUpgrade`](engine-maintenance-management.md#using-amvu) 实例设置对其进行管理。 这意味着，如果您愿意，则每次发布新的次要版本时，都可以通过订阅 [`RDS-EVENT-0156`](event-lists.md#RDS-EVENT-0156) 事件来接收通知（请参阅[订阅 Neptune 事件通知](events-subscribing.md)）。 补丁版本现在保留用于紧急的定向修复，并使用版本号的最后一部分（`*.*.*.1`、`*.*.*.2` 等）进行编号。 # Amazon Neptune 中不同类型的引擎版本 与引擎版本号的四个部分相对应的四种引擎版本如下所示： + **产品版本** - 只有当产品在功能或界面上发生彻底的根本性变化时，才会更改此版本。当前 Neptune 产品版本为 1。 + [**主要版本**](#major-versions) - 主要版本引入了重要的新特征和重大更改，其使用寿命通常至少为两年。 + [**次要版本**](#minor-versions) - 次要版本可以包含新特征、改进和错误修复，但不包含任何重大更改。您可以选择是否在下一个维护时段内自动应用它们，也可以选择在发布时接收通知。 + [**补丁版本**](#patch-version-updates) - 发布补丁版本仅用于解决紧急错误修复或关键安全更新。它们很少包含重大更改，并且会在发布后的下一个维护时段内自动应用。 ## Amazon Neptune 主要版本更新 主要版本更新通常会引入一个或多个重要的新特征，且通常包含重大更改。它的支持寿命通常约为两年。[引擎版本](engine-releases.md)中列出了 Neptune 的主要版本，及其发布日期和预计的使用寿命。 在您使用的主要版本到期之前，主要版本更新完全是可选的。如果您选择升级到新的主要版本，则必须使用 Amazon CLI 或 Neptune 控制台自行安装新版本，如中所述。[主要版本升级](engine-updates-manually.md) 但是，如果您使用的主要版本已过期，则系统会通知您需要升级到最新的主要版本。然后，如果您没有在通知后的宽限期内进行升级，则系统会自动安排在下一个维护时段内升级到最新的主要版本。请参阅[引擎版本的使用寿命](engine-updates-eol-planning.md)了解更多信息。 ## Amazon Neptune 次要版本更新 大多数 Neptune 引擎更新都是次要版本更新。它们经常发生，并且不包含重大更改。 如果您在数据库集群的写入器（主）实例中将 [`AutoMinorVersionUpgrade`](engine-maintenance-management.md#using-amvu) 字段设置为 `true`，则次要版本更新将在数据库集群中的所有实例发布后的下一个维护时段内自动应用于这些实例。 如果您在数据库集群的写入器实例中将 [`AutoMinorVersionUpgrade`](engine-maintenance-management.md#using-amvu) 字段设置为 `false`，则只有在您[明确安装](engine-updates-manually.md)时才会应用这些更新。 **注意** 次要版本更新是独立的（它们不依赖于以前对同一主要版本的次要版本更新）累积更新（它们包含先前次要版本更新中引入的所有特征和修复）。这意味着，无论您是否安装了以前的次要版本更新，您都可以安装任何给定的次要版本更新。 通过订阅 [`RDS-EVENT-0156`](event-lists.md#RDS-EVENT-0156) 事件，可以轻松跟踪次要版本的发布（参见[订阅 Neptune 事件通知](events-subscribing.md)）。然后，每次发布新的次要版本时，您都会收到通知。 此外，无论您是否订阅通知，您都可以随时[查看哪些更新有待处理](engine-maintenance-management.md#check-pending-updates)。 ## Amazon Neptune 补丁版本更新 如果出现影响实例可靠性的安全问题或其他严重缺陷，则 Neptune 会部署强制补丁。它们将在下一个维护时段应用于数据库集群中的所有实例，而无需您进行任何干预。 只有在不部署补丁版本的风险超过与部署补丁版本相关的风险和停机时间时，才会部署补丁版本。补丁版本很少发生（通常几个月一次），并且几乎不会需要过长的维护时段。 # 规划 Amazon Neptune 主要引擎版本的使用寿命 Neptune 引擎版本几乎总是在日历季度末达到使用寿命的尽头。只有在出现重大的安全或可用性问题时，才会出现例外。 当引擎版本达到其使用寿命结束时，您需要将 Neptune 数据库升级到较新的版本。 通常，Neptune 引擎版本将继续可用，如下所示： + **次要引擎版本：**次要引擎版本在发布后的至少 6 个月内保持可用。 + **主要引擎版本：**主要引擎版本在发布后的至少 12 个月内保持可用。 在引擎版本终止使用前至少 3 个月，系统 Amazon 会自动向与您的 Amazon 账户关联的电子邮件地址发送电子邮件通知，并将相同的消息发布到您的 Healt [Amazon h Das](https://docs.amazonaws.cn/health/latest/ug/aws-health-dashboard-status.html) hboard。这将使您有时间计划和准备升级。 当引擎版本达到其使用寿命结束时，您将无法再使用该版本创建新的集群或实例，自动缩放功能也无法使用该版本创建实例。 实际达到使用寿命结束的引擎版本将在维护时段期间自动升级。在引擎版本使用寿命结束前 3 个月发送给您的邮件将包含有关此自动更新将涉及的内容的详细信息，包括您将自动升级到的版本、对数据库集群的影响以及我们建议的操作。 **重要** 您有责任使数据库引擎版本保持最新。 Amazon 敦促所有客户将其数据库升级到最新的引擎版本，以便从最新的安全、隐私和可用性保护措施中受益。如果您在弃用日期之后在不受支持的引擎或软件（“旧版引擎”）上运行数据库，则更有可能面临安全、隐私和运营风险，包括停机事件。 在任何引擎上操作您的数据库均受管理您使用 Amazon 服务的协议的约束。传统引擎并非普遍可用。 Amazon 不再为传统引擎提供支持，如果 Amazon 确定旧版引擎对服务、其关联公司或任何第三方构成安全或责任风险或损害风险，则 Amazon 可以随时限制对任何传统引擎的访问或使用。 Amazon您决定继续在旧版引擎中运行您的内容可能会导致您的内容不可用、损坏或无法恢复。在旧版引擎上运行的数据库受服务水平协议 (SLA) 例外情况的约束。 在旧版引擎上运行的数据库和相关软件包含错误、错误、缺陷和 AND/OR 有害组件。因此，无论协议或服务条款中有任何相反之处，都 Amazon 是 “按原样” 提供传统引擎。 # 管理 Neptune 数据库集群的引擎更新 **注意** 更新将同时应用于数据库集群中的所有实例。更新操作需要在这些实例上重启数据库，因此，会出现从 20 或 30 秒到几分钟的停机，之后您可以继续使用数据库集群。在极少数情况下，可能需要多可用区失效转移才能完成实例的维护更新。 对于可能需要更长时间才能应用的主要版本升级，您可以使用[蓝绿部署策略](neptune-BG-deployments.md)，最大限度地减少停机时间。 ## 确定您当前使用的引擎版本 您可以使用 Amazon CLI [`get-engine-status`](access-graph-status.md)命令来检查您的数据库集群当前使用的引擎发行版本： ``` aws neptunedata get-engine-status ``` [JSON 输出](access-graph-status.md#access-graph-status-sample-output)包含 `"dbEngineVersion"` 字段，如下所示： ``` "dbEngineVersion": "1.3.0.0", ``` ## 查看哪些更新有待处理且可用 您可以使用 Neptune 控制台检查数据库集群的待处理更新。在左列中选择**数据库**，然后在数据库窗格中选择您的数据库集群。待处理的更新列在**维护**列中。如果您依次选择**操作**和**维护**，则有三种操作选择： + 立即升级。 + 在下一个时段升级。 + 推迟升级。 您可以使用以下方式列出待处理的 Amazon CLI 引擎更新： ``` aws neptune describe-pending-maintenance-actions \ --resource-identifier (ARN of your DB cluster) --region (your region) \ --engine neptune ``` 您也可以按 Amazon CLI 如下方式列出可用的引擎更新： ``` aws neptune describe-db-engine-versions \ --region (your region) \ --engine neptune ``` 可用的引擎版本列表仅包括版本号高于当前版本且已定义升级路径的那些版本。 ## 升级前始终先测试 发布新的主要或次要 Neptune 引擎版本时，请务必先在该版本上测试您的 Neptune 应用程序，然后再升级到该版本。次要版本升级可能引入会影响代码的新特征或行为，即使没有任何重大更改也如此。 首先，将当前版本的发行说明页面与目标版本的发行说明页面进行比较，以查看查询语言版本是否会发生变化或是否会发生其它重大更改。 在升级生产数据库集群之前测试新版本的最佳方法是使用 [Neptune 蓝绿部署解决方案](neptune-BG-deployments.md)。这样，您就可以在新版本上运行应用程序和查询，而不会影响您的生产数据库集群。 ## 请在升级之前始终创建手动快照 在执行升级之前，我们强烈建议您始终创建数据库集群的手动快照。拥有自动快照只能提供短期保护，而手动快照在您显式删除它之前仍然可用。 在某些情况下，作为升级过程的一部分，Neptune 会为您创建手动快照，但您不应依赖此快照，无论如何都应创建自己的手动快照。 当您确定不需要将数据库集群恢复到其升级前的状态时，可以显式删除自己创建的手动快照以及 Neptune 可能已创建的手动快照。如果 Neptune 创建手动快照，则其名称将以 `preupgrade` 开头，后跟数据库集群的名称、源引擎版本、目标引擎版本和日期。 ## Neptune 维护时段 每周维护时段为 30 分钟，在此期间将应用定期引擎更新和其他系统更改。大部分维护事件将在 30 分钟的维护时段内完成，但较大的维护事件有时可能需要更长时间才能完成。 每个数据库集群都有每周 30 分钟的维护时段。如果在创建数据库集群时未为其指定首选时段，则 Neptune 随机选择一周中的某一天，然后从这一天 8 小时的时间块中随机分配 30 分钟的时段（随区域的不同而变化）。 例如，以下是多个 Amazon 区域使用的维护时段的 8 小时时间块： **** [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/neptune/latest/userguide/engine-maintenance-management.html) 维护时段决定待处理操作何时开始，大多数维护操作都是在该时段内完成的，但是较大的维护任务可以在该时段结束之后继续进行。 ### 移动数据库集群维护时段 理想情况下，您的维护时段应在集群使用率最低的时候。如果您的当前时段不在这时候，则您可以将其移到更好的时间，如下所示： **更改数据库集群维护时段** 1. [登录 Amazon 管理控制台，然后在家中打开 Amazon Neptune https://console.aws.amazon.com/neptune/ 主机。](https://console.amazonaws.cn/neptune/home) 1. 在导航窗格中，选择**数据库**。 1. 选择要更改维护时段的数据库集群。 1. 选择**修改**。 1. 在**修改集群**页面底部选择**显示更多**。 1. 在**首选维护时段**部分，根据需要设置维护时段的日期、时间和持续时间。 1. 选择**下一步**。 在确认页面上，检查您的更改。 1. 要立即应用对维护时段的更改，请选择**立即应用**。 1. 选择**提交**以应用更改。 要编辑您的更改，请选择**以前**，要取消更改，请选择**取消**。 ## AutoMinorVersionUpgrade 用于控制次要版本的自动更新 **重要** `AutoMinorVersionUpgrade` 仅对[引擎版本 1.3.0.0](engine-releases-1.3.0.0.md) 以上的次要版本升级有效。 如果您在数据库集群的写入器（主）实例中将 `AutoMinorVersionUpgrade` 字段设置为 `true`，则次要版本更新将在数据库集群中的所有实例发布后的下一个维护时段内自动应用于这些实例。 如果您在数据库集群的写入器实例中将 `AutoMinorVersionUpgrade` 字段设置为 `false`，则只有在您[明确安装](engine-updates-manually.md#engine-minor-updates-using-console)时才会应用这些更新。 **注意** 无论 `AutoMinorVersionUpgrade` 参数的设置方式如何，补丁版本（`*.*.*.1`、`*.*.*.2` 等）总是在下一个维护时段内自动安装。 您可以按 Amazon Web Services 管理控制台 如下方式`AutoMinorVersionUpgrade`进行设置： **使用 Neptune 控制台设置 `AutoMinorVersionUpgrade`** 1. [登录 Amazon 管理控制台，然后在家中打开 Amazon Neptune https://console.aws.amazon.com/neptune/ 主机。](https://console.amazonaws.cn/neptune/home) 1. 在导航窗格中，选择**数据库**。 1. 选择要为其设置 `AutoMinorVersionUpgrade` 的数据库集群的主（写入器）实例。 1. 选择 **Modify**(修改)。 1. 在**修改集群**页面底部选择**显示更多**。 1. 在展开页面的底部，选择**开启自动次要版本升级**或**关闭自动次要版本升级**。 1. 选择**下一步**。 在确认页面上，检查您的更改。 1. 要应用对自动次要版本升级的更改，请选择**立即应用**。 1. 选择**提交**以应用更改。 要编辑您的更改，请选择**以前**，要取消更改，请选择**取消**。 您也可以使用 Amazon CLI 来设置字`AutoMinorVersionUpgrade`段。例如，要将其设置为 `true`，您可以使用如下命令： ``` 1. aws neptune modify-db-instance \ 2. --db-instance-identifier (the ID of your cluster's writer instance) \ 3. --auto-minor-version-upgrade \ 4. --apply-immediately ``` 同样，要将其设置为 `false`，可使用如下命令： ``` 1. aws neptune modify-db-instance \ 2. --db-instance-identifier (the ID of your cluster's writer instance) \ 3. --no-auto-minor-version-upgrade \ 4. --apply-immediately ``` # 手动安装 Neptune 引擎的更新 ## 安装主要版本引擎升级 必须始终手动安装主要引擎版本。为了最大限度地减少停机时间并留出充足的时间进行测试和验证，安装新的主要版本的最佳方法通常是使用 [Neptune 蓝绿部署解决方案](neptune-BG-deployments.md)。 在某些情况下，您还可以使用创建数据库集群时使用的 Amazon CloudFormation 模板来安装主要版本升级（请参阅[使用 Amazon CloudFormation 模板更新 Neptune 数据库集群的引擎版本](cfn-engine-update.md)）。 如果要立即安装主要版本更新，则可以使用如下所示的 CLI 命令： ``` aws neptune modify-db-cluster \ --db-cluster-identifier (identifier for your neptune cluster) \ --engine neptune \ --engine-version (the new engine version) \ --apply-immediately ``` 确保指定要升级的引擎版本。如果不这样做，您的引擎可能会升级到非最新版本或不是您期望的版本。 您可以指定 `--no-apply-immediately`，而不是 `--apply-immediately`。 如果集群使用自定义集群参数组，请确保指定使用此参数： ``` --db-cluster-parameter-group-name (name of the custom DB cluster parameter group) ``` 同样，如果集群中的任何实例使用自定义数据库参数组，请确保指定它使用此参数： ``` ---db-instance-parameter-group-name (name of the custom instance parameter group) ``` ## 使用安装次要版本引擎升级 Amazon Web Services 管理控制台 **使用 Neptune 控制台执行次要版本升级** 1. [登录 Amazon 管理控制台，然后在家中打开 Amazon Neptune https://console.aws.amazon.com/neptune/ 主机。](https://console.amazonaws.cn/neptune/home) 1. 在导航窗格中，选择**数据库**，然后选择您希望修改的数据库集群。 1. 选择 **Modify**(修改)。 1. 在**实例规格**下，选择要升级的新版本。 1. 选择**下一步**。 1. 如果要立即应用更改，请选择**立即应用**。 1. 选择**提交**以更新您的数据库集群。 ## 使用安装次要版本引擎升级 Amazon CLI 您可以使用如下命令来执行次要版本升级，而无需等待下一个维护时段： ``` aws neptune modify-db-cluster \ --db-cluster-identifier (your-neptune-cluster) \ --engine-version (new-engine-version) \ --apply-immediately ``` 如果您使用手动升级 Amazon CLI，请务必包括要升级到的引擎版本。如果不这样做，您的引擎可能会升级到非最新版本或不是您期望的版本。 # 从 1.2.0.0 之前的版本升级到引擎版本 1.2.0.0 或更高版本 [引擎版本 1.2.0.0](engine-releases-1.2.0.0.md) 引入了几项重大更改，这些更改可能会使从早期版本升级变得更加复杂： + [引擎版本 1.2.0.0](engine-releases-1.2.0.0.md) 为自定义参数组和自定义集群参数组引入了一种新格式。因此，如果您要从 1.2.0.0 之前的引擎版本升级到引擎版本 1.2.0.0 或更高版本，则必须使用参数组系列 `neptune1.2` 重新创建所有现有的自定义参数组和自定义集群参数组。早期版本使用参数组系列 `neptune1`，而这些参数组不适用于版本 1.2.0.0 及更高版本。请参阅[Amazon Neptune 参数组](parameter-groups.md)了解更多信息。 + 引擎版本 1.2.0.0 引入了一种新的撤消日志格式。因此，如果您要从 1.2.0.0 之前的版本升级到 1.2.0.0 或更高版本，则该[`UndoLogListSize`](cw-metrics.md#cw-metrics-UndoLogListSize)指标必须低于某个阈值。否则，补丁将回滚并失败。阈值基于实例类型：4xlarge 或更大的实例的默认限制为 40k，小于 4xlarge 的实例的默认限制为 10k。如果您尝试升级时`UndoLogListSize`超过限制，则补丁过程将回滚，升级将被取消，并且集群事件页面上将显示一个包含原因的事件。这些限制可能会因操作原因而发生变化，恕不另行警告。 您可以通过升级集群的写入器实例（清除发生的地方）来加快清除速率。在尝试升级之前这样做可以帮助降低适用的阈值以`UndoLogListSize`下。将写入器的大小增加到 24XL 实例类型，可以将清除率提高到每小时超过一百万条记录。 如果`UndoLogListSize` CloudWatch 指标非常大，则提出支持案例可以帮助您探索其他策略，将其降至所需限制以下。 + 最后，1.2.0.0 版本中有一项重大变化，会影响之前使用 Bolt 协议和 IAM 身份验证的代码。从版本 1.2.0.0 开始，Bolt 需要一个用于 IAM 签名的资源路径。在 Java 中，设置资源路径可能如下所示：`request.setResourcePath("/openCypher"));`。在其它语言中，可以将 `/openCypher` 附加到端点 URI 之后。有关示例，请参阅 [使用 Bolt 协议](access-graph-opencypher-bolt.md)。