Yue Ma created FLINK-37551:
------------------------------
Summary: Improve the state compatibility of ForStKeyeStateBackend
and ForStSyncKeyeStateBackend
Key: FLINK-37551
URL: https://issues.apache.org/jira/browse/FLINK-37551
Project: Flink
Issue Type: Bug
Components: Runtime / State Backends
Affects Versions: 2.0.0
Reporter: Yue Ma
Fix For: 2.0.1
Currently, when switching between ForStKeyeStateBackend and
ForStSyncKeyeStateBackend, the states may not be compatible. This may cause a
lot of upgrade costs for users. The main purpose of this ticket is to improve
the compatibility of ForStKeyeStateBackend and ForStSyncKeyeStateBackend.
In order to support the sync/async mode compatibility between
ForStKeyedStateBackend, there may be many details involved. For the convenience
of future tracking, the required changes will be summarized here. (The current
list may still be incomplete, but it will be continuously updated until full
compatibility)
* {*}Made StateMetaInfo consistent for ForStKeyeStateBackend and
ForStSyncKeyeStateBackend{*}. Currently, if MapState or ListState is used, the
StateMeta information saved by ForStKeyeStateBackend and
ForStSyncKeyeStateBackend when making cp may be inconsistent, which may cause
incompatible states. For example, when using MapState, ForStKeyeStateBackend
will save the ValueSerializer information in StateMeta, but
ForStSyncKeyeStateBackend will save the MapSerializer information. So we need
to unify this place.
* {*}Let ForStKeyedStateBackend consider namespaceSerializer compatibility
when restoring state{*}. ForStKeyedStateBackend currently does not consider
namespaceSerializer compatibility when restoring state. This may cause the
namespaceSerializer to change when it is not known whether it should be
compatible.
* {*}Make StateMeta in ForState restore from oldStateInfo from
Checkpoint{*}.(https://issues.apache.org/jira/browse/FLINK-37524) Currently,
when creating using ForStKeyedStateBackend create a new State ,
AbstractKeyedState will directly use the serializer in StateDescriptor
regardless of whether it is restored from a Checkpoint.However, this may cause
data to be unable to be restored when the last serializer changes (for example,
the class registration order in KryoSerializer has changed, for specific cases,
please refer
toStateBackendTestBase#testKryoRestoreResilienceWithDifferentRegistrationOrder).
Therefore, when creating a State from a Checkpoint, oldStateInfo should be
used as the new State's Serializer.
* *Add unit tests for state compatibility between ForStKeyeStateBackend and
ForStSyncKeyeStateBackend*
* *Make serialization consistent between ForStMapState and ForStSyncMapState*
(https://issues.apache.org/jira/browse/FLINK-37419)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)