We have two small user-visible changes this release. Thanks very much to Zastai and chirlu for working on these. The git tag is
This is a small bug-fix release. Server development has slowed down while we work on writing Docker containers for our new hosting infrastructure. But code contributions are always welcome. Thanks to Ulrich Klauer (chirlu) for his work on MBS-8806 this release.
The git tag is
- [MBS-8806] – Artist credits disappearing from tracklist & recordings after editing
- [MBS-8987] – Untouched URLs are automatically/suddenly cleaned up
- [MBS-8996] – Error message when trying to merge releases displays as “ARRAY(stuff)”
- [MBS-8997] – Merging releases with “(Disc 1)”, “(Disc 2)” etc in titles selects all as disc 1
- [MBS-8999] – Track lengths are in the wrong table column in the release editor
- [MBS-8994] – Allow passing &dismax=true through to the search server so Picard can show the same results as on the website
Our release today contains the usual lot of bug fixes and improvements. Thanks to yvanz, chirlu, and reosarevok for their contributions. The git tag is
- [MBS-7358] – Edit types not translated on Release editor / edit note tab
- [MBS-7963] – Release editor doesn’t prevent too long disambiguation comments
- [MBS-8809] – ASIN cleanup can be defective
- [MBS-8951] – Recent notes is broken
- [MBS-8968] – JSON version of artist includes gender-id value, which has no xml equivalent
- [MBS-8977] – Edit searches with relationship type conditions cause an internal server error
- [MBS-8983] – « Show only results that are in my subscribed entities. » checkbox broken
- [MBS-8985] – Fix CPDL URLs matching and clean it up
- [MBS-9000] – HTML special characters are not escaped on aliases page
- [MBS-7111] – Improve URL matching for musik-sammler.de links
- [MBS-8982] – Stop “fixing” piano with Guess Case
This server release contains fixes for bugs introduced in the recent schema change, and some other small improvements listed below. Thanks to reosarevok, chirlu, yvanz, and gcilou for their contributions this time around. The git tag is
- [MBS-7986] – Misleading error message for event setlists
- [MBS-8941] – Beta: Last AC in a release sometimes doesn’t change with the rest when changing release artist
- [MBS-8942] – Beta: cursor moves to the end of AC search field when removing a letter in the middle of the name
- [MBS-8950] – iTunes favicon is not displayed on the sidebar
- [MBS-8959] – Can’t add new packaging types – ISE
- [MBS-8824] – Update the rateyourmusic logo used in the sidebar
- [MBS-8925] – Limit BookBrainz relationship to BookBrainz URLs
- [MBS-8957] – Update SecondHandSongs icon and add BBC logo in the sidebar
Starting with this release, PostgreSQL 9.5 is now our minimum supported version. In order to import any future data sets, you will need to upgrade your installation to version 9.5.
Due to unforeseen problems with the Live Data Feed (AKA replication), users with slave databases will be required to first import a fresh data dump into their new 9.5 installation. We apologize that this is the case, but even had this stream not been broken, doing a clean import is faster and easier than doing the migration. For details on what happened during this rather lengthy schema change release, stay tuned for a post mortem blog post that covers the details.
If you have a non-replicated standalone database, you can use pg_upgrade and run ./upgrade.sh directly, but for simplicity we strongly recommend importing the latest data dump. Thus, we will only provide instructions for a clean import:
- Make sure you have PostgreSQL 9.5 installed, and your database settings in lib/DBDefs.pm are updated to point to the 9.5 installation if you currently have an older version of postgres running. If you already have postgres 9.5 and want to replace the existing database there, you’ll need to drop it first (using dropdb or from within psql). Be careful that you’re not dropping any important data if this is a standalone database that you’ve made changes to.
- Take down the web server running MusicBrainz, if you’re running a web server.
- Turn off cron jobs if you are automatically updating the database via cron jobs.
- Switch to the new code with
git fetch originfollowed by
git checkout v-2016-05-23-schema-change-v2
cpanm --installdeps --notest .to ensure your perl-based dependencies are up to date. Note the dot at the end.
DB_SCHEMA_SEQUENCEto 23 in
- Download the latest data dumps. If you don’t need historical edit data, excluding the edit dump will speed up your import significantly.
- Initialize a new database from the data dumps downloaded in step 7. Detailed instructions for doing this are located in INSTALL.md in the musicbrainz-server repository; if your data dumps are in /tmp, the command should simply be something like
./admin/InitDb.pl --createdb --import /tmp/mbdump*.tar.bz2.
- After the import has finished, turn cron jobs back on, if applicable.
- Restart the MusicBrainz web server, as well as memcached, if applicable.
We would like to thank bitmap, Gentlecat, zas, chirlu, reosarevok, gcilou for contributing directly to the release and we’d also like to thank all of the people who helped test, debug or otherwise offer support in this quite difficult release. Thank you!
And finally, here’s the list of changes you can expect in the upgrade:
- [MBS-6406] – Admins can’t change email addresses
- [MBS-8288] – Missing indexes for inverse lookup on *_gid_redirect tables
- [MBS-8669] – Primary key for place table missing on old slaves
- [MBS-8906] – Release pages ISE if CB doesn’t return JSON from its API for whatever reason
- [MBS-8928] – If you submit the release editor without being logged in, it displays “[object Object]” as an error mesage
- [MBS-8943] – Some pages do not respect DB_READ_ONLY setting
- [MBS-1873] – Fix vote tallies for edits
- [MBS-3887] – Duplicate artist and label names not being checked against alias
- [MBS-8287] – Log deleted entities that were in a subscribed collection
- [MBS-8433] – Work attributes don’t have a uuid
- [MBS-8716] – Store the edit data in a JSONB column
- [MBS-8717] – Move the edit data to a separate table
- [MBS-8838] – Add gids to all *_type* tables
- [MBS-8873] – Convert and unify artist credit editors to React
- [MBS-8909] – Add logos to IMDb and VGMdb links in the sidebar
- [MBS-8939] – Update the Instagram logo used in the sidebar
- [MBS-8940] – Let banner message editors dismiss the banner only temporarily
- [MBS-8656] – Bring edit table indexes back into sync
- [MBS-8719] – Stop materializing of edit and vote counts
- [MBS-8720] – Add a materialized view of edit note recipients
- [MBS-8727] – Prevent duplicate votes
- [MBS-8800] – Create the earthdistance extension and add a geodetic index for place coordinates
- [MBS-8804] – Add BRIN indexes for timestamp columns
- [MBS-8897] – add new entity icons
- [MBS-8938] – Schema changes to support alternative tracklists
Zas and I have been working hard to improve the capacity and stability of the site. In the last week, we’ve identified and fixed at least 3 problems with the search servers and we’ve added a timeout function that times out queries that take longer than 3 seconds. We think that the main cause of trouble was that queries were piling up after a slow query ran too long and that the servers never recovered from that and consequently crashed.
We won’t go as far as saying that the search servers are fixed — every time we have a smidgen of hope that things are improving, they crash again. Seemingly out of spite! So, the search servers are better.😉
Zas has also made a number of changes to the gateways and how we rate limit our incoming traffic. The rate limiting is now being done in a smarter way that reduces the overall traffic on our web servers. Well done!
We’ve also increased our bandwidth budget by 4mbits per second, which makes the site feel considerably more responsive.
Let me put these improvement into numbers: About a week ago were were struggling to keep up 250 requests per second and the site felt very sluggish. Now we can handle 500 requests a second and the site feels considerably faster. For large chunks of the day we are managing to handle all the traffic we should handle. And, the search servers haven’t crashed in 4 days!
We hope that this will give us a solid base from which to release the scheme upgrade tomorrow. Then once that is complete, we will start work on moving to the new hosting company.
Thanks for being patient with us!
In the past few weeks we’ve been hit with several traffic increases to MusicBrainz which is putting considerably more strain on our aging infrastructure than we’re happy with. If it seems that we’re not doing anything about it, that is because we’ve been busy behind the scenes trying to keep things moving forward. This sometimes doesn’t leave us a lot of time to keep the public informed on our work. Hopefully this blog post will fix this in the short term:
In 2011 we started to make plans to move MusicBrainz hosting into the cloud, but then out of the blue we were donated a pile of machines. There were so many machines that I postponed the cloud plans and prepared the donated machines for service. That has carried us for 4+ years with almost no hardware cost, which was really great. The plan was to move to the cloud sometime around 2015, but then I spent most of 2014/2015 dealing with conflicts in the team, putting us seriously behind schedule while our hardware decayed.
On top of that, we’ve recently had some “bad luck”. We have had some disrespectful commercial customers hit us really hard and we had to find and block them. We have had unexpected traffic spikes and when trying to address these unexpected traffic spikes, we had two more machines fail on us. These were the donated machines that we kept in reserve for just this moment. The loss of two machines caught us short on capacity to handle the increased demands on our servers.
So, now we face the tough question: Do we buy expensive hardware that we might use for 6 months (~$5000) or do we try and save the money and tough it out? I’d rather not spend so much money on such short term use if we can avoid it. We’re going to try and move to a new hosting facility somewhere in the EU, since that is where most of our users are.
Moving to a new hosting facility has an incredible number of dependencies that Christina (our Biz Dev manager), Zas and I have been working through. It may not seem like we have a plan, but we do, and we’re incredibly busy trying to make the plan happen. To give you a taste of what we’re up against:
- We want to move our hosting to Europe and have a business presence in Europe in order to reduce the costs and inefficiencies of being a solely US based business. A lot of our traffic, customers and contractors are in the EU and it simply makes sense to have a presence here.
- To establish a presence in the EU I needed local help to help with the business matters as well as researching and establishing an EU organization. So I needed to find a Biz Dev manager and that person is Christina.
- Once Christina was on board she researched our options about what was suited for us. Getting that process moving involved getting certified documents from California, board approval for spending funds to establish the organization, EU labor law research, (and we needed to swap a board member, too!), hiring help to establish the org. and generally navigating the Spanish bureaucracy. (See this only slightly exaggerated short film for some clues of our ordeal.)
- Once the org. had been established we needed to convince the bank to open a bank account for us. The draconian US banking laws extend worldwide and the local bank had to ensure that they were not opening themselves up to thousands of $$$ in accounting hassles just to allow a tiny non-profit to open a bank account. We finally have a bank account and have started paying our contractors with it!
- At the same time we’re also working to set up an office for the growing team here in Barcelona. That required a byzantine process that barely started when you sign the lease. Getting power, internet and water set up has taken a frustratingly long time. Had I known how long, I would have stayed at my co-working space for a while longer while addressing hosting issues.
- While Christina has been focused on the hardcore paperwork, Zas is keeping the site running, which itself requires many heroics. Zas and I have started planning the move to the EU hosting provider. We’ve got a 5-page document that collects some of the open questions and requirements around this process: https://docs.google.com/document/d/16KNm4KksNwz29Opk1aILOMtCmPIeXFuxxUjMoPT3th0/edit#heading=h.dpfvoz1idcro. Right now Zas and Bitmap are here in Barcelona and we’re going to work on establishing a formal plan for moving to the new hosting company. We’re currently comparing hosting company offerings – see what we’ve collected so far if you care to follow along. The amount of work required to make this happen is making my head hurt. (A special shoutout to KodeStar, lead developer of FanArt.tv, for providing a lot of useful feedback about our various options.)
- While Christina, Zas and I have our hands full, Bitmap and Gentlecat continue to release new features and work on the schema change. Not to mention all the contributions from Freso and Reosarevok to keep the community happy and polite while we deal with less than optimal site conditions. That said, I am really happy and proud of my team, trying to keep things running in sub-optimal conditions.
This is just a snapshot of everything that is happening behind the scenes that will culminate with the goal of moving to a new hosting company and being set up in the EU. And mind you, we’re doing this with a minuscule budget trying to be careful of how we spent our money.