terraform-aws-rds-aurora icon indicating copy to clipboard operation
terraform-aws-rds-aurora copied to clipboard

Multi-AZ ServerlessV2 Cluster

Open travis-jorge opened this issue 3 years ago β€’ 5 comments

Description

I have several ServerlessV2 Clusters and sometimes they startup with one instance in one az and one reader in another but it's not guaranteed. Is there something I'm missing to make sure it's always Multi-AZ. The Console also specifically says it's not Multi-AZ. I understand that ServerlessV2 Clusters are by their nature Multi-AZ but the reader in this scenario should be able to be forced into a separate az than the writer.

image

  • [X] βœ‹ I have searched the open/closed issues and my issue is not listed.

Versions

  • Module version [Required]: 7.1
  • Terraform version: 1.0.1
  • Provider version(s): 4.12.0

Reproduction Code [Required]

module "db" {
  source                          = "terraform-aws-modules/rds-aurora/aws"
  version                         = "7.1.0"
  name                            = "${module.this.id}-cluster"
  engine                          = data.aws_rds_engine_version.postgresql.engine
  engine_mode                     = "provisioned"
  engine_version                  = data.aws_rds_engine_version.postgresql.version
  subnets                         = local.isolated_subnets
  db_subnet_group_name            = aws_db_subnet_group.rds_isolated.name
  create_db_subnet_group          = false
  vpc_security_group_ids          = [aws_security_group.rds_sg.id]
  vpc_id                          = local.vpc_id
  monitoring_interval             = var.monitoring_interval
  skip_final_snapshot             = var.skip_final_snapshot
  apply_immediately               = var.apply_immediately
  storage_encrypted               = true
  db_parameter_group_name         = aws_db_parameter_group.aurora_db_postgresql13_parameter_group.id
  db_cluster_parameter_group_name = aws_rds_cluster_parameter_group.aurora_cluster_postgresql13_parameter_group.id
  database_name                   = var.database_name
  create_random_password          = false
  master_username                 = var.master_username
  master_password                 = random_password.master_password.result
  deletion_protection             = true
  create_security_group           = false
  backup_retention_period         = var.backup_retention_period
  kms_key_id                      = aws_kms_key.request_svc_kms_key.arn
  iam_role_name                   = "rds-enh-monitor-${module.this.id}"
  serverlessv2_scaling_configuration = {
     min_capacity = var.rds_min_capacity #.5
     max_capacity = var.rds_max_capacity #10
  }

  instance_class = "db.serverless"
  instances = {
    1 = {
      identifier = "${module.this.id}"
    },
    2 = {}
  }
  tags = module.this.tags
}

Steps to reproduce the behavior:

using the config above I would expect it to make two instances a writer and a reader. They should be in different AZ

Expected behavior

They should always be Multi-AZ

Actual behavior

It's random where they get placed sometimes it's in different AZ sometimes it's the same

travis-jorge avatar Jun 22 '22 19:06 travis-jorge

Adding AZ to the instance worked for me perhaps it can help you too instances = { one = {availability_zone="eu-central-1c"} two = {availability_zone="eu-central-1b"} }

tapulskis avatar Jun 29 '22 13:06 tapulskis

I'm having the same problem - serverless v2 clusters being created and reported as Multi-AZ=No and instances in the same AZ

matt-whyard avatar Jun 30 '22 14:06 matt-whyard

Please raise a ticket through AWS to request guidance. This module does not handle scheduling; it just interacts with the API provided through the provider.

bryantbiggs avatar Jun 30 '22 14:06 bryantbiggs

I have raised a ticket with AWS support, I will let you know what they say :)

james-green-affinity avatar Jul 11 '22 15:07 james-green-affinity

Looks like they recognised the problem however they are unwilling to fix it!

Is there anything you guys can do with this module to avoid the hardcoding of it or is it something we will need to live with?

-- AWS Reply --

I hope this email finds you well! Thank you for contacting AWS Premium Support and for being so patient as your case was being worked on. It is greatly appreciated.

I have run through some random test in creating the multiple reader to non Multi Az aurora cluster vs Multi Az aurora cluster.

The results are eventually random in both cases , but will add that Multi Az aurora cluster ensures the new reader is in random AZ and random location to take advantage of MultiAZ distribution.

Where as non Multi AZ aurora cluster might create some reader in same az in same location but eventually it will put into random AZ location ,

for non MultiAZ aurora cluster to avoid that you can use following

  1. adding Via Cli Specify the --availability-zone us-east-1b to mention manually the --availability-zone
  2. adding Via console using the Modify--> Add reader , under connectivity you have option to chose the Availability Zone under Availability ZoneInfo , if no preference it will pickup random.

e.g option to add zone when adding via cli

aws rds create-db-instance --db-instance-identifier db1-instance-db2 --db-cluster-identifier db2 --engine aurora-postgresql --db-instance-class db.serverless --availability-zone us-east-1b

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.

Within each AWS Region, Availability Zones (AZs) represent locations that are distinct from each other to provide isolation in case of outages. We recommend that you distribute the primary instance and reader instances in your DB cluster over multiple Availability Zones to improve the availability of your DB cluster. That way, an issue that affects an entire Availability Zone doesn't cause an outage for your cluster.

james-green-affinity avatar Jul 21 '22 08:07 james-green-affinity

This issue has been automatically marked as stale because it has been open 30 days with no activity. Remove stale label or comment or this issue will be closed in 10 days

github-actions[bot] avatar Aug 21 '22 00:08 github-actions[bot]

This issue was automatically closed because of stale in 10 days

github-actions[bot] avatar Aug 31 '22 00:08 github-actions[bot]

This issue has been resolved in version 7.4.0 :tada:

antonbabenko avatar Sep 07 '22 11:09 antonbabenko

This issue has been resolved in version 7.4.0 πŸŽ‰

Hi @antonbabenko it isn't clear to me how this issue is fixed - can you explain?

matt-whyard avatar Sep 08 '22 08:09 matt-whyard

@matt-whyard Please check the description and the code changes here - https://github.com/terraform-aws-modules/terraform-aws-rds-aurora/pull/317#issue-1356176225

Also, there is a lot of useful information about how to use certain features in the examples/multi-az

antonbabenko avatar Sep 08 '22 08:09 antonbabenko

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

github-actions[bot] avatar Apr 13 '23 02:04 github-actions[bot]