[
https://issues.apache.org/jira/browse/IGNITE-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16171729#comment-16171729
]
Alexey Goncharuk edited comment on IGNITE-6285 at 9/19/17 1:55 PM:
-------------------------------------------------------------------
There are several scenarios when generating random IDs does not work
predictably, specifically, when a user starts multiple node instances on the
same physical machine.
I suggest the following (assuming we maintain the backwards compatibility)
1) A starting node binds to a port and generates old-style consistent ID
2) The node scans the work directory and checks if there is a folder matching
the consistent ID. If such a folder exists, we start up with this ID
(compatibility mode)
3) If there are no matching folders, but the directory is not empty, scan it
for old-style consistent IDs. If there are old-style db folders, print out a
warning (or fail to start)
4) If there are existing new style folders, pick up the one with the smallest
sequence number and try to lock the directory. Repeat until we succeed or until
the list of new-style consistent IDs is empty
5) If there are no more available new-style folders, generate a new one with
next sequence number and random UUID as consistent ID.
6) Use this consistent ID for the node startup
7) Add a system property to allow override the consistent ID
As Yakov suggested, we can update the lock file on every use and print out this
timestamp during the node startup.
[~dmagda] [~yzhdanov] [~dsetrakyan] please let me know what you think.
was (Author: agoncharuk):
There are several scenarios when generating random IDs does not work
predictably, specifically, when a user starts multiple node instances on the
same physical machine.
I suggest the following (assuming we maintain the backwards compatibility)
1) A starting node binds to a port and generates old-style consistent ID
2) The node scans the work directory and checks if there is a folder matching
the consistent ID. If such a folder exists, we start up with this ID
(compatibility mode)
3) If there are no matching folders, but the directory is not empty, scan it
for old-style consistent IDs. If there are old-style db folders, print out a
warning (or fail to start)
4) If there are existing new style folders, pick up the one with the smallest
sequence number and try to lock the directory. Repeat until we succeed or until
the list of new-style consistent IDs is empty
5) If there are no more available new-style folders, generate a new one with
next sequence number and random UUID as consistent ID.
6) Use this consistent ID for the node startup
As Yakov suggested, we can update the lock file on every use and print out this
timestamp during the node startup.
[~dmagda] [~yzhdanov] [~dsetrakyan] please let me know what you think.
> Enhance persistent store paths logging on start
> -----------------------------------------------
>
> Key: IGNITE-6285
> URL: https://issues.apache.org/jira/browse/IGNITE-6285
> Project: Ignite
> Issue Type: Improvement
> Reporter: Yakov Zhdanov
> Assignee: Alexey Goncharuk
> Priority: Blocker
> Labels: usability
> Fix For: 2.3
>
>
> As per this thread -
> http://apache-ignite-users.70518.x6.nabble.com/Specifying-location-of-persistent-storage-location-td16636i20.html
> Ignite may switch storage path in case of changing DHCP lease or similar
> which can lead to consistent ID change.
> In order to help user in spotting the issue Ignite may output the following
> to the logs:
> # Output the store path and tell its (1) size or state that it is empty and
> (2) last data file modification date.
> # Output warning if there are other non-empty storage folders under work
> directory with their sizes and dates.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
