Design and implement QA/PRD RDS data update workflow

[logstar]

When OpenPedCan-analysis releases a new version of data, OpenPedCan-api needs to update the data in QA/PRD/DEV RDS database instances to use the newly released data.

The down time for QA and PRD RDS database instances should be minimized, in order to prevent PedOT outage. The DEV RDS instance could be used to test the data updating workflow.

The current data loading time is about 4 hours. During data loading, any request on non-testing endpoints will lead to long wait time due to missing database index, and the response may be incorrect. When new endpoints are developed, more data will be loaded, and the data loading time could exceed 8 hours.

Following are some approaches that we could discuss further. Any viable other approach can also be discussed.

• Create new RDS instance. Load new version of data into the RDS instance. Point QA/PRD/DEV API HTTP server to the new RDS instance.
• Make QA/PRD API HTTP server unavailable. Delete current data. Load new data into database server. Make QA/PRD API HTTP server available.

cc @taylordm @chinwallaa @afarrel

[logstar]

Closed with the following workflow implemented.

1. Create a new database on the same DEV/QA/PRD RDS instance.
2. Load data into the new database.
3. Deploy API HTTP server with the new database.