[Treebase-devel] treebasestage - cleanup and migration plan

[Vladimir G. <vla...@du...>]

On Jan 28, 2010, at 10:20 AM, youjun guo wrote:
> In table phylotree, many trees do not have a study_id value, but  
> their phylotreenode related to study 22 via table taxonlabel.  Their  
> phylotree_id are:
>
> 1129,1130,1131,1132,     2333,2334,2335,2336,2337,2338,
> 2339,2340,2341,2343,2556,2557,2686,2726,2727,2787,2788,2789,2790 
> ,      
> 3446,3671,3766,3767,3901,3902,3903,3904,3905,3906,3907,3908,3909,3910,3911,3912 
> ,     4062,4063,                
> 5705,5706,5707,5708,5720,5721,5921,5941,5981,160000022341
>
> I will delete those trees because their foreign key constrain   
> prevent me from cleaning up about 10,000 dummy taxonlabel records  
> related to submission 22 (study 22 and submission 22 happen to be  
> the same).


Youjun, Bill,

Thanks for the notice!
After you iron out all the wrinkles of this study22 cleanup on the  
treebasedev instance, please apply the cleanup to the treebasestage  
instance.

All,

treebasestage is an instance restored from a backup of treebasedev  
done around Dec 8. This is the instance where we will construct the  
new "pristine" copy of the data.  The steps that I propose are:

  (1) Apply all known clean-ups.  Study22 is one.  I recall there are  
a couple more, but I need to check past emails to remember what they  
are.  If anyone would like to take charge of that, that would be  
great.  I do think, though, that any clean-up task should be first  
debugged and tested on treebasedev.

(2) Apply hibernate_sequence fix.  It appears we are still figuring  
out what the fix should be.  Among other considerations, it may depend  
on the outcome of testing the migration procedures.

(3) Apply Dec 2009 migration.  That's after I finish testing it on my  
local (initially empty) instance and, maybe, on treebasedev.

(4) Inspect it by hand to determine if more cleanup is needed and fix  
any problems.

(5) Apply Jan 2010 migration.

(6) Restore from treebasestage to the "real" production instance. (And  
to treebasedev as well.)

It is possible that steps (2) and (3) may need to be swapped  
(depending on how the migration tools behave). I am also not sure  
about the order of (4) and (5).

While this is going on with treebasestage, Jon will use the same Dec 8  
backup to bring on-line the real production instance. He (and anyone  
else interested) can use it, in parallel, for testing any  
configuration, performance, availability, etc. issues that may come  
up.  The aim is to have the production fully operational, so that the  
only remaining tasks on Day 0 would be [1] restoring DB from  
treebasestage  and [2] dropping the appropriate WAR.

Please raise your concerns if anything appears off with this data  
migration plan.

--Vladimir