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 the disruption to access to accurate data and to provide safeguards if the Metadb resychronization process fails and/or takes longer than expected.
Environment Definitions
FOLIO Production = the FOLIO Production application server, which is the data source for reporting databases
LDP = our current LDP production reporting database
Metadb1 = our current Metadb production reporting database
Metadb2 = a separate Metadb reporting database that does not become Metadb Production until updates, synchronization, and testing processes are complete (2-3 weeks)
Cutover Scenarios to Consider - Scenario 1 and Scenario 2
SCENARIO 1 (PREFERRED) | |||
| Date | Cornell Production Reporting Database | Environment Changes | Activity |
|---|---|---|---|
| February 3 - 7, 2025 | LDP | LDP and Metadb1 | Reporting Team sets up dashboards, automated reports, and other processes to use Metadb1 as data source during cutover period |
| February 7, 2025 | Metadb1 | FOLIO Production | FOLIO Production is upgraded from PostgreSQL version 12 to 16. FOLIO Production is set up as source for continued streaming data to Metadb1. LDP is saved, but "frozen" without data updates. |
start February 7, 2025 | Metadb1 | FOLIO Production Metadb2 | Metadb2 is upgraded from PostgreSQL version 12 to 16. Start data resynchronization process between FOLIO Production and Metadb2. |
for one week following | Metadb1 | Metadb2 | Reporting and Automation Teams test data accuracy and performance on updated and resynchronized Metadb2. |
March 1 | Metadb2 or Metadb1, depending on "Go/No Go" decision | Metadb2 | If decision is a "Go," Metadb2 becomes the production reporting database, and Metadb1 and LDP are retired. Reporting and Automation Teams set up dashboards, automated reports, and other processes to use Metadb2, or Hosting Team makes a seamless switch from Metadb1 to Metadb2 host addresses such that no host address changes are needed. If decision is "No Go" Metadb1 continues running as the production reporting database until Metadb2 is working properly. |
OR
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?
-When do you have to do a resynch?
when we update postgres (Yes)
when we update Metadb software (no?)
when we update to Eureka?
when we update to a new version of FOLIO on the application server?