Configuring a second Aurora Serverless cluster node to get high availability

[erno]

From first blush I think this should work just by copying the "maindbDBWriterInstance" to another name and switching the availability zone there and altering promotion tier, since threre are no fixed "reader" and "writer" roles in serverless v2 but would be nice to get a "code review" for it. (Should copilot be using something else than "writer"? or maybe i misunderstood something?)

    Metadata:
      'aws:copilot:description': 'The maindb Aurora Serverless v2 writer instance'
    Type: 'AWS::RDS::DBInstance'
    Properties:
      DBClusterIdentifier: !Ref maindbDBCluster
      DBInstanceClass: db.serverless
      Engine: 'aurora-postgresql'
      PromotionTier: 1
      EnablePerformanceInsights: true
      AvailabilityZone: !Select
        - 0
        - !GetAZs
          Ref: AWS::Region

So, add a block like this?

    Metadata:
      'aws:copilot:description': 'The maindb Aurora Serverless v2 writer instance'
    Type: 'AWS::RDS::DBInstance'
    Properties:
      DBClusterIdentifier: !Ref maindbDBCluster
      DBInstanceClass: db.serverless
      Engine: 'aurora-postgresql'
      PromotionTier: 2
      EnablePerformanceInsights: true
      AvailabilityZone: !Select
        - 1
        - !GetAZs
          Ref: AWS::Region

[iamhopaul123]

Hello @erno. Yes, I think the snippet makes sense to me mostly. Maybe you don't need to specify the promotion tier at all since they are exactly the same? And you can't specify AvailabililityZone if it is a multi-AZ deployment according to this doc. You can refer to a CFN example here

[erno]

Alright, many thanks!

[erno]

Just an addition - upon rereading the docs it seems this is not required to get automatic recovery for AZ failure:

The cluster volume spans multiple Availability Zones (AZs) in a single AWS Region, and each Availability Zone contains a copy of the cluster volume data. This functionality means that your DB cluster can tolerate a failure of an Availability Zone without any loss of data and only a brief interruption of service.

If the primary instance in a DB cluster fails, Aurora automatically fails over to a new primary instance in one of two ways:

• By promoting an existing Aurora Replica to the new primary instance

• By creating a new primary instance

(from https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.AuroraHighAvailability.html)

[iamhopaul123]

Which do you think it's not required? The promotion tier?

[erno]

I was responding to myself, and reconsidering whether we need to do this at all, and being a bit unclear :)

I meant it's not required to have a second cluster node to have automatic recovery, according to the documentation I quoted as far as I understand, the altnernative is that we let Aurora automatically create a replacement instance. Presumably this takes a longer time, even manually adding a node takes like 20 minutes to finish the deploy update, so it's not "high-availability" in the sense that there's a break in service but you save the cost of running a second node.

I take it "The cluster volume spans multiple Availability Zones (AZs) in a single AWS Region, and each Availability Zone contains a copy of the cluster volume data" means that your data is still intact in both redundant node and non-redundant cases, if there's a AZ failure or the single node crashes.

[erno]

Continuing my monologue .. but I guess if I want to rely on a replacement being automatically created in event of AZ failure, I should still remove the AvailabilityZone specification in this?

[iamhopaul123]

Yeah that's what I think too after reading the link you posted and this.

[erno]

Update:

It seems it doesn't work to remove the AvailabilityZone section there. It reults in CF removing the instance (failing over to higher placen of existence..?). Further careful reading of the high availability doc yielded this bullet there: "If your provisioned or Aurora Serverless v2 cluster only contains a single DB instance, or if the primary instance and all reader instances are in the same AZ, make sure to manually create one or more new DB instances in another AZ."

So it seems that if I don't want to have more cluster members, there's no way to configure automatic recovery from AZ loss, there's a manual step to be performed.

It seems this is different in Aurora Serverless V2 vs V1 - in V1 it was advertised a few years ago that "In the unlikely event that an entire Availability Zone becomes unavailable, Aurora Serverless v1 launches a new instance for your cluster in one of the other Availability Zones. We refer to this capability as automatic Multi-AZ failover".