Local Musicbrainz Server issue

[SanderPander]

I actually had the same issue and managed to resolve it for the most part.

When running this command

$ admin/check-search-indexes all

Revealed that indexes for Solr were not loading. This was backed up by checking the documents count in solr.

http://localhost:8983/solr/#/~cores/annotation

CORE           STATUS  INDEX  DB
editor         OK      0      /0
instrument     --      0      /1007
series         --      0      /13596
place          --      0      /47851
event          --      0      /52191
tag            --      0      /109442
area           --      0      /118536
label          --      0      /204813
cdstub         --      0      /288965
annotation     --      0      /431335
work           --      0      /1521752
artist         --      0      /1844598
release-group  --      0      /2300865
release        --      0      /2922841
url            --      0      /7896372
recording      --      0      /25081689

(This is the result the thread below. I don’t want to delete my indexes after spending evenings getting it working)

Then I noticed this old thread where someone had a similar issue.

MusicBrainz server troubleshooting help

Hello – I have a local musicbrainz server instance setup via the main docker container and I’m trying to query the server with Beets (file renaming and metadata mgmt tool). The idea is to be able to perform more than 1 query per second with a local instance https://beets.readthedocs.io/en/latest/reference/config.html#musicbrainz-options The trouble I’m having is that “search by index” does not return any results … this is the case for both web browser (localhost:5000) and Beet software. I can…

Here the author increased the available memory from 4GB to 16GB. This resulted in some indexes not being searchable yet. In my case, I increased the available memory to 24GB both the Database and SOLR_HEAP. This was achieved by configuring the following file:

# <project-root>/local/compose/memory-settings.yml

services:
  db:
    command: postgres -c "shared_buffers=24GB" -c "shared_preload_libraries=pg_amqp.so"
  search:
    environment:
      - SOLR_HEAP=24g

Now, I doubt that you need to allocate 24GB to the database or that you really need 24GB available on your system. I had only 8GB of ram available to docker at the time and it appeared to still work just fine. But, your milage may vary.

These changes, finally resulted in the results you can see below.

╰─admin/check-search-indexes all
CORE           STATUS  INDEX     DB
editor         OK      0         /0
instrument     OK      1048      /1048
series         --      25582     /25591
place          --      68269     /68305
event          --      90885     /90908
area           --      119472    /119488
tag            --      205747    /218960
cdstub         OK      276489    /276489
label          --      288988    /289174
annotation     --      844665    /756768
work           --      2225360   /2225920
artist         --      2488825   /2490078
release-group  --      3462993   /3463906
release        --      4443907   /4445101
url            --      13138544  /13145485
recording      --      33688919  /33697045

In this other thread they did state that you probably don’t need STATUS OK for the Index to be functional. Just as long as the Index is not 0.

@InvisibleMan78

Since I use this docker version and download the dumps (data & indexes) I have never seen that all cores report the status “OK”. There are always some (minor) differences .

BUT:
As long as you see a zero (0) at the index columns, you don’t have a single entry for this index.
In your example you have no index for series, for tags, for works, for release-groups, for releases and for urls.

I hope this helps!