You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Andor Molnar (JIRA)" <ji...@apache.org> on 2018/01/03 10:40:00 UTC

[jira] [Comment Edited] (ZOOKEEPER-2960) The dataDir and dataLogDir are used opposingly

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16309451#comment-16309451 ] 

Andor Molnar edited comment on ZOOKEEPER-2960 at 1/3/18 10:39 AM:
------------------------------------------------------------------

Hi [~danmilon]

Looks like you're right. QuorumPeerMain mixes the 2 directories and if the server is running in an ensemble, logs are going to be created in dataDir and snapshots are in dataLogDir. What's even more confusing is that it works right in standalone mode. 

QuorumPeerMain@139 (non-standalone mode):
{code:java}
runFromConfig():
...
          quorumPeer.setTxnFactory(new FileTxnSnapLog(
                  new File(config.getDataDir()),
                  new File(config.getDataLogDir())));
{code}

ZookeeperServerMain@112 (standalone mode):
runFromConfig():
...
            txnLog = new FileTxnSnapLog(new File(config.dataLogDir), new File(
                    config.dataDir));

The latter is the right way of doing it: FileTxnSnapLog expects dataLogDir (txn logs) in the 1st and dataDir (snapshots) in the 2nd argument.


was (Author: andorm):
Hi [~danmilon]

Looks like you're right. QuorumPeerMain mixes the 2 directories and if the server is running in an ensemble, logs are going to be created in dataDir and snapshots are in dataLogDir. What's even more confusing is that it works right in standalone mode. 

QuorumPeerMain@139 (non-standalone mode):
runFromConfig():
...
          quorumPeer.setTxnFactory(new FileTxnSnapLog(
                  new File(config.getDataDir()),
                  new File(config.getDataLogDir())));

ZookeeperServerMain@112 (standalone mode):
runFromConfig():
...
            txnLog = new FileTxnSnapLog(new File(config.dataLogDir), new File(
                    config.dataDir));

The latter is the right way of doing it: FileTxnSnapLog expects dataLogDir (txn logs) in the 1st and dataDir (snapshots) in the 2nd argument.

> The dataDir and dataLogDir are used opposingly
> ----------------------------------------------
>
>                 Key: ZOOKEEPER-2960
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2960
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: server
>    Affects Versions: 3.4.11
>         Environment: Not relevant.
>            Reporter: Dan Milon
>            Assignee: Andor Molnar
>            Priority: Critical
>
> After upgrading from zookeeper 3.4.5, to 3.4.11, without editing {{zoo.cfg}}, the new version of the server tries to use the {{dataDir}} as the {{dataLogDir}}, and the {{dataLogDir}} as the {{dataDir}}. Or at least some parts of the server.
> Configuration file has:
> {noformat}
> $ grep -i data /etc/zookeeper/zoo.cfg 
> dataLogDir=/var/lib/zookeeper/datalog
> dataDir=/var/lib/zookeeper/data
> {noformat}
> But runtime configuration has:
> {noformat}
> $ echo conf | nc localhost 2181 | grep -i data
> dataDir=/var/lib/zookeeper/datalog/version-2
> dataLogDir=/var/lib/zookeeper/data/version-2
> {noformat}
> Also, I got this in the debug logs, so clearly some parts of the server confuse things.
> {noformat}
> [PurgeTask:FileTxnSnapLog@79] - Opening datadir:/var/lib/zookeeper/datalog snapDir:/var/lib/zookeeper/data
> [main:FileTxnSnapLog@79] - Opening datadir:/var/lib/zookeeper/data snapDir:/var/lib/zookeeper/datalog
> {noformat}
> I tried to look in the code for wrong uses of the directories. I only found [ZookeeperServer.java|https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/zookeeper/server/ZooKeeperServer.java#L227] is passing the arguments to {{FileTxnSnapLog}} in the wrong order, but the code comment says that this is legacy only for tests, so I assume it isn't the cause for my case.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)