Category: Server

Tomorrow at 2000UTC (1300 PDT, 1500 EDT, 2100BST, 2200MET) we’re going to finally rotate the new Sun server into active service. We’re expecting MusicBrainz to be unavailable for about 90 minutes while we dump the database from our old server and import it to the new server.

Sorry for the inconvenience this will cause.

We’ve got the new database server finally ready to roll, except for one thing: We don’t know how to monitor the hardware RAID array.

Under Linux we would use mpt-status, but this doesn’t work for Solaris. Does anyone know how to get Solaris to tell us about the state of the hardware RAID array? If one of the drives in the array goes away, we want to know about it as soon as possible.

Any tips would be greatly appreciated!

UPDATE: Our very own inhouseuk had the answer: raidctl — a utility that was installed all along!

Its been a rocky week in the MusicBrainz universe, that’s for sure!

About three weeks ago the load on our database server started rising — most likely due to the fact that after the April 1 release people went nutz adding labels to the database and vastly more AR links than before. The onslaught of this extra data pushed our database over an invisible threshold and things started getting shaky.

In order for a database to be running smoothly and efficiently it should mostly fit into RAM and not require the database server to fetch much data from disk continually. Once the threshold is hit where data needs to be continually fetched from disk, everything slows down drastically.

That’s basically what happened three weeks ago — the database outgrew the server we have for it. At first we thought that some feature from the April 1 release was bogging down the server, so we did some triaging with no luck. Finally we decided to throw out nearly 1 GB of useless Add TRM edit data, which shrunk the database size back down to a manageable level.

This, of course, is nothing more than a band aid. In a few weeks this problem will be back. Anticipating this moment for over a year now, I’ve been pushing for a large server donation. The Sun server donation was supposed to perfectly take care of that. But we were having serious issues with getting the database to run well on the Sun box. But, with help of some Sun engineers we’ve gotten past this problem and are now in the final stages of preparing the Sun server for production use.

But, in this middle of all this more disaster struck. Lingling, which was taking over for Stimpy as our primary web server, had a power supply fail early in the morning this past Sunday. Stimpy, with redundant power supplies, was sitting idle waiting to be put back into service after he got a new motherboard from Dell. With all the other problems we didn’t have the time to switch Stimpy back in for Lingling — we had scheduled that to happen about 12 hours after Lingling failed.

Lingling has a new powersupply arriving tomorrow. Moose, the Sun server, may go into service this weekend or early next week. Once we get these two tasks done, the site performance should be back to being zippy.

Until then, I apologize for the inconvenience!

All the usual tricks to massage our database server aren’t helping. 🙁

The problem appears to be the ever growing table of TRMs that the Classic Tagger uses. The table has gotten too big with dead TRMs and its really hard to remove all the dead TRMs. So, in order to get things back to a sane state, we’ve disabled TRM functionality and our database is now working fairly well again.

Classic Tagger users: While we figure out how to proceed, the tagger will stop working. The classic tagger will not recognize any tracks right now — we apologize for the inconvenience. At this point, please check out the Picard and PicardQT as alternatives!

Stay tuned for more details!

We need to dump the database and re-import it in order to get off this crazy load spike the database has been on. We will be down for about 90 minutes starting today (Friday) at 2000 UTC, 4pm EDT, 1pm PDT.

Sorry for the inconvenience and late notice!

UPDATE: The import/export is taking longer than we care for. We hope to be done soon. Sorry for the hassle.

The load on our database server has been growing over the last few days causing slow downs. Since our overall traffic is not going up right now, this suggests that our last update caused some performance issues.

In order to analyze our traffic, I will be doing some performance tuning and query logging to attempt to get to the bottom of this problem. To that affect, MusicBrainz will have a couple of short downtimes today as I tinker with our database server.

Sorry for the inconvenience.

This weekend we’ve seen a rise in tagger traffic to the MusicBrainz site. This extra traffic is causing load spikes that give us the dreaded 502 proxy error messages. Now that the release is done I can focus more time on getting our various hardware issues solved and bring a new database server online before the load spikes return next weekend.

What can you do? There are three concrete things:

1. Make a donation to help us cover our costs.
2. Stop tagging for today and spend some time with your friends and family for Easter. 🙂
3. If you must continue tagging, please use our UK mirror: http://www.uk.musicbrainz.org In the options dialog of your favorite tagging application, look for the tab that lets you set the server you’re using to tag. Enter www.uk.musicbrainz.org in that field and you should be good to go.

Sorry for the inconvenience, we’ll work on this as soon as possible!

After much work by Lukáš, Dave, Age (Prodoc) and myself, I’m pleased to announce that the main server has been updated! We now have support for DataQuality, Labels, improved cover art, track annotations and a whole host of bug reports. To see the detailed list of what things have been included in this release, please see our release milestone.

This release is significant in a number of ways:

1. The labels feature is our first major schema extension in quite some time.
2. Its our first schema change release in over a year!
3. Age Bosma (Prodoc) has submitted a number of patches that were included in this release. Its great to see another aspiring developer getting code included in the main server. Well done and thanks much, Age!

Huge thanks go to Lukáš, Dave, Age for working on this release. Thank you!

The next server update is scheduled to happen one week from today. Today Lukáš and I finished checking in changes and will now only do further bug fixes — that is if you help us find more bugs!

A few things to note:

• Lukáš added support for track annotations and release formats!
• Data quality changes are no longer automods for everyone. Their behavior is defined in the edit info page now.
• Since we’ve implemented the DataQuality feature, expired edits will no longer stay open for a grace period. Thus the next time ModBot runs after the next release, a bunch of expired edits will be accepted, since all the data will be at the default level and the action for expired edits at the default level is to accept the edit! Is this really what we want? Please take a moment to review the edit info page now and make sure it all makes sense to you!

The staging server is now updated with the latest code — please come and help us test over the next week to make sure no new bugs slipped into the upcoming release.

April 1st may not be the best date to release a new server, but scheduling would have it that way: The next server update is officially scheduled for April 1st, 2007.

To prevent the next release from becoming a bad April Fools joke, we will need your help to test the new features on the server. Recently we’ve asked people to come check out the new Labels support and the Data Quality support. Now that we’re coming to a close on this new release (there are still bugs to be fixed, but major functionality changes are done) we’d like people to come check it out again and help us test on the staging server.

The following features will be included in the next release:

1. Improved cover art support: A new release-url Advanced Relationship link type has been created. By linking a release to a cover art JPG file at CD Baby or at the Internet Archive, editors will now able to deep link to cover art on sites other than Amazon.com. For more information on this feature, see CoverArtSites. See an example here and here.
2. Data quality: Based on the first round of feedback, we’ve narrowed the data quality levels down to 3 from 4. The staging server has also been loaded with recent data and the ModBot is now running for a more complete test. See below for more comments on this.
3. Label support: Label support has been around and a number of bugs have been fixed. For more info see Labels.
4. Lookup nagging: Nagging tagger users who look up their files at MusicBrainz but who have not donated. If you go to to the taglookup page, you will be constantly nagged if you’re not logged in. If you log in, you will only be nagged every 5th lookup (I suspect that most people will be logged in). If you’ve donated to MusicBrainz, you wont be nagged at all. Designed to be not terrible right off the bat, I am curious to see what people think of this solution. Please point your tagger to http://test.musicbrainz.org and do some lookups to see if you think the current nagging approach will work ok.
5. Bug fixes: Lots of them — see our milestone info for more details.

I have some more comments regarding the DataQuality feature — based on blog feedback I’ve changed the data quality levels to:

1. Low
2. Unknown
3. High

I’m not certain if these are the best levels, but I wanted to throw out some thoughts that go with choosing these names/levels. First, the existing data and all new data that editors have not vouched for needs to have a name attached to it that makes sense. Just applying low data quality to all data by default will be unfair to large swatches of our data. I think one level needs to indicate that no human has vouched for the data and the other levels needs to indicate that someone has looked at the data and given it a thumbs up or thumbs down. Second, I like Low and High, but I am not a big fan of Unknown. What other word can we use that suggests that no human has vouched for this data?

Other suggestions I’ve tried for level names:

• bad, unknown, good
• unverified, unknown, verified

I tend to dislike these levels since labeling our data as bad seems like a poor idea. And verified is questionable as well — what do you verify the data against? So, please take the staging server for another spin and let us know what you think now. We still have nearly three weeks to try and figure our the best way of handling this.

Finally, the change artist/release quality edits are currently still auto edits for everyone — this will be changed before the release.

Thanks!