- Create a new subdomain and website on the staging server, with client cert auth.
- Directory root should be group-writeable like the others. We'll unpack a tarball there and do some other crazy stuff.
- Needs a new clone of the database. Since we'll be running the database migration repeatedly, it should be easy to reload the 4.2 db. Ops-less reload of the database would be a bonus.
Description
Event Timeline
Bump--we need our first database reset. A fresh copy of production civicrm and drupal would be perfect, thanks!
@awight who are you trying to ping? No one is assigned to this. Are the right people subscribed?
@Jeff_Green: Turns out we need to drop a bunch of tables before restarting the upgrade, do you know of a convenient way to do that?
* ERROR DEBUGINFO: RENAME TABLE `civicrm_contribution_type` TO `civicrm_financial_type` [nativecode=1050 ** Table 'civicrm_financial_type' al ready exists] #0 [internal function](): CRM_Core_Error::exceptionHandler(Object(DB_Error))
@Jgreen: fyi, I dropped the database and recreated. Works for me, as long as this doesn't mess with the permissions.
@Jgreen, what do you think about mysqldbcopy? There's even a --multiprocess flag for two-handed forkbombing... The db restore currently takes about 4 hours, which isn't exactly an inconvenience yet, but long enough that I'm interested in making improvements ahead of the next time we need to test an upgrade. Looks like the mysql-utils package gets much better performance with version 1.3.6, which might be ported by the time we do another Civi leap.
Random note to self: Put the staging site into maintenance mode, cd $CRM/drupal && drush vset maintenance_mode 1
I've never used it, let's give it a try. We can stop replication before
starting a copy so the civi+drupal db's stay in sync.
Note to anyone trying this--you need to drop and recreate the dev_* databases before importing a dump.