Red Hat Bugzilla – Bug 1344456
replication errors after inplace upgrade from 5.5 to 5.6.0.10
Last modified: 2016-06-29 12:07:22 EDT
Description of problem:replication errors after inplace upgrade from 5.5 to 5.6.0.10 Version-Release number of selected component (if applicable):5.6.0.10 How reproducible:100% Steps to Reproduce: 1.2 appliance's in replicated setup 2.add update.repo with latest 5.6 repos to /etc/yum.repos.d/ 3.stop replication sync in ui 4.run systemctl stop evmserverd 5.run yum update following docs Actual results:replication shows as active but backlog increases and errors show in logs. Expected results: replication works correctly Additional info: [0] Documentation https://access.redhat.com/articles/2297391 evm.log http://pastebin.test.redhat.com/382304 apps ips rro 10.16.5.145 rr99 10.8.58.217
https://github.com/ManageIQ/manageiq/pull/9264
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/b1cb72ee2c059864ff2fc6b7ee5f295153c63a83 commit b1cb72ee2c059864ff2fc6b7ee5f295153c63a83 Author: Nick Carboni <ncarboni@redhat.com> AuthorDate: Thu Jun 16 16:54:24 2016 -0400 Commit: Nick Carboni <ncarboni@redhat.com> 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