-
Notifications
You must be signed in to change notification settings - Fork 9.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
provider/aws: Add AWS RDS Read Replica #1946
Conversation
Implementation is (mostly) done. You can create, destroy, and promote a replica. To promote, simply remove the The acceptance test is incomplete, but I wanted to see if anyone had feedback on implementation / usage. |
cc @radeksimko, @ryanking as at least 2 people who I know requested this in some fashion 😄 |
Interface lgtm. |
Overall looks good, I have not been looking at the API docs yet, but since we gonna be able to build a M-S-S RDS cluster, it would be nice to test typical scenarios, like engine upgrade. I know that RDS does some clever things like "upgrade each slave separately first", then upgrade master, while promoting one of the slaves to master = no downtime caused. I'm not sure if all this happens under the hood automatically, I haven't tried that yet, but it's a typical scenario that should work well. |
Wow, is this process documented somewhere? I didn't read the docs entirely so I may have just missed it. Seems like promoting a follower would be a bad thing, since it has different address. Unless you're talking about their HA setup ( What are you thinking I need to do here to accommodate? |
Like I mentioned, I did not actually experienced this, I've just read it somewhere, can't remember where, sorry... What I was rather trying to suggest is to battle test this in situations, when you upgrade certain things. Just make sure that the most basic expectable upgrade paths are working. |
7e4358c
to
1230a7e
Compare
1230a7e
to
6b6aa86
Compare
Rebased on master and added an acceptance test. @phinze please review when you get a chance. |
more information on using Replication. | ||
|
||
|
||
~> **NOTE:** Removing the `relicate_source` attribute from an existing RDS |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, typo here - relicate_source
=> replicate_source
Overall LGTM. 👍
yet I haven't actually tried building a replicated RDS outside of the test suite. This resource should make decent amount of people happier. 😄 |
remove typos, debugging, and try spelling things correctly
@@ -65,6 +66,17 @@ The following arguments are supported: | |||
* `apply_immediately` - (Optional) Specifies whether any database modifications | |||
are applied immediately, or during the next maintenance window. Default is | |||
`false`. See [Amazon RDS Documentation for more for more information.](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html) | |||
* `replicate_source` - (Optional) Specifies that this resource is a Replicate |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's replicate_source_db
in code and replicate_source
here.
One wee docs thing, but otherwise LGTM! |
provider/aws: Add AWS RDS Read Replica
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. |
My proposal for adding support to for read replicas to
resource_aws_db
, by way of adding areplicate_source_db
attribute, referencing theidentifier
of the source database.Caveats:
username
,password
,engine
). Many of these are required when creating a database instance, but not when creating a replica. The trouble there is if being a replica is just a flag on a resource, that resource still needs those required attributes, even if they're ignored (inherited) from the source. Until Terraform has aValidateFunc
orRequiredIf
concept(s), we're stuck repeating ourselves.PromoteReadReplica
API call when thereplicate_source_db
attribute is removed in the configuration. This may be a surprise to some users, since we can't notify them that "removing this attribute makes a full read/write database" duringplan
.Example config:
In practice, users may want to manually duplicate all those fields. In the implementation, we'll have to ignore most of them that don't apply.
The fields that are applicable to replica creation:
Relevant docs:
create
Things:
I welcome thoughts on this approach