Update to 5.29.0 get frozen

Question

When updating civicrm/civicrm-core (5.28.3 => 5.29.0), the process get frozen while

[Executed: Upgrade DB to 5.29.alpha1: Fill civicrm_relationship_cache (1 => 5000)]

After reinstallation of a backup and removal of all caches, still the update gives a same frozen installation.

===========

Here's what I found in the Civi logs:

465 Sep 07 20:44:40 [info] $CRM_Queue_Page_AJAX_runNext_error = PEAR_Exception: "DB Error: constraint violation"

421 Sep 07 20:44:40 [debug] $backTrace = #0 /PATH/vendor/civicrm/civicrm-core/CRM/Core/Error.php(937): CRM_Core_Error::backtrace("backTrace", TRUE)

385 Sep 07 20:44:40 [error] $Fatal Error Details = Array

383 Sep 07 20:44:39 [info] Running task: Upgrade DB to 5.29.alpha1: Fill civicrm_relationship_cache (5001 => 10000)

381 Sep 07 20:44:37 [info] Running task: Upgrade DB to 5.29.alpha1: Fill civicrm_relationship_cache (1 => 5000)

379 Sep 07 20:44:37 [info] Running task: Install eventcart extension

377 Sep 07 20:44:36 [info] Running task: Upgrade DB to 5.29.alpha1: SQL

375 Sep 07 20:44:36 [info] Running task: Upgrade DB to 5.29.alpha1

373 Sep 07 20:44:35 [info] Running task: Begin Upgrade to 5.29.alpha1

371 Sep 07 20:44:35 [info] Running task: Checking extensions

369 Sep 07 20:44:34 [info] Running task: Cleanup old files

=========

In Drupal's logs :

Message Warning: Declaration of CRM_Volunteer_BAO_Project::copyValues(&$params, $serializeArrays = false) should be compatible with CRM_Core_DAO::copyValues($params) in require_once() (line 36 of /PATH/web/sites/default/files/civicrm/ext/org.civicrm.volunteer/CRM/Volunteer/BAO/Project.php)

Answer 1

We got this on one of the db upgrades. For us, it was due to few entries in civicrm_relationship table which were attached to permanently deleted contact ids. You can follow the below steps to complete the upgrade process.

• Take a separate back up for civicrm_relationship table.

• Check invalid entries using -

  select id 
  from civicrm_relationship 
  where contact_id_a not in (select id from civicrm_contact) OR contact_id_b  not in (select id from civicrm_contact)
  

• Delete these rows

  delete from civicrm_relationship 
  where contact_id_a not in (select id from civicrm_contact) OR contact_id_b  not in (select id from civicrm_contact)
  

Complete the upgrade process. Hope that works.

Answer 2

I had a similar problem, but only on a Drupal 8 site I upgraded; the others went fine.

I ran the following SQL to create the new table civicrm_relationship_cache, then ran cv upgrade:db --retry so that CiviCRM would pick up from where it had failed.

CREATE TABLE `civicrm_relationship_cache` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Relationship Cache ID',
  `relationship_id` int(10) unsigned NOT NULL COMMENT 'id of the relationship (FK to civicrm_relationship.id)',
  `relationship_type_id` int(10) unsigned NOT NULL COMMENT 'id of the relationship type',
  `orientation` char(3) COLLATE utf8_unicode_ci NOT NULL COMMENT 'The cache record is a permutation of the original relationship record. The orientation indicates whether it is forward (a_b) or reverse (b_a) relationship.',
  `near_contact_id` int(10) unsigned NOT NULL COMMENT 'id of the first contact',
  `near_relation` varchar(64) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT 'name for relationship of near_contact to far_contact.',
  `far_contact_id` int(10) unsigned NOT NULL COMMENT 'id of the second contact',
  `far_relation` varchar(64) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT 'name for relationship of far_contact to near_contact.',
  `is_active` tinyint(4) DEFAULT 1 COMMENT 'is the relationship active ?',
  `start_date` date DEFAULT NULL COMMENT 'date when the relationship started',
  `end_date` date DEFAULT NULL COMMENT 'date when the relationship ended',
  PRIMARY KEY (`id`),
  UNIQUE KEY `UI_relationship` (`relationship_id`,`orientation`),
  KEY `index_nearid_nearrelation` (`near_contact_id`,`near_relation`),
  KEY `index_nearid_farrelation` (`near_contact_id`,`far_relation`),
  KEY `index_near_relation` (`near_relation`),
  KEY `FK_civicrm_relationship_cache_relationship_type_id` (`relationship_type_id`),
  KEY `FK_civicrm_relationship_cache_far_contact_id` (`far_contact_id`),
  CONSTRAINT `FK_civicrm_relationship_cache_far_contact_id` FOREIGN KEY (`far_contact_id`) REFERENCES `civicrm_contact` (`id`) ON DELETE CASCADE,
  CONSTRAINT `FK_civicrm_relationship_cache_near_contact_id` FOREIGN KEY (`near_contact_id`) REFERENCES `civicrm_contact` (`id`) ON DELETE CASCADE,
  CONSTRAINT `FK_civicrm_relationship_cache_relationship_id` FOREIGN KEY (`relationship_id`) REFERENCES `civicrm_relationship` (`id`) ON DELETE CASCADE,
  CONSTRAINT `FK_civicrm_relationship_cache_relationship_type_id` FOREIGN KEY (`relationship_type_id`) REFERENCES `civicrm_relationship_type` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=8191 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

Answer 3

@Ichi has a point as I am troubleshooting some issues and have just done exactly what was suggested. You may need to restore your WP DB and CiviCRM DB fro your existing DBs after fresh installs of WP and CiviCRM. A few changes to the WP and possibly CiviCRM table name prefixes in wp_config.php and then civicrm.settings.php and you should be right to go. Good luck!