terraform-aws-rds-aurora
terraform-aws-rds-aurora copied to clipboard
Multi-AZ ServerlessV2 Cluster
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.

- [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
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"} }
I'm having the same problem - serverless v2 clusters being created and reported as Multi-AZ=No and instances in the same AZ
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.
I have raised a ticket with AWS support, I will let you know what they say :)
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
- adding Via Cli Specify the --availability-zone us-east-1b to mention manually the --availability-zone
- 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.
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
This issue was automatically closed because of stale in 10 days
This issue has been resolved in version 7.4.0 :tada:
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 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
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.