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
We've had some situations where enough servers were up, but the configuration didn't propagate properly and thus the cluster got stuck.
Our current emergency_repair options only work if servers are actually disconnected. We should strongly consider adding some sort of emergency_repair="force" mode. I'm not sure if this could actually be an option to reconfigure, and we have to think about how and whether it should actually change the configuration.
Even if it just kept the current configuration, it could be useful if it forced a new epoch for the table configuration.
The text was updated successfully, but these errors were encountered:
In discussing this offline with @danielmewes we came to the conclusion that emergency_repair="force" may do more harm than good if it could overwrite the existing configuration with a completely new one. Instead we're going to add an emergency_repair mode that recommits the existing configuration with a new epoch.
Given that this is to repair problems that shouldn't normally occur we've decided to name it emergency_repair="_debug_recommit".
We've had some situations where enough servers were up, but the configuration didn't propagate properly and thus the cluster got stuck.
Our current
emergency_repair
options only work if servers are actually disconnected. We should strongly consider adding some sort ofemergency_repair="force"
mode. I'm not sure if this could actually be an option toreconfigure
, and we have to think about how and whether it should actually change the configuration.Even if it just kept the current configuration, it could be useful if it forced a new epoch for the table configuration.
The text was updated successfully, but these errors were encountered: