Goals
Although the cutover period is projected to last up to a week, this could extend into two weeks or longer if data synchronization processes need to be restarted (as they did last time). We need to ensure that we have access to an accurate and complete reporting database source throughout the cutover period, ideally without having to change what is already in place for our dashboards, automated batch jobs, and automated reports. It is important to minimize both the disruption to access to accurate data and the risk of the Metadb resychronization process failing.
Environment Definitions
FOLIO Production = the FOLIO Production application server, which is the data source for reporting databases
...
SCENARIO 2 (BACKUP) | |||
| Date | Cornell Production Reporting Database | Environment Changes | Activity |
|---|---|---|---|
| February 3 - 7, 2025 | LDP | LDP | Reporting and Automation Teams set up dashboards, automated reports, and other processes to use LDP as data source during cutover period. |
| February 7, 2025 | LDP | LDP | FOLIO Production is upgraded from PostgreSQL version 12 to 16. FOLIO Production is set up as source for continued nightly LDP data transfers. |
start February 7, 2025 | LDP | Metadb1 | Start data resynchronization process between FOLIO Production and Metadb1. |
for one week following | LDP | Metadb1 | Reporting and Automation Teams test data accuracy and performance on updated and resynchronized Metadb1. Based on results of testing, Cornell makes "Go/No Go" decision to continue using LDP or to start using Metadb1 as production reporting database. |
March 1 | LDP or Metadb1, depending on "Go/No Go" decision | LDP | If "Go," Reporting and Automation Teams set up dashboards, automated reports, and other automation processes to use Metadb1. If "No Go," LDP continues to serve as production reporting database until Metadb1 is working properly. |
NOTES:
-Would using snapshots help?
-What about a 3rd scenario where the synchronization is done ahead of time?