Tag: instructions

Schema change upgrade instructions, schema 21

This upgrade shouldn’t be substantially different than past upgrades, now that we’ve fixed a few bugs with the process. To upgrade:

  1. Make sure your REPLICATION_TYPE setting is RT_SLAVE and your DB_SCHEMA_SEQUENCE is set to 20 in lib/DBDefs.pm.
  2. Ensure you’ve replicated up to the most recent replication packet available with the old schema. (if you’re not sure, run ./admin/replication/LoadReplicationChanges and see what it tells you).
  3. Take down the web server running MusicBrainz, if you’re running a web server.
  4. Turn off cron jobs if you are automatically updating the database via cron jobs.
  5. Switch to the new code with git fetch origin followed by git checkout schema-change-20-to-21
  6. Run ./upgrade.sh (or carton exec -Ilib -- ./upgrade.sh if you’re using carton, with very old setups).
  7. Set DB_SCHEMA_SEQUENCE to 21 in lib/DBDefs.pm
  8. Turn cron jobs back on, if needed.
  9. Restart the MusicBrainz web server, if applicable. It’s also recommended you restart memcached.

That’s it! The only real difference from the past is the specific tag to be used: schema-change-20-to-21, which is a couple of fix-up commits past the regular release tag.

Search server jar/war files

We’ve been asked to provide instructions for how to upgrade a search server installation. We’ve got two answers for you:

  1. Short answer: Use the jar/war files linked below. Deploy these into whatever setup you’re currently using.
  2. Long answer: Check out the source (svn rev 13728) of the search server and follow the install instructions to build your own jar/war files.

Links: indexer jar, servlet war

2013-10-14 schema change release update instructions

As promised, here are the instructions for updating any instances of MusicBrainz you might have. You will need to perform these steps to upgrade to the new version:

  1. Take down the web server running MusicBrainz, if you’re running a web server.
  2. Turn off cron jobs if you are automatically updating the database via cron jobs.
  3. Make sure your REPLICATION_TYPE setting is RT_SLAVE
  4. Switch to the new code with git fetch origin followed by git checkout v-2013-10-14
  5. Run carton exec -Ilib — ./upgrade.sh (or simply ./upgrade.sh if you aren’t using carton, such as for VM users or fairly new installs).
  6. Set DB_SCHEMA_SEQUENCE to 19 in lib/DBDefs.pm
  7. Turn cron jobs back on, if needed.
  8. Restart the MusicBrainz web server, if needed.

If your server fails to start or cron is having issues, it may be a missing perl module problem. To check for any missing perl modules, follow the instructions in INSTALL.md.

New virtual machine available via BitTorrent

We have finally created a new version of our Virtual Machine and we’re currently seeding it via BitTorrent. If you have some spare bandwidth and would like to help seed this torrent, please join it and leave your client running.

You can find the torrent file here. (edit: for the curious/disk-limited, the downloaded .ova is 10.13GB). Please read the instructions for how to use this VM.

You should consider this VM as beta quality as it not been tested at all. Let’s hope for the best!

UPDATE: We’ve got a workaround for getting this VM to work in VirtualBox. It works just fine under VMWare Fusion and Player.

UPDATE 2: We’ve added a second tracker to the BitTorrent.

Schema 17/18 upgrade instructions

We’ve just completed our extra schema upgrade. The full instructions for upgrade follow:

Schema 16 to schema 17 upgrade

If you already ran the migration that was announced May 15th, or if you imported a data dump from May 15th or later, skip to the next section.

  1. Run replication with carton exec -Ilib -- ./admin/replication/LoadReplicationChanges until it cannot apply any packets in schema 16.
  2. Take down the web server running MusicBrainz, if you’re running a web server.
  3. Turn off cron jobs if you are automatically updating the database via cron jobs.
  4. Make sure your REPLICATION_TYPE setting is RT_SLAVE in lib/DBDefs.pm
  5. Switch to the new code with git fetch origin followed by git checkout schema-16-to-17
  6. Run carton install --deployment to install any new perl modules.
  7. Run carton exec -Ilib -- ./upgrade.sh from the top of the source directory.
  8. Set DB_SCHEMA_SEQUENCE to 17 in lib/DBDefs.pm
  9. Turn cron jobs back on, if needed.
  10. Restart the MusicBrainz web server, if needed.

Schema 17 to schema 18 upgrade

  1. Run replication with carton exec -Ilib -- ./admin/replication/LoadReplicationChanges until it cannot apply any packets in schema 17.
  2. Take down the web server running MusicBrainz, if you’re running a web server.
  3. Turn off cron jobs if you are automatically updating the database via cron jobs.
  4. Make sure your REPLICATION_TYPE setting is RT_SLAVE in lib/DBDefs.pm
  5. Switch to the new code with git fetch origin followed by git checkout v-2013-05-24
  6. Run carton exec -Ilib -- ./upgrade.sh from the top of the source directory.
  7. Set DB_SCHEMA_SEQUENCE to 18 in lib/DBDefs.pm
  8. Turn cron jobs back on, if needed.
  9. Restart the MusicBrainz web server, if needed. EDIT: also restart memcached here, see http://tickets.musicbrainz.org/browse/MBS-6376

Note that the tags to check out for the two migrations are different.

Changes

For the list of changes in schema 17, see the former blog post. The changes for schema 18 are:

  1. Fix the track table corruption that the schema 16-17 upgrade created, by importing a copy of the ‘track’ table from the production database.
  2. Fix some indexes and constraints that should not be on slaves or which had bad names starting with ‘medium2013’ or ‘track2013’
  3. Create a missing index on medium.release that dramatically improves performance.
  4. Fix the ref_count column of the artist_credit table, which was not updated properly at the schema 16-17 upgrade.

Issues with 2013-05-15 schema change and the 'track' table.

As a heads-up for anyone using postgresql 9.1 or later (9.0 is the only confirmed-correct version) anyone running a slave server, it appears that there’s an issue with the upgrade script which will result in an incorrect track table in most cases.

An ostensible fix that was previously mentioned here does not work. We’re still working on a fix and will update this post as we have more details.

There is a fix, see http://blog.musicbrainz.org/?p=1962 for instructions. Thanks for your patience!

Updating MusicBrainz slave instances for 2012-10-15

If you have a replicated instance of MusicBrainz, please follow these instructions to get your server running on the new schema:

  1. Take down the web server running MusicBrainz, if you’re running a web server.
  2. Turn off cron jobs if you are automatically updating the database via cron jobs.
  3. Make sure your REPLICATION_TYPE setting is RT_SLAVE
  4. Switch to the new code with git fetch origin followed by git checkout v-2012-10-15-schema-change
  5. Run carton install --deployment to install any new perl modules.
  6. Run carton exec -- ./upgrade.sh from the top of the source directory.
  7. Set DB_SCHEMA_SEQUENCE to 16 in lib/DBDefs.pm
  8. Turn cron jobs back on, if needed.
  9. Restart the MusicBrainz web server, if needed.

This upgrade requires quite a bit of disk-space to execute; your slave may run into trouble if there is less than 10Gb of disk space free. If you’re on a disk space constrained machine, you may want to consider re-importing the data rather than upgrading in place. The next data dump should be available in about 14-16 hours from now.

Post schema change fix for importing clean data

Yesterday we found a bug that prevents the import of a post schema change update data set. We’ve pushed out a fix for this and tagged it with: 

v-2012-05-15-import-fix

If you’re planning on importing a new data set, make sure to check out this tag, rather than the tag mentioned in this entry.

2012-01-12 Schema change upgrade instructions for replicated setups

We just finished the latest schema change release! If you are running a full musicbrainz-server mirror, then follow these instructions for upgrading your installation:

  1. Take down the web server running MusicBrainz, if you’re running a web server.
  2. Turn off cron jobs if you are automatically updating the database via cron jobs.
  3. Make sure your REPLICATION_TYPE setting is RT_SLAVE
  4. Switch to the new code with git fetch origin followed by git checkout v-2012-01-12-schema-change-2
  5. Install any necessary perl modules by running perl ./Makefile.PL and sudo make installdeps
  6. Run ./upgrade.sh from the top of the source directory.
  7. Set DB_SCHEMA_SEQUENCE to 14 in lib/DBDefs.pm
  8. Turn cron jobs back on, if needed.
  9. Restart the MusicBrainz web server, if needed.

If you are running a mbslave mirror, check out the latest code and read the upgrade instructions in the README file.

Schema change, 2012-01-12

We’ve just finished pushing out the scheduled schema change update today. A slightly rocky experience, but we’ve managed to get everything ironed out now and our servers are back to their normal selves. Before, I get into release notes, a few notes for people who’d like to upgrade their non-replicated servers. For replicated servers, please see this post.

  1. First, update your repository to the v-2012-01-12-schema-change tag.
  2. Next, disable any MusicBrainz cron jobs you might have scheduled to run
  3. Run ./upgrade.sh provided in the root directory of your musicbrainz-server checkout.
  4. Update your DBDefs DB_SCHEMA_SEQUENCE configuration option to 14.
  5. Turn any cron jobs back on

And onto the release notes!

Bug

  • [MBS-2121] – Deleting track/row in advanced tracklist editor while artist credits "dialog" is open leaves it stuck
  • [MBS-2390] – It’s not really possible to assign a track to a recording because cannot see length of track in either tracklist or proposal list
  • [MBS-2620] – Most ‘edit’ edits do not check for conflicts
  • [MBS-3393] – App keeps DB connections open and doesn’t reconnect upon DB restart.
  • [MBS-3696] – Using Jamendo as License Relationship fails due to Javascript change to Cover Art relationship
  • [MBS-3972] – ISWC column on works page should be nowrap
  • [MBS-4046] – Releases with pending edits are not marked as such in label page
  • [MBS-4099] – The server should give a good error message when it can’t connect to the DB
  • [MBS-4103] – Problems building database extensions with Ubuntu 11.10
  • [MBS-4129] – "Edit artist" doesn’t change artist credit for credits that were unchecked by default but checked manually
  • [MBS-4132] – Rate limited pages send HTML as text/plain
  • [MBS-4134] – Javascript sorting broken on Country statistics page since comma has been introduced
  • [MBS-4136] – beta.mb: recording edits generated by release editor when updating recording information from track changes are not auto-edits
  • [MBS-4138] – Language-Script page in statistics broke
  • [MBS-4146] – Track times deleted if using tab key
  • [MBS-4149] – The added referrer stuff breaks Amazon UK links
  • [MBS-4157] – beta.mb: Edit recording edits seem to create a ‘edit release’ edit too
  • [MBS-4169] – CDToc page shows blank/empty catalog numbers separated by commas

Improvement

  • [MBS-1482] – Report: no language, no script
  • [MBS-2439] – Releases with multiple catalog numbers are shown multiple times on the Label page.
  • [MBS-2513] – Allow updating recording information when track information changes via the release editor
  • [MBS-3288] – Release group type isn’t shown when looking up a release group
  • [MBS-4105] – Warn when merging releases with track artists that don’t match

New Feature

  • [MBS-4147] – Display AcoustIDs using JavaScript

Task

  • [MBS-3672] – Remove the deprecated Live Sound Engineer relationship

Sub-task

  • [MBS-2676] – Filter by relationship type