Socorro:Releases/18: Difference between revisions
| Line 13: | Line 13: | ||
This database upgrade takes around 1/2 hour to run, assuming a 2-week backfill of the new matviews. Should we decide to do more than 2 weeks of backfill, this can be adjusted by editing upgrade.sh. | This database upgrade takes around 1/2 hour to run, assuming a 2-week backfill of the new matviews. Should we decide to do more than 2 weeks of backfill, this can be adjusted by editing upgrade.sh. | ||
This database upgrade is lock-sensitive. As such, it requires the downtime per above. | This database upgrade is lock-sensitive. As such, it requires the downtime per above. This downtime needs to include processors, monitor, web application, and cron jobs. | ||
This database upgrade involves a number of irreversable changes. As such, two additional steps are required before deploying it: | This database upgrade involves a number of irreversable changes. As such, two additional steps are required before deploying it: | ||
Revision as of 18:28, 12 September 2012
Upgrade Steps
This upgrade requires a downtime. Likely the downtime will only be 1/2 hour, but we should schedule a 1-hour downtime just in case. Both the processors and the web UI should be down during the upgrade.
Database changes need to be deployed first, then UI/mware changes.
Database Upgrade
IMPORTANT: Several hours before the upgrade, we need to do a full archival backup of the pre-Mobeta database. We will also need to coordinate with NetOps about failover.
As usual, run "18.0/upgrade.sh breakpad".
This database upgrade takes around 1/2 hour to run, assuming a 2-week backfill of the new matviews. Should we decide to do more than 2 weeks of backfill, this can be adjusted by editing upgrade.sh.
This database upgrade is lock-sensitive. As such, it requires the downtime per above. This downtime needs to include processors, monitor, web application, and cron jobs.
This database upgrade involves a number of irreversable changes. As such, two additional steps are required before deploying it:
- Archival final "pre-mobeta" offsite backup. See bug: https://bugzilla.mozilla.org/show_bug.cgi?id=762305
- Disable replication to master02 before running the upgrade, and do not restore it until after QA verification. This may then require a full resync of master02.
Cron job adjustments
- remove oldtcbs cron (cron_aggregates.sh) for bug 778255
- dev - Sep 5 09:04
- stage - TODO
- prod - TODO