Maintaining an Amazon Aurora DB cluster - Amazon Aurora
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Maintaining an Amazon Aurora DB cluster

Periodically, Amazon RDS performs maintenance on Amazon RDS resources. The following topics describe these maintenance actions and how to apply them.

Overview of DB cluster maintenance updates

Maintenance most often involves updates to the following resources in your DB cluster:

  • Underlying hardware

  • Underlying operating system (OS)

  • Database engine version

Updates to the operating system most often occur for security issues. We recommend that you do them as soon as possible. For more information about operating system updates, see Operating system updates for Aurora DB clusters.

Offline resources during maintenance updates

Some maintenance items require that Amazon RDS take your DB cluster offline for a short time. Maintenance items that require a resource to be offline include required operating system or database patching. Required patching is automatically scheduled only for patches that are related to security and instance reliability. Such patching occurs infrequently, typically once every few months. It seldom requires more than a fraction of your maintenance window.

Deferred DB instance and DB cluster modifications

Deferred DB cluster and instance modifications that you have chosen not to apply immediately are applied during the maintenance window. For example, you might choose to change DB instance classes or cluster or DB parameter groups during the maintenance window. Such modifications that you specify using the pending reboot setting don't show up in the Pending maintenance list. For information about modifying a DB cluster, see Modifying an Amazon Aurora DB cluster.

To see the modifications that are pending for the next maintenance window, use the describe-db-clusters Amazon CLI command and check the PendingModifiedValues field.

Eventual consistency for the DescribePendingMaintenanceActions API

The Amazon RDS DescribePendingMaintenanceActions API follows an eventual consistency model. This means that the result of the DescribePendingMaintenanceActions command might not be immediately visible to all subsequent RDS commands. Keep this in mind when you use DescribePendingMaintenanceActions immediately after using a previous API command.

Eventual consistency can affect the way you managed your maintenance updates. For example, if you run the ApplyPendingMaintenanceActions command to update the database engine version for a DB cluster, it will eventually be visible to DescribePendingMaintenanceActions. In this scenario, DescribePendingMaintenanceActions might show that the maintenance action wasn't applied even though it was.

To manage eventual consistency, you can do the following:

  • Confirm the state of your DB cluster before you run a command to modify it. Run the appropriate DescribePendingMaintenanceActions command using an exponential backoff algorithm to ensure that you allow enough time for the previous command to propagate through the system. To do this, run the DescribePendingMaintenanceActions command repeatedly, starting with a couple of seconds of wait time, and increasing gradually up to five minutes of wait time.

  • Add wait time between subsequent commands, even if a DescribePendingMaintenanceActions command returns an accurate response. Apply an exponential backoff algorithm starting with a couple of seconds of wait time, and increase gradually up to about five minutes of wait time.

Viewing pending maintenance updates

View whether a maintenance update is available for your DB cluster by using the RDS console, the Amazon CLI, or the RDS API. If an update is available, it is indicated in the Maintenance column for the DB cluster on the Amazon RDS console, as shown in this figure.

Maintenance action is available and will be applied at the next maintenance window.

If no maintenance update is available for a DB cluster, the column value is none for it.

If a maintenance update is available for a DB cluster, the following column values are possible:

  • required – The maintenance action will be applied to the resource and can't be deferred indefinitely.

  • available – The maintenance action is available, but it will not be applied to the resource automatically. You can apply it manually.

  • next window – The maintenance action will be applied to the resource during the next maintenance window.

  • In progress – The maintenance action is being applied to the resource.

If an update is available, you can do one of the following:

  • If the maintenance value is next window, defer the maintenance actions by choosing Defer upgrade from Actions. You can't defer a maintenance action that has already started.

  • Apply the maintenance actions immediately.

  • Apply the maintenance actions during your next maintenance window.

  • Take no action.

To take an action by using the Amazon Web Services Management Console
  1. Choose the DB instance or cluster to show its details.

  2. Choose Maintenance & backups. The pending maintenance actions appear.

  3. Choose the action to take, then choose when to apply it.

Pending maintenance item for an Aurora DB instance.

The maintenance window determines when pending operations start, but doesn't limit the total run time of these operations. Maintenance operations aren't guaranteed to finish before the maintenance window ends, and can continue beyond the specified end time. For more information, see Amazon RDS maintenance window.

You can also view whether a maintenance update is available for your DB cluster by running the describe-pending-maintenance-actions Amazon CLI command.

For information about applying maintenance updates, see Applying updates to a DB cluster.

Maintenance actions for Amazon Aurora

The following maintenance actions apply to Aurora DB clusters:

  • os-upgrade – Update the operating systems of all the DB instances in the DB cluster, using rolling upgrades. For more information, see Operating system updates for Aurora DB clusters.

  • system-update – Patch the DB engine for Aurora PostgreSQL.

The following maintenance actions apply to Aurora DB instances:

  • ca-certificate-rotation – Update the Amazon RDS Certificate Authority certificate for the DB instance.

  • hardware-maintenance – Perform maintenance on the underlying hardware for the DB instance.

  • system-update – Update the operating system for the DB instance.

Choosing the frequency of Aurora MySQL maintenance updates

You can control whether Aurora MySQL upgrades happen frequently or rarely for each DB cluster. The best choice depends on your usage of Aurora MySQL and the priorities for your applications that run on Aurora. For information about the Aurora MySQL long-term stability (LTS) releases that require less frequent upgrades, see Aurora MySQL long-term support (LTS) releases.

You might choose to upgrade an Aurora MySQL cluster rarely if some or all of the following conditions apply:

  • Your testing cycle for your application takes a long time for each update to the Aurora MySQL database engine.

  • You have many DB clusters or many applications all running on the same Aurora MySQL version. You prefer to upgrade all of your DB clusters and associated applications at the same time.

  • You use both Aurora MySQL and RDS for MySQL. You prefer to keep the Aurora MySQL clusters and RDS for MySQL DB instances compatible with the same level of MySQL.

  • Your Aurora MySQL application is in production or is otherwise business-critical. You can't afford downtime for upgrades outside of rare occurrences for critical patches.

  • Your Aurora MySQL application isn't limited by performance issues or feature gaps that are addressed in subsequent Aurora MySQL versions.

If the preceding factors apply to your situation, you can limit the number of forced upgrades for an Aurora MySQL DB cluster. You do so by choosing a specific Aurora MySQL version known as the "Long-Term Support" (LTS) version when you create or upgrade that DB cluster. Doing so minimizes the number of upgrade cycles, testing cycles, and upgrade-related outages for that DB cluster.

You might choose to upgrade an Aurora MySQL cluster frequently if some or all of the following conditions apply:

  • The testing cycle for your application is straightforward and brief.

  • Your application is still in the development stage.

  • Your database environment uses a variety of Aurora MySQL versions, or Aurora MySQL and RDS for MySQL versions. Each Aurora MySQL cluster has its own upgrade cycle.

  • You are waiting for specific performance or feature improvements before you increase your usage of Aurora MySQL.

If the preceding factors apply to your situation, you can enable Aurora to apply important upgrades more frequently. To do so, upgrade an Aurora MySQL DB cluster to a more recent Aurora MySQL version than the LTS version. Doing so makes the latest performance enhancements, bug fixes, and features available to you more quickly.