pt-osc: Option to reverse triggers after table swap
General
Escalation
General
Escalation
Description
Client has requested ability for pt-osc triggers to be utilized on the _new table (after swap) pointing in the reverse direction (back to the old table).
In other words, looking for an option so that the pt-osc triggers that are placed on a table during the run to capture incoming write traffic also be created on the _new table after the swap, pointing back to the old table. This would allow client to roll back after a pt-osc change that did not work as expected and not lose any traffic, as the traffic going to the new table (after swap) is now being routed back to the old table as well.
Environment
None
AFFECTED CS IDs
CS0013923
Smart Checklist
Activity
Show:
Sveta Smirnova January 14, 2021 at 12:10 PM
Prepared statement errors happen when table handler is taken from the table cache. Workaround here is to do not use table cache that is not acceptable. I believe that another workaround: re-prepare statements is acceptable.
Jira Bot January 13, 2021 at 1:55 PM
To: CC:
Hi, I'm jira-bot, Percona's Jira automation tool. I've detected that someone from Percona has made an edit to the Summary field of an issue that you reported.
I'm not sentient (yet) so I'm not sure whether the person fixed a typo, changed a few words, or completely rewrote the text. In any case, it is Percona Engineering's intention to make the Summary and Description of an issue as accurate as possible so that we're fixing the actual problem you're encountering, and to avoid misunderstandings about symptoms and causes.
If the current Summary does not accurately reflect the problem you are reporting, or if you feel the change was otherwise inappropriate in some way, please add a new comment explaining things and we'll address it as soon as we can.
This message will be added only once per issue, regardless of how many times the Summary is edited.
Client has requested ability for pt-osc triggers to be utilized on the _new table (after swap) pointing in the reverse direction (back to the old table).
In other words, looking for an option so that the pt-osc triggers that are placed on a table during the run to capture incoming write traffic also be created on the _new table after the swap, pointing back to the old table. This would allow client to roll back after a pt-osc change that did not work as expected and not lose any traffic, as the traffic going to the new table (after swap) is now being routed back to the old table as well.