Updated VM available for replication/reindexation test

virtualmachine
virtualbox
musicbrainz-vm
Tags: #<Tag:0x00007f3511a89e20> #<Tag:0x00007f3511a89ce0> #<Tag:0x00007f3511a89ba0>

#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.


#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.


#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.


#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


#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:

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:

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:


#33

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


#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