You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Alexey Goncharuk (JIRA)" <ji...@apache.org> on 2017/09/19 13:56:00 UTC

[jira] [Comment Edited] (IGNITE-6285) Enhance persistent store paths logging on start

    [ 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)