[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.3, Mon Jun 28 19:21:24 2004 UTC revision 1.4, Wed Jul 21 16:59:51 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 2-5 hours will occur when  used to prepare updated versions of the system.  Even so, work stoppages of 4-8 hours will occur when
170  new releases are swapped in.  To swap in new data from the update system to the production system,  new releases are swapped in.  To swap in new data from the update system to the production system,
171  you need to  you need to
172  <ol>  <ol>
173  <li>stop all work on the production machine,  <li>stop all work on the production machine,
174  <li>do a peer-to-peer update from the production machine to the update machine to  <li>You now need to capture the assignments, annotations and
175  capture all annotations and assignments,  subsystems work that has been done on the production machine.  To do
176  <li> move the Data directory in the production machine to a backup location,  this, you need to know when the last production release was
177  <li> move in a copy of the update Data directory, and  installed.  Suppose that it was July 1, 2004.  If that was the date,
178  <li> run  we recommend that you
179    run<br><br>
180  <pre>  <pre>
181          fig load_all      <b>extract_data_for_syncing_after_update 7/1/2004 /tmp/sync.data.july.1.2004<</b>
182    </pre>
183    <br><br>
184    This will capture your updates and save them in the directory
185    /tmp/sync.data.july.1.2004.
186    <li>Now, you need to replace your <b>Data</b> directory (within
187    <b>FIGdisk/FIG</b>) with the new version from the update system.  We
188    suggest that you do the following:
189    <ol>
190    <li>archive the existing <b>Data</b> directory.  These can usually be
191    discarded within a month or two, but keeping them around is a good
192    safety measure.
193    <li>move a copy of the update <b>Data</b> directory into the
194    <b>FIGdisk/FIG</b> directory.
195    </ol>
196    At this point, you have a version of the data from the update system
197    in the right location, but the internal databases all contain the old data.
198    <li> Now, run
199    <pre>
200            <b>fig load_all</b>
201  </pre>  </pre>
202  to reload the production databases with the data from the newly inserted Data directory.  to reload the production databases with the data from the newly inserted Data directory.
203  This will usually take several hours.  This will usually take several hours.
204    <li>Now, you need to capture the changes made to the old production
205    version using something like
206    <br>
207    <pre>
208            <b>sync_new_system /tmp/sync.data.july.1.2004 make-assignments</b>
209    </pre>
210    <br>
211  <li> make the production machine available for use.  <li> make the production machine available for use.
212    <li>You should now bring your update system to the same state as the
213    production system.  This can be done by making sure that
214    <b>/tmp/sync.data.july.1.2004</b> is accessible to the update system.
215    If the production and update systems are run on the same machine, then
216    the directory is already there.  If not, copy it to <b>/tmp</b> on the
217    update machine.  Then run
218    <br>
219    <pre>
220            <b>sync_new_system /tmp/sync.data.july.1.2004 make-assignments</b>
221    </pre>
222    <br>
223    on the update machine.
224  </ol>  </ol>
225  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,
226  this 2-system approach is the way to do it.  this 2-system approach is the way to do it.  You can, if necessary,
227    put both systems on the same physical machine.  This does require some
228    special handling in setting up two different <b>FIGdisk</b>
229    directories.  We recommend using <b>FIGdisk.production</b> and
230    <b>FIGdisk.update</b>.  However, in general it makes sense to use two
231    separate physical machines, for backup if nothing else.  The update
232    system can usually be run on a $2000 (or less) box, although it is
233    desirable to spend a little more and get at least 1 gigabyte of main
234    memory and 200 gigabytes of external disk.
235  <br>  <br>
236  <h2>Adding a New Genome to an Existing SEED</h2>  <h2>Adding a New Genome to an Existing SEED</h2>
237  To add a new genome to a running SEED is fairly easy, but there are a  To add a new genome to a running SEED is fairly easy, but there are a
# Line 525  Line 572 
572  <pre>  <pre>
573          make_a_SEED /Users/fig/FIGdisk /Volumes/Tmp/ExtractedData /Volumes/MyFriend/FIGdisk.ReadyToGo          make_a_SEED /Users/fig/FIGdisk /Volumes/Tmp/ExtractedData /Volumes/MyFriend/FIGdisk.ReadyToGo
574          rm -rf /Volumes/Tmp/ExtractedData          rm -rf /Volumes/Tmp/ExtractedData
 <<<< Bob, can you write make_a_SEED??? >>>  
575  </pre>  </pre>
576    
577  <h2>Periodic Reintegration of Similarities</h2>  <h2>Periodic Reintegration of Similarities</h2>

Legend:
Removed from v.1.3  
changed lines
  Added in v.1.4

MCS Webmaster
ViewVC Help
Powered by ViewVC 1.0.3