[
https://issues.apache.org/jira/browse/FLINK-26490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502109#comment-17502109
]
刘方奇 commented on FLINK-26490:
-----------------------------
[~mayuehappy] [~yunta] THX for your reply.
In my opinion, removing the max parallelism check is so difficult, cause there
are so many checks in the CheckpointCoordinator / TaskExecutor / Backend
restore and so on. It will bring a huge code refactor and code maintaining
problem.
I think we can adjust the max parallelism of OperatorState which don't contains
keyed state after restore savepoint, then deploy.(rebuild a CompletedCheckpoint)
PS : We can reuse the max parallelism compute logic to re-compute max
parallelism with new parallelism.
> Adjust the MaxParallelism or remove the MaxParallelism check when unnecessary.
> ------------------------------------------------------------------------------
>
> Key: FLINK-26490
> URL: https://issues.apache.org/jira/browse/FLINK-26490
> Project: Flink
> Issue Type: Improvement
> Components: Runtime / State Backends
> Reporter: 刘方奇
> Priority: Major
>
> Since Flink introduce key group and MaxParallelism, Flink can rescale with
> less cost.
> But when we want to update the job parallelism bigger than the
> MaxParallelism, it 's impossible cause there are so many MaxParallelism check
> that require new parallelism should not bigger than MaxParallelism.
> Actually, when an operator which don't contain keyed state, there should be
> no problem when update the parallelism bigger than the MaxParallelism,, cause
> only keyed state need MaxParallelism and key group.
> So should we remove this check or auto adjust the MaxParallelism when we
> restore an operator state that don't contain keyed state?
> It can make job restore from checkpoint easier.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
