diff options
| author | Yannick Welsch <yannick@welsch.lu> | 2016-10-12 09:06:37 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2016-10-12 09:06:37 +0200 |
| commit | 075047065d5dd692d0a74f6ca70e796880f84df1 (patch) | |
| tree | 976e5df929e3d88b2103e83da7b2d0b9d03140e9 /core/src/test/java/org/elasticsearch/versioning | |
| parent | 42a7a554b1d279f102a2e0842279bd927bb8e711 (diff) | |
Keep snapshot restore state and routing table in sync (#20836)
The snapshot restore state tracks information about shards being restored from a snapshot in the cluster state. For example it records if a shard has been successfully restored or if restoring it was not possible due to a corruption of the snapshot. Recording these events is usually based on changes to the shard routing table, i.e., when a shard is started after a successful restore or failed after an unsuccessful one. As of now, there were two communication channels to transmit recovery failure / success to update the routing table and the restore state. This lead to issues where a shard was failed but the restore state was not updated due to connection issues between data and master node. In some rare situations, this lead to an issue where the restore state could not be properly cleaned up anymore by the master, making it impossible to start new restore operations. The following change updates routing table and restore state in the same cluster state update so that both always stay in sync. It also eliminates the extra communication channel for restore operations and uses standard cluster state listener mechanism to update restore listener upon successful
completion of a snapshot.
Diffstat (limited to 'core/src/test/java/org/elasticsearch/versioning')
0 files changed, 0 insertions, 0 deletions