Feature Request: Expose Multi-AZ Option for CreateDBClusterInput #475
Comments
toanctruong
changed the title
|
Hi @toanctruong thanks for the request. I'd like to hear more about your request. Amazon Aurora DB Clusters have multi-AZ enabled by deploying to three AZ with one being the primary and two failovers with a autoconfigured cluster endpoint. The cluster endpoint will automatically switch between the primary and failover instances as needed. If you're looking to create a Aurora DB not as a cluster but as a single instance or instance with fallover you can use the CreateDBInstance API operation which will allow you to enable or disable multi-AZ for these instance. Here and here is a good guide to how clusters are a collection of instances. |
|
Hi @jasdel thanks for following up. As far as I can tell (I may be wrong), creating a new Aurora DB Cluster utilizing the AWS SDK, the cluster gets created with the multi-az property set to "No". My assumption is that since that option is not exposed through "CreateDBClusterInput", AWS will default to "No" which is a property that cannot be changed after the fact. |
|
@toanctruong thanks for the update and clarification. I did some digging into this issue, and I don't see any way of creating a non-multi AZ cluster with the public RDS API. The RDS web console is doing something internally which does not look to be exposed via the public API. I'll reach out to the RDS team if creating a ClusterDB without Multi AZ replicas is possible with the public API. In addition I suggestion posting a thread on the RDS AWS forums. There may be others with this issue, and more request for it will help encourage implementation. |
jasdel
added
service-api
|
Hi @toanctruong I did some digging and have some information about how Aurora RDS instances and clusters work with Multi-AZ. Specifically a Aurora RDS deployment is always actually a cluster. A database storage cluster (Aurora) will always have to exist in three AZ's for redundancy, but you don't have to create a database head node or Aurora instance in more than one AZ.If you were to create an Aurora cluster through the console and choose multi-az, it would create you a primary head node in one AZ and a read replica in another (eg. multi-az). When selecting "No" for the multi-az deployment in the console, it will simply create you one head node in the particular AZ you choose. To create a single AZ deployment with the RDS API you can call Let us know if there if there is any additional information we can provide, or help with. |
|
Thanks for contacting us about this issue @toanctruong. I'm going to go ahead and close this issue. Please let us know if you have any other questions, or feedback. |
Breaking Change --- * Update SDK retry behavior * Significant updates were made the SDK's retry behavior. The SDK will now retry all connections error. In addition, to changing what errors are retried the SDK's retry behavior not distinguish the difference between throttling errors, and regular retryable errors. All errors will be retried with the same backoff jitter delay scaling. * The SDK will attempt an operation request 3 times by default. This is one less than the previous initial request with 3 retires. * New helper functions in the new `aws/retry` package allow wrapping a `Retrier` with custom behavior, overriding the base `Retrier`, (e.g. `AddWithErrorCodes`, and `AddWithMaxAttempts`) * Update SDK error handling * Updates the SDK's handling of errors to take advantage of Go 1.13's new `errors.As`, `Is`, and `Unwrap`. The SDK's errors were updated to satisfy the `Unwrap` interface, returning the underlying error. * With this update, you can now more easily access the SDK's layered errors, and meaningful state such as, `Timeout`, `Temporary`, and other states added to the SDK such as `CanceledError`. * Bump SDK minimum supported version from Go 1.12 to Go 1.13 * The SDK's minimum supported version is bumped to take advantage of Go 1.13's updated `errors` package. Services --- * Synced the V2 SDK with latest AWS service API definitions. SDK Features --- * `aws`: Add Support for additional credential providers and credential configuration chaining ([aws#488](aws/aws-sdk-go-v2#488)) * `aws/processcreds`: Adds Support for the Process Credential Provider * Fixes [aws#249](aws/aws-sdk-go-v2#249) * `aws/stscreds`: Adds Support for the Web Identity Credential Provider * Fixes [aws#475](aws/aws-sdk-go-v2#475) * Fixes [aws#338](aws/aws-sdk-go-v2#338) * Adds Support for `credential_source` * Fixes [aws#274](aws/aws-sdk-go-v2#274) * `aws/awserr`: Adds support for Go 1.13's `errors.Unwrap` ([aws#487](aws/aws-sdk-go-v2#487)) * `aws`: Updates SDK retry behavior ([aws#487](aws/aws-sdk-go-v2#487)) * `aws/retry`: New package defining logic to determine if a request should be retried, and backoff. * `aws/ratelimit`: New package defining rate limit logic such as token bucket used by the `retry.Standard` retrier. SDK Enhancements --- * `aws`: Add grouping of concurrent refresh of credentials ([aws#503](aws/aws-sdk-go-v2#503)) * Concurrent calls to `Retrieve` are now grouped in order to prevent numerous synchronous calls to refresh the credentials. Replacing the mutex with a singleflight reduces the overall amount of time request signatures need to wait while retrieving credentials. This is improvement becomes pronounced when many requests are made concurrently. * `service/s3/s3manager`: Improve memory allocation behavior by replacing sync.Pool with custom pool implementation * Improves memory allocations that occur when the provided `io.Reader` to upload does not satisfy both the `io.ReaderAt` and `io.ReadSeeker` interfaces. SDK Bugs --- * `service/s3/s3manager`: Fix resource leaks when the following occurred: * Failed CreateMultipartUpload call * Failed UploadPart call
Would be great if this option was exposed so then it could be exposed through Terraform for green field deployment code.
The text was updated successfully, but these errors were encountered: