Page MenuHomePhabricator

Configure new CiviCRM staging instance for testing 4.6 upgrade
Closed, ResolvedPublic

Description

  • 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.

Related Objects

StatusAssignedTask
OpenNone
Resolvedmepps
ResolvedNone
Resolvedawight
ResolvedEileenmcnaughton
ResolvedNone
ResolvedEileenmcnaughton
ResolvedEileenmcnaughton
ResolvedEileenmcnaughton
ResolvedNone
Resolvedawight
ResolvedDStrine
ResolvedEileenmcnaughton
ResolvedEileenmcnaughton
DeclinedEileenmcnaughton
Resolvedawight
Resolvedawight
Resolvedawight
Resolvedawight
OpenEileenmcnaughton
ResolvedNone
Resolvedawight

Event Timeline

awight created this task.Sep 11 2015, 7:10 PM
awight raised the priority of this task from to Normal.
awight updated the task description. (Show Details)
awight added subscribers: Aklapper, atgo, awight, gerritbot.

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.

awight moved this task from Backlog to Done on the Fundraising Sprint UB40 board.Sep 30 2015, 11:20 PM
awight added a comment.Oct 1 2015, 7:41 AM

@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.

awight closed this task as Resolved.Oct 8 2015, 7:28 PM
awight set Security to None.

Note to anyone trying this--you need to drop and recreate the dev_* databases before importing a dump.

mmodell removed a subscriber: awight.Jun 22 2017, 9:37 PM