You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In this use case, MySQL is externally managed, like RDS, which does not support fast failovers. In this case, one can use a second vttablet of type REPLICA pointed at the master. During software rollout, one can use a "failover" mechanism to update the vttablets without incurring downtime.
In the above situation, if there is a network partition, two vttablets can end up thinking that they are masters. If so, they can race on generating sequences and step over each other.
This bug can also be trigerred by someone directly updating next_id. It's also possible that someone could update next_id to a lower value that can mess things up even further.
The current implementation assumes that next_id cannot change underneath. So, vttablet continues to iterate from current NextVal. Instead, all we have to do is validate the current LastVal against next_id, and correct the system accordingly.
The text was updated successfully, but these errors were encountered:
Fixesvitessio#5590
Previously the nextval code assumed that next_id will be changed
externally. As explained in the bug, this can now happen with the
new use cases.
This change ensures that vttablet will work correctly even if
next_id was changed.
Signed-off-by: Sugu Sougoumarane <[email protected]>
In this use case, MySQL is externally managed, like RDS, which does not support fast failovers. In this case, one can use a second vttablet of type REPLICA pointed at the master. During software rollout, one can use a "failover" mechanism to update the vttablets without incurring downtime.
In the above situation, if there is a network partition, two vttablets can end up thinking that they are masters. If so, they can race on generating sequences and step over each other.
This bug can also be trigerred by someone directly updating next_id. It's also possible that someone could update next_id to a lower value that can mess things up even further.
The current implementation assumes that next_id cannot change underneath. So, vttablet continues to iterate from current NextVal. Instead, all we have to do is validate the current LastVal against next_id, and correct the system accordingly.
The text was updated successfully, but these errors were encountered: