Amazon Neptune engine updates - Amazon Neptune

Amazon Neptune engine updates

Amazon Neptune releases engine updates regularly. You can determine which engine release version you currently have installed using the instance-status API.

Engine releases are listed at Engine releases for Amazon Neptune, and patches are listed at Latest Updates.

You can find information about how the updates are released and how to upgrade the Neptune engine in this section. For example, engine version numbering is explained in Neptune Engine version numbering.

Note

Before November 2019, Neptune only supported one engine version at a time, and engine version numbers all took the form, 1.0.1.0.200<xxx>, where xxx was the patch number. New engine versions were all released as patches to earlier versions.

Starting in November 2019, Neptune supports multiple versions, allowing customers better control over their upgrade paths. As a result, engine release numbering changed.

Always test before you upgrade

When a new major or minor Neptune engine version is released, always test your Neptune applications on it first before upgrading to it. Even a minor upgrade could introduce new features or behavior that would affect your code.

Start by comparing the release notes pages from your current version to those of the targeted version to see if there will be changes in query language versions or other breaking changes.

The best way to test a new version before upgrading your production DB cluster is to clone your production cluster so that the clone is running the new engine version. You can then run queries on the clone without affecting the production DB cluster.

Always create a manual snapshot before you upgrade

Before performing an upgrade, we strongly recommend that you always create a manual snapshot of your DB cluster. Having an automatic snapshot only offers short-term protection, whereas a manual snapshot remains available until you explicitly delete it.

In certain cases Neptune creates a manual snapshot for you as a part of the upgrade process, but you should not rely on this, and should create your own manual snapshot in any case.

When you are certain that you won't need to revert your DB cluster to its pre-upgrade state, you can explicitly delete the manual snapshot that you created yourself, as well as the manual snapshot that Neptune might have created. If Neptune creates a manual snapshot, it will have a name that begins with preupgrade, followed by the name of your DB cluster, the source engine version, the target engine version, and the date.

Upgrading your Neptune engine

Note

Updates are applied to all instances in a DB cluster simultaneously. An update requires a database restart on those instances, so you experience downtime ranging from 20 or 30 seconds to several minutes, after which you can resume using the DB cluster.

Patch releases (.R2, .R3, etc.) are always installed automatically during your next maintenance window.

If you are manually upgrading using the AWS CLI, be sure to specify the engine version to which you want to upgrade. If you do not, your engine may be upgraded to a version that is not the most recent one or the one you expect.

You can always determine what engine version your DB cluster is running by using the Instance Status API. If you are using the CreateDBCluster to create a cluster, the API returns the engine version used to create the cluster in its response.

The timing of automatic updates depends on the AWS region and maintenance window settings for your DB cluster. You can view or change your maintenance window settings on the Neptune console. For more information, see Neptune Maintenance Window.

Major engine releases must be installed manually.

Neptune Engine version numbering

Neptune version numbers have 3 parts. Take version number 1.0.2.0.R2 as an example:

  1. The first part (the first two numbers, namely the 1.0 in 1.0.2.0.R2) is the database major version number.

    This part only changes when a major incompatible change occurs, such as a change in the way data is stored that requires data migration when upgrading. Upgrading to a new major version often requires downtime proportional to the size of the cluster being upgraded, and can take much longer than other upgrades.

  2. The second part (the third and fourth numbers, namely the 2.0 in 1.0.2.0.R2) is the minor version number of the engine release.

    You can choose to upgrade your engine to new minor versions automatically, as described below, or choose to decide for each minor version change.

  3. The third part (the last number, namely the R2 in 1.0.2.0.R2) is the patch number for the minor version of the engine.

    Patches involve urgent changes such as bug fixes or security changes that are deployed between minor engine releases. The first release of an engine version is implicitly R0, and patches to it are numbered R1, R2, and so forth.

    Patches are always automatically applied during system maintenance windows, as described below.

You can list the available engine releases using the AWS CLI as follows:

For Linux, OS X, or Unix:

aws neptune describe-db-engine-versions \ --region <your-region> \ --engine neptune

For Windows:

aws neptune describe-db-engine-versions ^ --region <your-region> ^ --engine neptune

Available engine releases include only those releases that have a version number higher than the current one and for which an upgrade path is defined.

Using the console to upgrade your engine to a more recent version

You can perform a minor version upgrade of a Neptune DB cluster using the AWS Management Console as follows:

To upgrade the engine version of a DB cluster using the console
  1. Sign in to the AWS Management Console, and open the Amazon Neptune console at https://console.aws.amazon.com/neptune/home.

  2. In the navigation pane, choose Clusters, and then choose the DB cluster that you want to modify.

  3. Choose Actions, and then choose Modify cluster. The Modify DB cluster page appears.

  4. For DB engine version, choose the new version.

  5. Choose Continue and check the summary of modifications.

  6. To apply the changes immediately, choose Apply immediately.

  7. On the confirmation page, review your changes. If they are correct, choose Modify Cluster to save your changes.

    Alternatively, choose Back to edit your changes, or choose Cancel to cancel your changes.

Manually performing a minor upgrade of the Neptune DB Engine using the CLI

You can manually perform a minor upgrade of the engine version of a DB cluster as follows, using the AWS CLI and the ModifyDBCluster API:

For Linux, OS X, or Unix:

aws neptune modify-db-cluster \ --db-cluster-identifier (your-neptune-cluster) \ --engine-version (new-engine-version) \ --apply-immediately

For Windows:

aws neptune modify-db-cluster ^ --db-cluster-identifier (your-neptune-cluster) ^ --engine-version (new-engine-version) ^ --apply-immediately

Be sure to include the engine version that you want to upgrade to. If you do not, your engine may be upgraded to a version that is not the latest one.

Manually performing a major upgrade of the Neptune DB Engine using the CLI

To perform a major upgrade of the engine version of a DB cluster manually using the AWS CLI and the ModifyDBCluster API, you need to provide more parameters than for a minor upgrade:

It is important to include the engine version that you want to upgrade to. If you do not, your engine may be upgraded to a version that is not the latest one.

For Linux, OS X, or Unix:

aws neptune modify-db-cluster \ --db-cluster-identifier (your-neptune-cluster) \ --engine neptune \ --engine-version (new-engine-version) \ --apply-immediately

For Windows:

aws neptune modify-db-cluster ^ --db-cluster-identifier (your-neptune-cluster) ^ --engine neptune ^ --engine-version <new-engine-version> ^ --apply-immediately

Instead of --apply-immediately, you can specify --no-apply-immediately.

If your cluster uses a custom cluster parameter group, be sure to include this paramater to specify it:

--db-cluster-parameter-group-name (name of the custom DB cluster parameter group)

Similarly, if any instances in the cluster use a custom DB parameter group, be sure to include this parameter to specify it:

---db-instance-parameter-group-name (name of the custom instance parameter group)