Expose a gRPC interface for moveTablet

Experience Report for Feature Request

What you wanted to do

Control Zero MoveTablet via gRPC

What you actually did

Control Zero MoveTablet via http :frowning:

Why that wasn’t great, with examples

gRPC-first interface to large swaths of system, might as well expose this as well that way.

Any external references to support your case

Sort of discussed in this feature request and this ticket etc., /moveTablet seems to be a recommended way of controlling the tablets yourself. Currently the algorithm Zero uses to shard the tablets is purely based on size. However, this can lead to a massive imbalance in workload of the servers. Currently with 2 groups this is giving me one group serving 100 tablets, and the other serving 4300 tablets, with the memory and cpu usage of the heavier group being 10x that of the lesser loaded group.

This leads me to implement my own tablet moving system, as suggested in both of the referenced issues. It would be great to expose this on the same interface as the other first-class APIs.

The current gRPC interface for the Zero server includes a call for ShouldServe(tablet) and you can send that a different group than the tablet actually has right now… but I do not think that is the same as the moveTablet endpoint. (I wrote a thing against this endpoint and I believe it just messed everything up)

1 Like