Support evacuation of pilorama #947

New issue

Closed

opened 2024-01-31 14:39:41 +00:00 by fyrchik · 2 comments

fyrchik commented

2024-01-31 14:39:41 +00:00

Owner

Pilorama must be in read-only.
Shards to evacuate to should be chosen according to HRW.
If there are no shards left, evacuate to the container nodes.
3.1. It is enough to evacuate to 1 other node, this should speed up operation time greatly.
The operation should be interrupt-safe: service restart in the middle of migration should pick an old instance.
The operation should be idempotent.
5.1. Service restart in the middle of migration should pick the same shard if possible.
5.2. If service is restarted in the middle of migration, do no excessive work for subsequent invocations. This doesn't include migration over network.
It should be possible to drop any garbage one way or another.
If we write "rebalancer" to use after migration, it should reuse evacuation code (moving pilorama between shards).
(*) Implement asynchronous interface, like for evacuation command.

1. Pilorama must be in read-only. 2. Shards to evacuate to should be chosen according to HRW. 3. If there are no shards left, evacuate to the container nodes. 3.1. It is enough to evacuate to 1 other node, this should speed up operation time greatly. 4. The operation should be interrupt-safe: service restart in the middle of migration should pick an old instance. 5. The operation should be idempotent. 5.1. Service restart in the middle of migration should pick the same shard if possible. 5.2. If service is restarted in the middle of migration, do no excessive work for subsequent invocations. This doesn't include migration over network. 6. It should be possible to drop any garbage one way or another. 7. If we write "rebalancer" to use after migration, it should reuse evacuation code (moving pilorama between shards). 8. (*) Implement asynchronous interface, like for evacuation command.