Update auf 5.29.0 wird eingefroren

Question

Beim Aktualisieren von civicrm / civicrm-core (5.28.3 => 5.29.0) wird der Prozess währenddessen eingefroren

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

Nach der Neuinstallation einer Sicherung und dem Entfernen aller Caches führt das Update immer noch zu einer eingefrorenen Installation.

===========

Folgendes habe ich in den Civi-Protokollen gefunden:

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 Drupals Protokollen:

Meldungswarnung: Deklaration von CRM_Volunteer_BAO_Project :: copyValues ​​(& $ params, $serializeArrays = false) should be compatible with CRM_Core_DAO::copyValues($params) in require_once () (Zeile 36 von /PATH/web/sites/default/files/civicrm/ext/org.civicrm.volunteer/CRM/Volunteer/BAO/Project.php)

Answer 1

Wir haben dies bei einem der DB-Upgrades bekommen. Für uns lag es an wenigen Einträgen in der civicrm_relationshipTabelle, die an dauerhaft gelöschte Kontakt-IDs angehängt wurden. Sie können die folgenden Schritte ausführen, um den Upgrade-Vorgang abzuschließen.

• Nehmen Sie eine separate Sicherung für den civicrm_relationshipTisch.

• Überprüfen Sie ungültige Einträge mit -

  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)
  

• Löschen Sie diese Zeilen

  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)
  

Schließen Sie den Upgrade-Vorgang ab. Hoffe das funktioniert.

Answer 2

Die hinzugefügten Protokolle wurden in den ersten Beitrag verschoben

Answer 3

@Ichi hat einen Punkt, da ich einige Probleme behebe und genau das getan habe, was vorgeschlagen wurde. Möglicherweise müssen Sie Ihre WP-DB und CiviCRM-DB nach Neuinstallationen von WP und CiviCRM für Ihre vorhandenen DBs wiederherstellen. Ein paar Änderungen an den Präfixen für WP- und möglicherweise CiviCRM-Tabellennamen in wp_config.php und dann in civicrm.settings.php, und Sie sollten sofort loslegen. Viel Glück!

Answer 4

Ich hatte ein ähnliches Problem, aber nur auf einer Drupal 8-Site, die ich aktualisiert habe. Die anderen gingen gut.

Ich habe die folgende SQL ausgeführt, um die neue Tabelle zu erstellen civicrm_relationship_cache, und dann ausgeführt, cv upgrade:db --retrydamit CiviCRM dort abfängt, wo es fehlgeschlagen ist.

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