Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate existing data from ~/RaiBlocks to ~/Nano #1512

merged 1 commit into from Dec 29, 2018


4 participants
Copy link

commented Dec 28, 2018

As a part of the rename from RaiBlocks to Nano (#1504), we now default to a different data path.

This adds a migration from the old/legacy path to the new path.

@rkeene rkeene added this to the V18.0 milestone Dec 28, 2018

@rkeene rkeene self-assigned this Dec 28, 2018

@rkeene rkeene requested review from argakiig and cryptocode Dec 28, 2018

@zhyatt zhyatt added this to Unscheduled in V18 Dec 28, 2018

@rkeene rkeene merged commit 66a359b into nanocurrency:master Dec 29, 2018

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
continuous-integration/travis-ci/pr The Travis CI build passed

This comment has been minimized.

Copy link

commented Dec 29, 2018

How would this affect Dockerized nodes? If the migration is occurring within the container’s namespace, wouldn’t operators need to accommodate this change with an additional host-mounted volume for persistence?


This comment has been minimized.

Copy link

commented Dec 29, 2018

The mount point is /root, so ./RaiBlocks/ will still be renamed to ./Nano and no change to existing mappings should be needed.


This comment has been minimized.

Copy link

commented Jan 3, 2019

I'm running the latest docker image and, while you were correct regarding about not needing to adjust the volume mappings, I noticed the migration of RaiBlocks to Nano did not occur as expected. My node began bootstrapping from scratch from an empty Nano directory while the contents of RaiBlocks were left hanging.

[root@xrb ~]# ls -l RaiBlocks/
total 5932508
drwx------. 2 root root         83 Oct 27 02:00 backup
-rw-------. 1 root root       2689 Dec 19 15:55 config.json
-rw-------. 1 root root       2657 Nov 29 02:21 config.json.bak
-rw-r--r--. 1 root root 6074867712 Jan  3 17:26 data.ldb
-rw-------. 1 root root       8192 Jan  3 17:26 data.ldb-lock
drwxr-xr-x. 2 root root        201 Jan  3 16:52 log
[root@xrb ~]# ls -l Nano
total 9401736
-rw-------. 1 root root       2720 Jan  3 17:26 config.json
-rw-------. 1 root root 9261748224 Jan  3 19:20 data.ldb
-rw-------. 1 root root       8192 Jan  3 19:20 data.ldb-lock
drwx------. 2 root root         43 Jan  3 17:26 log

Oddly, backing up Nano and replacing it with the old contents of RaiBlocks resulted in some kind of issue with the node (even after blowing away config.json and letting it pull a fresh config). Calls to the RPC port were failing.

[root@xrb ~]# docker stop enn_nanonode_1
[root@xrb ~]# mv Nano Nano.bak
[root@xrb ~]# cp -r RaiBlocks/ Nano
[root@xrb ~]# docker start enn_nanonode_1
[root@xrb Nano]#  curl -g -d '{ "action": "block_count" }' '[::1]:7076'
curl: (56) Recv failure: Connection reset by peer

Edit: just to clarify, stopping the node and switching the directory back allows the node to at least function properly. Apart from the config, I'm not sure what could be causing the issue with the RPC calls.

@zhyatt zhyatt moved this from Unscheduled to CP 0 in V18 Jan 4, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.