Fix replication installation after primary key addition #9264
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@Fryguy please review |
|
@miq-bot add_label core, replication, bug |
carbonin
force-pushed
the
fix_rubyrep_for_join_table_pks
branch
from
de169e4
to
bcc9410
Compare
|
👍 Looks awesome! |
|
I'll review shortly. @chessbyte @gtanzillo Please don't merge / backport until I can verify that we have the darga_migrations.txt stuff all squared away. |
Commit 392423a created a spec which would fail if a migration in the current source tree was at an earlier timestamp than one that has already been released, leaving us open to an issue where we could run migrations out of order potentially causing schema inconsistencies across regions. The previous method relied on a file to determine which migrations had been released. When that file was not updated when new migrations were backported we left ourselves open to a false positive. This change pulls the migrations from the github api right before running the spec, ensuring that we have the latest data on backported migrations.
Fryguy
changed the title
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
carbonin
force-pushed
the
fix_rubyrep_for_join_table_pks
branch
from
bcc9410
to
b1cb72e
Compare
Fryguy
changed the title
|
#9278 is merged, so when this goes green I think we are good. |
|
Checked commit carbonin@b1cb72e with ruby 2.2.4, rubocop 0.37.2, and haml-lint 0.16.1 |
chessbyte
pushed a commit
that referenced
this pull request
Jun 20, 2016
Fix replication installation after primary key addition (cherry picked from commit e106575)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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