Bug 1344456
| Summary: | replication errors after inplace upgrade from 5.5 to 5.6.0.10 | ||
|---|---|---|---|
| Product: | Red Hat CloudForms Management Engine | Reporter: | luke couzens <lcouzens> |
| Component: | Appliance | Assignee: | Nick Carboni <ncarboni> |
| Status: | CLOSED ERRATA | QA Contact: | luke couzens <lcouzens> |
| Severity: | urgent | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 5.6.0 | CC: | abellott, cpelland, jhardy, ncarboni, obarenbo, simaishi |
| Target Milestone: | GA | ||
| Target Release: | 5.6.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | upgrade:black | ||
| Fixed In Version: | 5.6.0.12 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-06-29 16:07:22 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
luke couzens
2016-06-09 18:06:46 UTC
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/b1cb72ee2c059864ff2fc6b7ee5f295153c63a83 commit b1cb72ee2c059864ff2fc6b7ee5f295153c63a83 Author: Nick Carboni <ncarboni> AuthorDate: Thu Jun 16 16:54:24 2016 -0400 Commit: Nick Carboni <ncarboni> CommitDate: Mon Jun 20 11:08:36 2016 -0400 Fix replication installation after primary key addition In 7656212 a migration added "id" primary keys to some tables that were being replicated. The triggers used in rubyrep replication hardcode the "key" used to retrieve the row that has been changed. In tables without a proper PK these triggers were using multiple columns for this key. Before this change, a migrated environment would have the same (old) triggers firing on tables that now had a primary key which would write the old key into the pending changes table. This mismatch between what was recorded in the pending changes table and the actual primary key caused an infinate loop / timeout during rubyrep replication. This fixes the situation by removing the triggers and other replication state information for these tables and allowing them to be rebuilt when replication starts again. The new triggers will have the new primary key in them and will generate changes that can be properly processed. https://bugzilla.redhat.com/show_bug.cgi?id=1344456 ..._rep_triggers_on_tables_with_new_primary_key.rb | 34 ++++++++++++++++++++++ ...triggers_on_tables_with_new_primary_key_spec.rb | 27 +++++++++++++++++ 2 files changed, 61 insertions(+) create mode 100644 db/migrate/20160425161345_reset_ruby_rep_triggers_on_tables_with_new_primary_key.rb create mode 100644 spec/migrations/20160425161345_reset_ruby_rep_triggers_on_tables_with_new_primary_key_spec.rb Verified in 5.6.0.12 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2016:1348 |