Hi, I’ve reproduced this and have a fix – I guess it’ll be available with 2.8. Meanwhile I can only suggest not to create indexes without an explicit name.
Stan From: mahesh76private Sent: 16 января 2019 г. 12:39 To: [email protected] Subject: RE: Baselined node rejoining crashes other baseline nodes - DuplicateKeyError Stan, thanks for the visibility. -1- Over the last year, we move from various versions of ignite 2.4, 2.5 to 2.7. I always keep work folder in tact. -2- Over a period of development, we might have tried to create index a second or many times on the same column on which an index already existed. Now, could that cause a confusion at ignite level, especially in a multi-node scenario? Was something out of sync? Was a check missing? -3- Over a period of time, we dropped the table several times and recreated the table several times and indexes. Was something stable left out in work folder. We always used 2 or more nodes. -4- Over a period of time, we saw issues with index creation as well. My colleague posted another strange behaviour with index creation. See the issue here, http://apache-ignite-users.70518.x6.nabble.com/Failing-to-create-index-on-Ignite-table-column-td26252.html#a26258 Summary is if we don't give index names the ignite gives exceptions. Something seems to be wrong with Ignite index handling in multi-node environment. Regarding your point 2 (jira), absolutely, makes sense not to crash the node on this exception. We have about 100GB data (tables) on ignite and the only work around right now seems to be Boot node 1. Keep its work folder. Boot node 2 after removing its work folder This scenario though works, gives the cluster a down-time of about 1-2 hours and this is not acceptable for our customers. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
