[Bio] / FigTutorial / SEED_administration_issues.html Repository:
ViewVC logotype

Diff of /FigTutorial/SEED_administration_issues.html

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.6, Fri Jul 23 20:33:37 2004 UTC revision 1.7, Wed Jul 28 21:21:59 2004 UTC
# Line 166  Line 166 
166  effort.  In this case, you have a user community that is sensitive to disruptions of service, and you  effort.  In this case, you have a user community that is sensitive to disruptions of service, and you
167  have frequent demands to update versions of data.  In this case, it is best to have two systems: the  have frequent demands to update versions of data.  In this case, it is best to have two systems: the
168  <b>production system</b> is used to support the larger user community, and the <b>update system</b> is  <b>production system</b> is used to support the larger user community, and the <b>update system</b> is
169  used to prepare updated versions of the system.  Even so, work stoppages of 4-8 hours will occur when  used to prepare updated versions of the system.
170  new releases are swapped in.  To swap in new data from the update system to the production system,  New genomes are added to the update system, and then periodically a
171  you need to:  revised Data directory is extracted to update the production system.
172    Even so, work stoppages of a few hours will occur when
173    new releases are swapped in.
174    <p>
175    This use of an "update" and a "production" system is quite analogous
176    to running a production system which is occasionally updated from new
177    Data DVDs (which FIG normally makes available about every 4-6 months).
178    That is, in both cases you are updating a production system from a
179    newly created <b>Data</b> directory that is lacking assignments and
180    annotations that exist on your production system.  However, if you have
181    added new genomes to the production system (that are not part of the
182    releases you may acquire via DVDs), you should get the new release,
183    install the versions of your local genomes, and then do this update
184    procedure.
185    <p>
186    The plan we propose is to build a completely encapsulated new version
187    of the system, then capture updates from the old production system, update
188    the new production system, and then make the new version the actual
189    production system.  This last step amounts to altering a symbolic link
190    to point at the new production system rather than the old.  This has
191    the virtue of ease of recovery -- that is, if something goes wrong you
192    can flip back to the old system.
193    The actual steps are as follows:
194  <ol>  <ol>
195    <li>First make a copy of the Code Distribution Environment (from a DVD
196    or via the network).  Suppose that we have made such a directory in
197    CodeDistEnv.  Then use,
198    <br>
199    <pre>
200            cd CodeDistEnv
201            ./install-code TargetDirectory
202    </pre>
203    where <b>TargetDirectory</b> is where you wish to build the new
204    production version.  We recommend calling it something like
205    <b>FIGdisk.July24</b>.
206    
207  <li> Stop all work on the production machine for the duration of the update.  <li> Stop all work on the production machine for the duration of the update.
208       You do this by clicking on the "Seed Control Panel" link,       You do this by clicking on the "Seed Control Panel" link,
209       and then entering an explanatory message in the text box       and then entering an explanatory message in the text box
# Line 185  Line 219 
219       <br><br>       <br><br>
220       This will capture your updates and save them in the directory       This will capture your updates and save them in the directory
221       /tmp/sync.data.july.1.2004.       /tmp/sync.data.july.1.2004.
222  <li> Now, you need to replace your <b>Data</b> directory (within  <li>Now, you need to stop the existing production system using
223       <b>FIGdisk/FIG</b>) with the new version from the update system.  We  <br>
224       suggest that you do the following:  <pre>
225       <ol>          ~/FIGdisk/bin/stop-servers
226       <li> Archive the existing <b>Data</b> directory.  These can usually be  </pre>
227            discarded within a month or two, but keeping them around is a good  <br>
228            safety measure.  
229      <li> Move a copy of the update <b>Data</b> directory into the  <li>Now, you need to configure the runtime environment for the system
230           <b>FIGdisk/FIG</b> directory.  you are running on.
231      </ol>  To do this, use
232      At this point, you have a version of the data from the update system  <br>
233      in the right location, but the internal databases all contain the old data.  <pre>
234  <li> Now, run          cd TargetDirectory
235            ./configure MacOrLinux
236    </pre>
237    where <b>MacOrLinux</b> must be a currently supported environment.
238    Those that are supported on July 24, 2004 are <b>mac</b> for
239    Macintoshes running panther, <b>mac-jaguar</b> for those that have not
240    upgraded to panther, and <b>linux-postgres</b>.
241    
242    <li>Now, you need to insert the new Data directory into the newly
243    constructed version of the SEED.  To do this use
244    <br>
245    <pre>
246            cd TargetDirectory/FIG
247            chmod -R 777 Data
248            ln -s TheNewData Data
249    </pre>
250    where TheNewData is the new Data directory, which normally comes  from the
251    update system.  If you acquired a new Data directory via Data DVDs, you
252    will need to unpack them using the README instructions, but what
253    results is a new version of the <b>Data</b> directory.
254    <li>Now, you need to start the servers in order to load the databases
255    with the new release using
256    <br>
257       <pre>       <pre>
258          <b>fig load_all</b>          cd TargetDirectory/bin
259            ./start-servers
260            cd ..
261            source config/fig-user-env.sh
262            init_FIG
263            fig load_all
264       </pre>       </pre>
265       to reload the production databases with the data from the newly inserted Data directory.  <br>
266       This will usually take several hours.  This last command will run for several hours.
267  <li> Now, you need to capture the changes made to the old production  <li> Now, you need to capture the changes made to the old production
268       version using something like       version using something like
269       <br>       <br>
# Line 210  Line 271 
271           <b>sync_new_system /tmp/sync.data.july.1.2004 make-assignments</b>           <b>sync_new_system /tmp/sync.data.july.1.2004 make-assignments</b>
272       </pre>       </pre>
273       <br>       <br>
274  <li> Make the production machine available for use.  <li>Run
275    <br>
276    <pre>
277            index_annotations
278            index_subsystems
279            make_indexes
280    </pre>
281    <li>Now, finally, you should alter the symbolic link in <i>~fig</i> to
282    the current FIGdisk using something like:
283    <br>
284    <pre>
285            cd ~fig
286            rm FIGdisk     # should be removing a symbolic link to the current SEED
287            ln -s TargetDirectory FIGdisk
288    </pre>
289    That should make the new SEED the one available through the Web interface.
290  <li> You should now bring your update system to the same state as the  <li> You should now bring your update system to the same state as the
291       production system.  This can be done by making sure that       production system.  This can be done by making sure that
292       <b>/tmp/sync.data.july.1.2004</b> is accessible to the update system.       <b>/tmp/sync.data.july.1.2004</b> is accessible to the update system.
# Line 224  Line 300 
300       <br>       <br>
301       on the update machine.       on the update machine.
302  </ol>  </ol>
303    <p>
304    
305  Our experience is that anytime a group wishes to share a common production environment,  Our experience is that anytime a group wishes to share a common production environment,
306  this 2-system approach is the way to do it.  You can, if necessary,  this 2-system approach is the way to do it.  You can, if necessary,
307  put both systems on the same physical machine.  This does require some  put both systems on the same physical machine.  This does require some

Legend:
Removed from v.1.6  
changed lines
  Added in v.1.7

MCS Webmaster
ViewVC Help
Powered by ViewVC 1.0.3