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
Even with a corruption alarm, an inconsistent etcd member can serve corrupted data to clients between the time of boot and detection. This is undesirable in cases where corruption can't be tolerated (e.g., serving disk geometry data). Worse, if the corruption is on a leader, it's possible it will further propagate the corruption by sending snapshots to other members.
Instead, if a member can contact the client addresses of its peers, it should first fetch hashes from the other members at a known revision and compare before serving any client requests. If the hashes don't match, the server will print a fatal and terminate. This will stop etcd from initializing with inconsistent data in most cases.
Even with a corruption alarm, an inconsistent etcd member can serve corrupted data to clients between the time of boot and detection. This is undesirable in cases where corruption can't be tolerated (e.g., serving disk geometry data). Worse, if the corruption is on a leader, it's possible it will further propagate the corruption by sending snapshots to other members.
Instead, if a member can contact the client addresses of its peers, it should first fetch hashes from the other members at a known revision and compare before serving any client requests. If the hashes don't match, the server will print a fatal and terminate. This will stop etcd from initializing with inconsistent data in most cases.
Related: #8214
The text was updated successfully, but these errors were encountered: