Skip to content

Why does downtime occur for my Amazon Aurora DB clusters?

5 minute read
0

I want to understand why downtime occurs for my Amazon Aurora DB clusters.

Resolution

The following reasons can cause downtime for your Aurora DB instance.

Engine version upgrades

Major and minor version upgrades cause downtime for your entire Aurora DB cluster. Before you upgrade a production DB cluster, test the upgrade process on a test DB cluster. Verify the duration of the process, and then validate your applications before you perform the upgrade.

You can also use Aurora Blue/Green Deployments to upgrade the major or minor version of your cluster. When you use a blue/green deployment, downtime typically lasts less than 1 minute.

Automatic minor version upgrades

Automatic minor version upgrades cause downtime for your entire Aurora DB cluster. Aurora applies minor version upgrades during the cluster maintenance window. If you don't want Aurora to automatically apply minor version upgrades, then turn off the option on your DB instances.

For more information, see Upgrading the minor version or patch level of an Aurora MySQL DB cluster.

Note: Downtime doesn't occur when you turn on automatic minor version upgrades. Downtime occurs only when Aurora applies the automatic upgrade.

Aurora DB cluster failover events

If your DB cluster has Aurora replicas, then Aurora promotes a replica to the primary instance during failover events. A brief downtime occurs, and read and write operations fail with an exception. Service typically restores in less than 120 seconds and often less than 60 seconds.

To increase the availability of your DB cluster, create one or more Aurora replicas in two or more different Availability Zones. For more information, see Fault tolerance for an Aurora DB cluster.

Aurora DB cluster maintenance tasks

Some maintenance tasks, such as updates to the operating system (OS) or database patching, cause your DB cluster to go offline for a short period of time. For more information, see Maintaining an Amazon Aurora DB cluster.

Maintenance window modifications

Downtime doesn't automatically occur when you modify the maintenance window. Your DB cluster might have pending actions. If you modify the maintenance window, then you immediately apply the pending actions and downtime occurs. For more information about maintenance window modifications, see What do I need to know about the Amazon RDS maintenance window?

DB cluster or DB instance reboots

Downtime occurs when you reboot a DB cluster or DB instance. The time that's required to reboot each DB instance in your cluster depends on the database activity at the time of reboot. Downtime also depends on the recovery process of your DB engine.

DB instance class modifications

When you modify the DB instance class, downtime occurs on the specified DB instance but not the entire cluster.

New DB cluster parameter group or DB parameter group associations

When you associate a new DB cluster parameter group to the DB cluster or DB parameter group to the DB instance, downtime doesn't occur automatically. Downtime only occurs when you must reboot to apply the changes in the parameter group. For example, to apply changes in the DB cluster parameter group, you must reboot the primary DB instance. To apply changes in a DB parameter group, you must reboot the DB instance.

Specific settings in your DB cluster or instance

The following are common settings modifications that cause downtime. For a full list of settings and information about whether they cause downtime, see Settings for Amazon Aurora.

Parameter setting modifications in a DB cluster parameter group or DB parameter group

Database parameters are either static or dynamic. When you modify a static parameter setting in a DB cluster parameter group or DB parameter group, the change occurs after you manually reboot the DB instances in each associated DB cluster. Downtime occurs during the reboot.

But when you modify a dynamic parameter setting in a DB cluster parameter group or DB parameter group, the changes apply immediately to the DB cluster. There isn't downtime because you don't have to reboot the DB instance to modify dynamic parameters.

DB instance identifier modifications

You must reboot the DB instance to modify the DB instance identifier. Downtime occurs during this change.

Database port modifications

Downtime occurs when you modify the database port that you use to access your DB cluster because all the DB instances in the cluster immediately reboot.

CA modifications

Note: If you receive errors when you run AWS Command Line Interface (AWS CLI) commands, then see Troubleshooting errors for the AWS CLI. Also, make sure that you're using the most recent AWS CLI version.

If you modify the certificate authority (CA) for your DB instance's sever certificate, then downtime occurs for DB engines that don't support rotation without a restart.

To check whether your DB engine supports rotation without a restart, run the describe-db-engine-versions AWS CLI command.

Related information

Performing major version upgrades for Amazon Aurora MySQL with minimum downtime

AWS OFFICIALUpdated 5 months ago