ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzaki_5.4.0.1/rzakihotbackup.htm

114 lines
7.6 KiB
HTML

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en-us" xml:lang="en-us">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="security" content="public" />
<meta name="Robots" content="index,follow" />
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
<meta name="DC.Type" content="topic" />
<meta name="DC.Title" content="Scenario: Hot-backup environment" />
<meta name="abstract" content="In this scenario, the remote journaling environment uses a hot-backup application that causes JKLINT2 to replace JKLINT in the case that JKLINT has a failure." />
<meta name="description" content="In this scenario, the remote journaling environment uses a hot-backup application that causes JKLINT2 to replace JKLINT in the case that JKLINT has a failure." />
<meta name="DC.Relation" scheme="URI" content="rzakirscenarios.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakirdatarep.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakirdatarep.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakirecovery.htm" />
<meta name="copyright" content="(C) Copyright IBM Corporation 2004, 2006" />
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2004, 2006" />
<meta name="DC.Format" content="XHTML" />
<meta name="DC.Identifier" content="rzakihotbackup" />
<meta name="DC.Language" content="en-us" />
<!-- All rights reserved. Licensed Materials Property of IBM -->
<!-- US Government Users Restricted Rights -->
<!-- Use, duplication or disclosure restricted by -->
<!-- GSA ADP Schedule Contract with IBM Corp. -->
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
<link rel="stylesheet" type="text/css" href="./ic.css" />
<title>Scenario: Hot-backup environment</title>
</head>
<body id="rzakihotbackup"><a name="rzakihotbackup"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Scenario: Hot-backup environment</h1>
<div><p>In this scenario, the remote journaling environment uses a hot-backup
application that causes JKLINT2 to replace JKLINT in the case that JKLINT
has a failure.</p>
<p>A <span class="uicontrol">hot-backup application</span> typically performs the
following:</p>
<ol><li>If the primary system fails, it performs a switch-over to the backup system.
This function then logically promotes the backup system to assume the role
of the primary system.</li>
<li>After the failed primary system is restarted, it performs a switch-back
operation so that the primary system can again assume the role of the primary
system.</li>
</ol>
<p>A <span class="uicontrol">hot-backup application apply</span> defines the part
of a hot-backup application that actually performs the replay operations to
the data replica. This usually occurs on the backup system when maintaining
a data replica.</p>
<p>The following figure describes a typical remote journal environment that
is used for hot-backup purposes. The following occurs in this illustration:</p>
<ul><li>Server JKLINT is the primary server while JKLINT2 is the backup server.</li>
<li>Server JKLINT journals objects to local journal JKLB1/JRN.</li>
<li>Changes to those journaled objects are also journaled to remote journal
JLB2/JRN on server JKLINT2.</li>
<li>On JKLINT2 a hot backup-apply replays changes to the data replica. When
the hot backup-apply replays these changes, JKLINT2 journals the changes to
its own local journal, JLB1/JRN.</li>
<li>If JKLINT fails, JKLINT2 assumes the role of primary server and all local
journaling of changes to the data replica (now acting as the original data)
continue on JKLINT2's local journal, JLB1/JRN.</li>
<li>When it is time to switch the role of primary server back to JKLINT, JKLINT2
sends changes from its local journal, JLB1/JRN, to remote journal JLB2/JRN
on server JKLINT (the transport from JKLINT2 to JKLINT is only used for this
purpose).</li>
<li>JKLINT then uses its remote journal, JLB2/JRN, to replay changes to the
original data.</li>
</ul>
<div class="section"><h4 class="sectiontitle">Typical hot-backup environment with remote journal function</h4><br /><img src="rzaki515.gif" alt="Typical hot-backup environment with remote journal function" /><br /></div>
<div class="section"><h4 class="sectiontitle">How to establish the hot-backup environment</h4><p>The
steps to establish a hot-backup environment the are the same as establishing
data replication environment except for this additional last step:</p>
<p>Sharon
also establishes a remote journal JKLINT that is associated with the local
journal that she creates on JKLINT2. This remote journal receives or retrieves
the journaled changes that are made when JKLINT2 assumes the role of the primary
system. This local journal and remote journal pair will only be used when
replicating changes back to the original data. During normal run-time processing,
the remote journal, JLB2/JRN, that is defined on JKLINT is not active. When
it is not active, it is not receiving or retrieving journal entries from the
local journal, JLB1/JRN, on JKLINT2.</p>
</div>
<div class="section"><h4 class="sectiontitle">Normal run-time environment for the hot-backup environment</h4>The
details for run-time environment for the hot-backup environment is the same
as the data replication environment.</div>
<div class="section"><h4 class="sectiontitle">Hot-backup recovery if JKLINT fails</h4><p>If you use a
hot-backup application where the logical ownership of the data is given to
JKLINT2, recovery is more complicated. In this case, the hot-backup application
logically promotes JKLINT to assume the role of the primary system. Recovery
is more complicated because after JKLINT has completed its IPL, the remote
journal function catch-up phase from the local journal on system JKLINT to
the remote journal on system JKLINT2 will always allow a resynchronization
of the two sets of data.</p>
<p><span class="uicontrol">Data resynchronization</span> is
recovery processing that is performed during switch-back processing by a hot-backup
application apply. This processing ensures that the original data is consistent
with the data replica, and contains all the correct changes. The main objective
of this, besides assuring data consistency, is to eliminate re-priming the
original data from the data replica.</p>
<p>For details on recovering a hot-backup
environment see Scenario: Recovery for remote journaling.</p>
</div>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzakirscenarios.htm" title="These scenarios describe the possible ways that JKL Toy Company can use remote journal management. JKL Toy Company uses the server JKLINT as their web server.">Scenarios: Remote journal management and recovery</a></div>
</div>
<div class="relinfo"><strong>Related information</strong><br />
<div><a href="rzakirdatarep.htm" title="In this scenario, JKLINT and JKLINT2 use remote journaling for data replication purposes only.">Scenario: Data replication environment for remote journals</a></div>
<div><a href="rzakirecovery.htm" title="This scenario describes a hot-backup environment in which the local system, JKLINT fails. It is necessary to restore the local system, and synchronize it with the remote system, JKLINT2.">Scenario: Recovery for remote journaling</a></div>
</div>
</div>
</body>
</html>