You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by Sergey Korotkov <se...@gmail.com> on 2021/11/18 10:37:28 UTC
'Cache Interceptor mismatch' exception on node start during migration from Ignite 2.8.1 to 2.11.0
Hello,
We have a trouble migrating the persistent data from the Ignite 2.8.1 to
2.11.0. The native persistence is used and one the caches has an
CacheInterceptor configured.
If we run Ignite 2.11.0 against the persistent data created in 2.8.1
nodes do not start (only the 1st node starts but all others fail) with
the exception like:
INFO: Received activate cluster request with BaselineTopology[id=0]
initiator node ID: 43b7cd18-4366-44ef-8bfd-df4778bb4b23
INFO: Started state transition: activate cluster
INFO: Started exchange init [topVer=AffinityTopologyVersion [topVer=2,
minorTopVer=1], crd=true, evt=DISCOVERY_CUSTOM_EVT,
evtNode=43b7cd18-4366-44ef-8bfd-df4778bb4b23,
customEvt=ChangeGlobalStateMessage
[id=d6445623d71-548457da-85c2-4abd-b6ac-0a8c39dec582,
reqId=02ac8e24-c461-4361-805d-75364a997a7b,
initiatingNodeId=43b7cd18-4366-44ef-8bfd-df4778bb4b23, state=ACTIVE,
baselineTopology=BaselineTopology [id=0, branchingHash=-2080344499,
branchingType='Cluster activation', baselineNodes=[node-1, node-2]],
forceChangeBaselineTopology=false, timestamp=1637228041860,
forceDeactivation=true], allowMerge=false, exchangeFreeSwitch=false]
SEVERE: Got exception while starting (will rollback startup routine).
class org.apache.ignite.IgniteCheckedException: Cache Interceptor
mismatch [cacheName=test-cache, localInterceptor=CacheInterceptor,
remoteInterceptor=null, rmtNodeId=92330e36-3a07-4a6e-b851-9e7fb6422e17]
Fix cache configuration or set system property -DIGNI
TE_SKIP_CONFIGURATION_CONSISTENCY_CHECK=true.
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.throwIgniteCheckedException(GridCacheUtils.java:1633)
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.checkAttributeMismatch(GridCacheUtils.java:1002)
at
org.apache.ignite.internal.processors.cache.ClusterCachesInfo.checkCache(ClusterCachesInfo.java:398)
at
org.apache.ignite.internal.processors.cache.ClusterCachesInfo.onKernalStart(ClusterCachesInfo.java:341)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:687)
at
org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1414)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
at
org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:668)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:590)
at org.apache.ignite.Ignition.start(Ignition.java:328)
at ServerNode.startNode(ServerNode.java:57)
at ServerNode.main(ServerNode.java:20)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:293)
at java.lang.Thread.run(Thread.java:748)
We have prepared the small test to reproduce the problem. Test starts 2
ignite nodes with native persistence enabled and creates cache with
interceptor. To see the problem test should be run twice:
1. Create the persistent cache using ignite 2.8.1:
mvn clean package exec:java -Dignite.version=2.8.1
2. Try to start ignite 2.11.0 nodes agains created cache data. One of
the nodes (node-2) will fail to start:
mvn clean package exec:java -Dignite.version=2.11.0
***
Looks like the issue was introduced in 2.9.1. Migration to 2.9.0 works
fine but all 2.9.1, 2.10.0, 2.11.0 fail.
****
The error message suggests to use the
-DIGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK=true. It does help. But
can it be safely used in production environment? What other important
checks would be skipped?
Thanks,
--
Sergey
Re: 'Cache Interceptor mismatch' exception on node start during migration from Ignite 2.8.1 to 2.11.0
Posted by Sergey Korotkov <se...@gmail.com>.
Hello,
Are there any comments on the issue? Is it a bug? Or may be the
expected behaviour and known incompatibility?
Thanks,
- -
Sergey
18.11.2021 17:37, Sergey Korotkov пишет:
> Hello,
>
> We have a trouble migrating the persistent data from the Ignite 2.8.1 to
> 2.11.0. The native persistence is used and one the caches has an
> CacheInterceptor configured.
>
> If we run Ignite 2.11.0 against the persistent data created in 2.8.1
> nodes do not start (only the 1st node starts but all others fail) with
> the exception like:
>
> INFO: Received activate cluster request with BaselineTopology[id=0]
> initiator node ID: 43b7cd18-4366-44ef-8bfd-df4778bb4b23
> INFO: Started state transition: activate cluster
> INFO: Started exchange init [topVer=AffinityTopologyVersion [topVer=2,
> minorTopVer=1], crd=true, evt=DISCOVERY_CUSTOM_EVT,
> evtNode=43b7cd18-4366-44ef-8bfd-df4778bb4b23,
> customEvt=ChangeGlobalStateMessage
> [id=d6445623d71-548457da-85c2-4abd-b6ac-0a8c39dec582,
> reqId=02ac8e24-c461-4361-805d-75364a997a7b,
> initiatingNodeId=43b7cd18-4366-44ef-8bfd-df4778bb4b23, state=ACTIVE,
> baselineTopology=BaselineTopology [id=0, branchingHash=-2080344499,
> branchingType='Cluster activation', baselineNodes=[node-1, node-2]],
> forceChangeBaselineTopology=false, timestamp=1637228041860,
> forceDeactivation=true], allowMerge=false, exchangeFreeSwitch=false]
> SEVERE: Got exception while starting (will rollback startup routine).
> class org.apache.ignite.IgniteCheckedException: Cache Interceptor
> mismatch [cacheName=test-cache, localInterceptor=CacheInterceptor,
> remoteInterceptor=null, rmtNodeId=92330e36-3a07-4a6e-b851-9e7fb6422e17]
> Fix cache configuration or set system property -DIGNI
> TE_SKIP_CONFIGURATION_CONSISTENCY_CHECK=true.
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.throwIgniteCheckedException(GridCacheUtils.java:1633)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.checkAttributeMismatch(GridCacheUtils.java:1002)
> at
> org.apache.ignite.internal.processors.cache.ClusterCachesInfo.checkCache(ClusterCachesInfo.java:398)
> at
> org.apache.ignite.internal.processors.cache.ClusterCachesInfo.onKernalStart(ClusterCachesInfo.java:341)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:687)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1414)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
> at
> org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:668)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:590)
> at org.apache.ignite.Ignition.start(Ignition.java:328)
> at ServerNode.startNode(ServerNode.java:57)
> at ServerNode.main(ServerNode.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:293)
> at java.lang.Thread.run(Thread.java:748)
>
>
> We have prepared the small test to reproduce the problem. Test starts 2
> ignite nodes with native persistence enabled and creates cache with
> interceptor. To see the problem test should be run twice:
>
> 1. Create the persistent cache using ignite 2.8.1:
>
> mvn clean package exec:java -Dignite.version=2.8.1
>
> 2. Try to start ignite 2.11.0 nodes agains created cache data. One of
> the nodes (node-2) will fail to start:
>
> mvn clean package exec:java -Dignite.version=2.11.0
>
>
> ***
>
> Looks like the issue was introduced in 2.9.1. Migration to 2.9.0 works
> fine but all 2.9.1, 2.10.0, 2.11.0 fail.
>
> ****
>
> The error message suggests to use the
> -DIGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK=true. It does help. But
> can it be safely used in production environment? What other important
> checks would be skipped?
>
> Thanks,
>