From what I have read in the docs, during a predicate rebalance this will cause the predicate to go in to read only mode, and you should queue up the the work until it back in write only mode.
This is fine for a mostly offline system but how can this be good for a live system? Maybe I have read something wrong, but this does seem very good for feedback type system like DAG processing, which dgraph would help simplify.
That was how Google’s Bigtable used to work. During tablet migration, it would pause writes to that tablet. Note that migrations are not that common. You could also manually trigger these moves during periods of “maintenance”, etc.
We could definitely improve it over time. Allow writes while a move is going on, but it is not a priority for now.
Welcome Owen. Look forward to hearing more from you on the forums!
i am also having the similar doubt about the data migration in sharding.
You added that
"You could also manually trigger these moves during periods of “maintenance”,
Can you please refer me how to do this.
And also can we add our manual way to control the predicate to group combination.
This will help the client to control based on their data.
Look for moveTablet here: https://dgraph.io/docs/deploy/#more-about-dgraph-zero
You can set the rebalance interval flag in Zero to something arbitrarily high, so Zero wouldn’t do tablet moves automatically.