Updated VM available for replication/reindexation test

Tags: #<Tag:0x00007fcb50500b18> #<Tag:0x00007fcb505005f0> #<Tag:0x00007fcb50500230>


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



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


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.


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.


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


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.


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.


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


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



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.


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.


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


Not so pretty java.io.FileNotFoundException:


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


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 posts were split to a new topic: Issue with 2018-08-14 VM