A manufacturing company's website uses an Amazon Aurora PostgreSQL DB cluster. Which configurations will result in the LEAST application downtime during a failover? (Choose three.)
A.
Use the provided read and write Aurora endpoints to establish a connection to the Aurora DB cluster.
B.
Create an Amazon CloudWatch alert triggering a restore in another Availability Zone when the primary Aurora DB cluster is unreachable.
C.
Edit and enable Aurora DB cluster cache management in parameter groups.
D.
Set TCP keepalive parameters to a high value.
E.
Set JDBC connection string timeout variables to a low value.
ACE
A: We should use read/cluster endpoints of aurora. If we use other endpoints like instance endpoint, custom endpoint, it might not work correctly after faiover.
B: Aurora failover within region is automatic so we don't need cloudwatch alert to do anything
C. Cluster cache management will help to warm up the cache on the new primary instance --> no high load on the new primary instance
D. F. Long dns cache or connection are enemies of failover so we should avoid that --> E is correct
Sorry for my english
ACE
Regarding C:
Fast recovery after failover with cluster cache management for Aurora PostgreSQL.
With cluster cache management, you set a specific reader DB instance as the failover target. Cluster cache management ensures that the data in the designated reader's cache is kept synchronized with the data in the writer DB instance's cache. The designated reader's cache with prefilled values is known as a warm cache. If a failover occurs, the designated reader uses values in its warm cache immediately when it's promoted to the new writer DB instance. This approach provides your application much better recovery performance.
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.cluster-cache-mgmt.html
A E is correct
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.html
A. Use the endpoints to cluster.
x B cloudwatch...
x D. Set TCP keepalive parameters to a high value. (keep it low)
E. Set JDBC connection string timeout variables to a low value.
x F. Set Java DNS caching timeouts to a high value. (keep it low)
C is here
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.cluster-cache-mgmt.html
C. Edit and enable Aurora DB cluster cache management in parameter groups. (keeps cache in sync on replica)
A E is correct
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.html
C is here
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.cluster-cache-mgmt.html
A and E are correct. Not sure of third one. C is for keeping the cache warm on replica so that after failover performance is not degraded. Purpose of CCM is not to reduce downtime.
Based on the link below, the answer looks like it should be ADE. Not sure where it says C is an option to ensure a fast failover.
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.html#AuroraPostgreSQL.BestPractices.FastFailover.TCPKeepalive
D is not correct. You should set TCP keepalive to low value, not high one.
Enabling TCP keepalive parameters and setting them aggressively ensures that if your client is no longer able to connect to the database, then any active connections are quickly closed. This action allows the application to react appropriately, such as by picking a new host to connect to
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
Mickysingh
Highly Voted 3 years, 8 months agoLMax
3 years, 7 months agoim_not_robot
Highly Voted 2 years, 4 months agoroymunson
Most Recent 1 year, 8 months agoIhorK
1 year, 10 months agosatishstechie
2 years, 5 months agorags1482
2 years, 6 months agopraffuln
3 years agonovice_expert
3 years, 1 month agoRotterDam
3 years, 3 months agolokeshM
3 years, 7 months agoaws4myself
3 years, 7 months agoguru_ji
3 years, 7 months agoChauPhan
3 years, 7 months agoDip11
3 years, 7 months agojyrajan
3 years, 7 months agoChauPhan
3 years, 7 months agoWindy
3 years, 8 months agomyutran
3 years, 8 months ago