#musicbrainz-devel

very odd.

Cannot upgrade #236638: This data is corrupt and cannot be upgraded at /home/acid2/musicbrainz-server/admin/sql/updates/../../../lib/MusicBrainz/Server/Edit/Historic/EditTrackNum.pm line 48.

that's the last line for me

ruaok: well if it crashes I didn't have anything to display the error

but I've got a commit for that too

shall I push and resume migration from this script?

I didin't see any error either.

yea, it dies silently

but since you had it in a transaction, you can re-run it, right?

yep

right-o.

I'm coming up on 2am here.

djce: you here right now?

ping

ok, I'd like to hand over the reigns to both of you and get some sleep.

first: reboot astro.

can we do that now?

go for it...

ocharles: you've got root, close off your sessions and last man out gets to reboot it ...

i'm out!

dont go anywhere!@

astro is rebooting.

i'm here

ok.

ocharles will need to make sure all is well.

and that the right branch is loaded and read to go.

once ocharles is happy with the branch, we need to start executing the migration plan.

djce: can you please be the master of ceremonies?

I'll try :-)

:)

have we stolen djce for the day?

2 days!

lets go through what we needs to happen in the next 8 hours.

cool :)

Disallow any changes to MB.

for that, svn up the codebase on tails, stimpy, dexter.

does that stop modbot?

no.

> Change the data download URL in admin/replication/LoadReplicationChanges

we can skip that til later.

I'll move it.

> stop all cron jobs on classic

you illustrated that to me earlier djce. should be no issue.

I can do that.

> Close all open edits

set the expire and close time of all edits in moderation_open to now().

the run CheckVotes.pl

the end results should be an emty moderation_open table

(oh and ofter the web servers need to be restarted once svn up is done above)

sure

and get nikki or reoscarksiorsky to check to make sure that no one can edit anything.

> Dump the MB Classic data for the last time.

poor reosarevok :P

easy, you know what needs to happen.

> Move the last classic data dump to permanently saved location on the FTP server.

move it out of the data dir.

maybe into the classic dir.

ok

or a dir called classic

> Copy the data to astro and start import into clean DB.

don't forget the private data file in /usr/local/mb_server/backup.

on scooby that is.

> Start migration immediately. igrate to musicbrainz_db and musicbrainz_db_raw, and set type to RT_MASTER in the migration codebase

are we going to have ngs.mb up while migration is running?

djce: you'll recognize what is going on here. this step requires that the export be called with --without-replication

ocharles: should be possible. your call.

yep, it will be possible, just a tiny bit more load

shouldn't be a problem

djce: still with me?

shall I commit --without-replication to upgrade.sh?

so the final export from classic needs to be --without-replication ?

no.

actually that step can probably wait.

ignore that for now.

once the replication finishes, bring it up on ngs.mb.org and poke at it.

get everyone and their mom to poke at it. see if it has problems.

Sorry, I'm lost. What step can wait?

http://tickets.musicbrainz.org/browse/MBS-1867 can wait.

ok

djce: ./upgrade.sh will fail, right at the end

but you don't need to worry about that, iirc

oh, its part of migration.

hum, one sec.

ruaok: that's why I said shall I add the flag to upgrade.sh

hrm, it has --without-replication in the export in upgrade.sh

yeah.

not sure wtf.

it dies because the dbmirror* tables are not present.

ocharles: add this line before the vacuum:

Not entirely sure I understand what's going on. The import of the final classic export, on astro, into totoro, uses what codebase?

./admin/psql READWRITE <./admin/sql/CreateReplicationSetup.sql

djce: the 'production' branch

can I use astro yet btw?

So that knows how to import a classic db?

and ocharles will be in charge of making sure that branch is ready to go.

djce: indeed

it doesn't.

yea...

ok, hold on a sec ocharles

1. copy all the dump files to astro.

2. double check the private data file is there too

3. import the classic data with the mb_server codebase in ~musicbrainz on astro.

ah

4. Once the classic data is imported, start migration.

using the musicbrainz-server production branch?

yes.

ocharles: you know how to do that step presumably.

ocharles: did you note to add the ReplicationSetup.sql step?

yes, that's commited to edit-fixes

get.

which assuming this all works on astro/my machine will be commited straight to master shortly

echo "PLEASE BACKUP these exported dumps from /tmp/mbexport-XXXX!!!!!!"

those are the tmp tables we need to save so save them in some place on put them on the ftp site.

so catalyst needs to be stopped presumably while the migration occurs?

djce: nope, just using a different database

hm

so, a different codebase copy too then?

yep

probably best to just stop it

rather than making more work for ourselves

And the migration is what, "./upgrade.sh" ?

yep

once you've set DBDefs.pm up, of course

and it takes roughly how long?

~6 hours?

thereabouts.

should be faster now with a reboot.

can I kick the script off again now, btw?

I've made some changes to http://wiki.musicbrainz.org/Next_Generation_Sch...

please review.

the artist fix? yes.

"RT_MASTER in the migration codebase " happens /before/ running upgrade.sh ?

I don't think it mattes.

k

I've always done it as RT-STANDALONE come to think of it.

and then promote it to master by hand by doing the replication stuff.

tbh by the time we get to this point, I think you'll be back with us again.

yea, that's about 8 hours away

yep.

I just updated the times in the wiki page.