Updated VM available for replication/reindexation test

MusicBrainz Development
, ,
21

Thank you again for your fixes @yvanzo, especially for the documentation enhancement!
This version looks really good now :+1::tada:

Just to be sure:
If I start this VM from time to time and want to manually replicate the changed data when I need it (=no automatic cronjob), I can also execute bin/update-indexes now after a manual bin/replicate now ?

Should this index update run much faster than the initial (first-time-only) bin/reindex ?

Do you recommend to stop the VM with

docker-compose stop && sudo shutdown -h now
or
docker-compose down && sudo shutdown -h now
or only
sudo shutdown -h now






Just for the record:
The first replication (28.07.2018 until 07.08.2018) took 46 minutes.

22

Yes.

Yes. (It is still necessary to build initial index data at least once after setting replication access token.)

Note: This is the last MBVM to include the old search indexer. Next MBVMs will board the new SOLR-based search server along with prebuilt initial index data (to be tracked as MBVM-38).

Yes (to the latter).

Edit:

It is okay to manually stop containers, but I guess you will have to manually start it on next boot.

This will remove containers and any change you made, including access token and server name.

2 Likes
23

@yvanzo
The scripts work well, my access token and the GUI are preserved as expected.

Unfortunately, I can’t confirm this speed gain.
It took the same time for bin/update-indexes now as for bin/reindex. In my environment about 5 hours.

24

Even for further runs of bin/update-indexes now?

25

After two more attempts (replication/index update) I have to say:
No speed gain!

It seems as bin/update-indexes now does exactly the same task as bin/reindex.

1 Like
26

Thanks for testing at full scale. :cry: I will revert hourly indexation and publish final VM on tomorrow.

Yet another reason to switch to SOLR-based search server and its indexer for further VM images.

2 Likes
27

With replicated data until tonight? :innocent::wink::+1:

28

Well, there was no dump last night, it contains latest dump which is 2018-08-11.

ftp://ftp.eu.metabrainz.org/pub/musicbrainz-vm/musicbrainz-server-2018-08-14.ova.torrent

1 Like
29

Thank you for the newest VM @yvanzo

I got his error message
“Possible EventEmitter memory leak detected. 12 resolve listeners added. Use emitter.setMaxListeners() to increase limit”
after setting the IP-Address for the newest OVA:

leak
leak777×377 8.84 KB

I have no idea what this means and if I have to do something (what?) now.

30

There is another warning message
cannot access ‘/mnt/docker-volumes/volumes/musicbrainzdocker_indexddata/_data/’: Permission denied
after the command bin/reindex:

Access%20denied
Access%20denied848×206 4.01 KB

The reindex-process seems to run. We will see in about 5 hours if it works.

31

Sorry about this spurious message, you can safely ignore this one. I will take a look at the other.

32

Not so pretty java.io.FileNotFoundException:

FileNotFoundException
FileNotFoundException852×626 7.87 KB

33

A VM reboot and executing
sudo bin/reindex
solved the above java.io.FileNotFoundException and the “Permission denied” errors.

2 Likes
34

This is a bug in the script bin/reindex that can be fixed by running the following command:

sudo sed -i '/sudo/!s/ls\|rm/sudo &/' bin/reindex

Edit: by the way, running sudo bin/reindex is a correct workaround

Edit: troubleshooting notes have been added to doc/MusicBrainz Server/Setup.

2 Likes
35

2 posts were split to a new topic: Issue with 2018-08-14 VM