Repository navigation
Decommission mysql databases #5643
Description
Activity
Consider what we could do to handle those two SSB-solrcloud databases which we might need to migrate.
If we can get inventory running without solr, then we don't need to support SSB-solrcloud.
- added a parent issue
on May 14, 2026 - removed a parent issue
on Jul 7, 2026 - moved this from O&M Specific Backlog to 📟 Sprint Backlog (Top Priority) in data.gov team board
on Jul 15, 2026 - added a parent issue
on Jul 28, 2026 @jbrown-xentity would you note your concerns about this being done after catalog old is deleted
- moved this from 📟 Sprint Backlog (Top Priority) to Not Ready/Draft in data.gov team board
on Jul 29, 2026 - removed a parent issue
on Jul 29, 2026 This doesn't need to be done after catalog old is completed. It needs to be done after #6033, the first ticket in that epic (I slotted it in priority and in the epic below that first item).
The mySQL DB's are for the SSB, managing usernames, passwords, deployments, etc for SOLR. As long as SOLR is in use (or needs to be available, like for catalog-old), then we shouldn't delete these.
Once it is confirmed catalog-old is ready for deletion, doing this first makes sense (I've seen cloud systems charge for using out of date DB versions, and don't want us or cloud.gov to get charged). Then the rest of catalog (and all of the SSB really) can be decommissioned.
Tagging @SueValente for notification and @FuhuXia for verification.
This ticket is expected to require no action; it is created for tracking purposes.
We received notification on 2026-01-12 that AWS will end support for MySQL 8.0 in July. The affected MySQL databases support applications that are scheduled for decommissioning, so the databases will be removed along with the applications. No migration is required.
Space and MySQL RDS service names: