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
PlannedReparentShard is supposed to be only called when all the components are running fine. If a user calls PRS with a mysql instance of a replica not working fine, then PRS does fail, but only after promoting another replica. This isn't correct and we should fail without touching the cluster at all. The user should resolve all the problems before they try a planned reparent operation again.
Also, if a Primary Tablet is deleted and then PRS is called, it ends up running the code for the initialisation of a shard, which calls InitPrimary but this isn't correct either, because InitPrimary allows a primary to accept writes without semi-sync waits even if it is configured that way.
Use Case(s)
Improvements to PRS to better report errors and prevent its misuse.
The text was updated successfully, but these errors were encountered:
Feature Description
PlannedReparentShard
is supposed to be only called when all the components are running fine. If a user calls PRS with a mysql instance of a replica not working fine, then PRS does fail, but only after promoting another replica. This isn't correct and we should fail without touching the cluster at all. The user should resolve all the problems before they try a planned reparent operation again.Also, if a Primary Tablet is deleted and then PRS is called, it ends up running the code for the initialisation of a shard, which calls
InitPrimary
but this isn't correct either, becauseInitPrimary
allows a primary to accept writes without semi-sync waits even if it is configured that way.Use Case(s)
Improvements to PRS to better report errors and prevent its misuse.
The text was updated successfully, but these errors were encountered: