How can a Database Specialist address these requirements with minimal user involvement?
Split up the DB cluster into two different clusters: one for OLTP and the other for reporting. Monitor and set up replication between the two clusters to keep data consistent.
Review all evaluate the peak combined workload. Ensure that utilization of the DB cluster node is at an acceptable level. Adjust the number of instances, if necessary.
Use the stop cluster functionality to stop all the nodes of the DB cluster during times of minimal workload. The cluster can be restarted again depending on the workload at the time.
Set up automatic scaling on the DB cluster. This will allow the number of reader nodes to adjust automatically to the reporting workload, when needed.
Explanations:
Splitting the DB cluster into two different clusters is unnecessary and increases complexity. It also requires managing replication between two clusters, which can introduce overhead and isn’t needed for the given workload.
Reviewing and adjusting the number of instances based on the peak workload can help, but this requires manual intervention. The goal is to minimize user involvement, and this approach does not meet that requirement.
Stopping the cluster during times of minimal workload is not a viable solution for Aurora, as stopping a cluster in Amazon Aurora is not a feature. Aurora clusters are always available, and this would require manual intervention each time to stop and restart the cluster.
Setting up automatic scaling for the DB cluster, especially for the reader nodes, is a correct solution. This approach dynamically adjusts to the reporting workload and minimizes user involvement, reducing costs during periods of lower demand.
In my experience, the answer is:
Set up automatic scaling on the DB cluster. This will allow the number of reader nodes to adjust automatically to the reporting workload, when needed.