241 lines
18 KiB
HTML
241 lines
18 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="task" />
|
|
<meta name="DC.Title" content="Details: Recovery for remote journaling scenario" />
|
|
<meta name="abstract" content="A description of the recovery process for remote journaling." />
|
|
<meta name="description" content="A description of the recovery process for remote journaling." />
|
|
<meta name="DC.Relation" scheme="URI" content="rzakirscenarios.htm" />
|
|
<meta name="DC.Relation" scheme="URI" content="rzakirecovery.htm" />
|
|
<meta name="DC.Relation" scheme="URI" content="rzakirecovery.htm" />
|
|
<meta name="DC.Relation" scheme="URI" content="../cl/rcvjrne.htm" />
|
|
<meta name="DC.Relation" scheme="URI" content="../apis/QJORJRNE.htm" />
|
|
<meta name="DC.Relation" scheme="URI" content="rzakiswapjrnrcv.htm" />
|
|
<meta name="DC.Relation" scheme="URI" content="rzakiactiverep.htm" />
|
|
<meta name="DC.Relation" scheme="URI" content="rzakiinactivate.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="rzakirecovdtails" />
|
|
<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>Details: Recovery for remote journaling scenario</title>
|
|
</head>
|
|
<body id="rzakirecovdtails"><a name="rzakirecovdtails"><!-- --></a>
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
|
<h1 class="topictitle1">Details: Recovery for remote journaling scenario</h1>
|
|
<div><p>A description of the recovery process for remote journaling.</p>
|
|
<div class="section">These details provide a step-by-step description of the process that
|
|
occurs in Scenario: Recovery for remote journaling.</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="reltasks"><strong>Related tasks</strong><br />
|
|
<div><a href="rzakiswapjrnrcv.htm" title="An important task for journal management is to swap (or change) journal receivers. You typically swap journal receivers when they reach their storage threshold. You can swap journal receivers either with iSeries Navigator or with the Change Journal (CHGJRN) command. If you use system journal-receiver management, the system changes journal receivers for you.">Swap journal receivers</a></div>
|
|
<div><a href="rzakiactiverep.htm" title="In order to activate the replication of journal entries to a given remote journal, the following must be true:">Activate the replication of journal entries to a remote journal</a></div>
|
|
<div><a href="rzakiinactivate.htm" title="When you end replication of journal entries to a remote journal, it is recommended that the replication of entries be ended from the source system whenever possible, rather than from the target system. Usually, ending replication from the target system for a remote journal is only necessary when the source system has failed, and the system has not ended the remote journal function.">Inactivate the replication of journal entries to a remote journal</a></div>
|
|
</div>
|
|
<div class="relref"><strong>Related reference</strong><br />
|
|
<div><a href="../cl/rcvjrne.htm">Receive Journal Entry (RCVJRNE) command</a></div>
|
|
<div><a href="../apis/QJORJRNE.htm">Retrieve Journal Entries (QjoRetrieveJournalEntries) API</a></div>
|
|
</div>
|
|
<div class="relinfo"><strong>Related information</strong><br />
|
|
<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><div class="nested1" xml:lang="en-us" id="currentstatejklint2"><a name="currentstatejklint2"><!-- --></a><h2 class="topictitle2">Current state of JKLINT and JKLINT2</h2>
|
|
<div><div class="section"><p>At the time of the system failure, the state of JKL and JKLINT
|
|
is as follows:</p>
|
|
<ul><li>Journal entries 12-19 are already deposited into PJ1 and confirmed in
|
|
BJ1.</li>
|
|
<li>The corresponding data changes are also already reflected in the data
|
|
replica, DB', on system JKLINT2.</li>
|
|
<li>Journal entries 20-25 are built and validated in main storage on JKLINT
|
|
and sent to BJ1, and then system JKLINT fails.</li>
|
|
<li>Main storage is not preserved when JKLINT fails, so at the time of the
|
|
failure, the last known confirmed sequence number in BJ1 is 19. Sequence numbers
|
|
20 through 25 are all unconfirmed.</li>
|
|
<li><img src="./delta.gif" alt="Start of change" />The last known sequence number in PJ1 will be 19 when system
|
|
JKLINT restarts.<img src="./deltaend.gif" alt="End of change" /></li>
|
|
</ul>
|
|
<p>The hot-backup recovery strategy in these details does not require
|
|
that both before-images and after-images are journaled to the local journal.
|
|
However, the strategy would require before-images if, during the resynchronization
|
|
process of the switch-back to the primary system, the strategy requires that
|
|
the hot-backup application remove journaled changes. See step <a href="#stepsrequirerecov__hotbackup">3.c</a>.</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="nested1" xml:lang="en-us" id="stepsrequirerecov"><a name="stepsrequirerecov"><!-- --></a><h2 class="topictitle2">Steps required for recovery</h2>
|
|
<div><div class="section">To recover system JKLINT, the following steps are required:</div>
|
|
<ol><li class="stepexpand"><span><strong>Update DB' by using the hot-backup application to replay the
|
|
unconfirmed journal entries.</strong></span><ol type="a"><li><span>On system JKLINT2, allow the hot-backup application apply processing
|
|
to complete the replay of confirmed operations as identified in journal BJ1.
|
|
This is the first step of the switch-over processing. The apply processing
|
|
includes replaying all journal entries up through and including sequence number
|
|
19.</span></li>
|
|
<li><span>The hot-backup application does not replay sequence numbers
|
|
20-25 because the I/O for those journal entries is not yet confirmed from
|
|
the local journal PJ1. The Receive Journal Entry (RCVJRNE) command or Retrieve
|
|
Journal Entries (QjoRetrieveJournalEntries) API that is being used to retrieve
|
|
the entries from the remote journal will not return sequence numbers 20-25
|
|
to the exit program, unless specifically requested to do so. To specify that
|
|
sequence numbers 20 - 25 are returned to the exit program, use the INCENT(*ALL)
|
|
parameter on the command. You can also request this by specifying *ALL for
|
|
the include entries key on the API.</span></li>
|
|
<li><span>After the hot-backup application replays all confirmed journal
|
|
entries, perform a change journal operation to attach a new journal receiver
|
|
to local journal PJ2 on system JKLINT2 and change the state of journal PJ2
|
|
in *ACTIVE state. The change journal operation establishes a clean recovery
|
|
point. It also makes clear what information needs to be sent back to system
|
|
JKLINT later to replay back to the original data. Performing the change journal
|
|
operation also prevents the remote journal function from having to re-replicate
|
|
all of the journal entries that were previously generated into the currently
|
|
attached journal receiver of PJ2. (The journal entries were generated into
|
|
the receiver as part of replaying the database changes to the data replica
|
|
on system JKLINT2.)</span></li>
|
|
</ol>
|
|
<p>The following figure shows that more unconfirmed journal entries
|
|
are present in BJ1 than are known in PJ1.</p>
|
|
<br /><img src="rzaki509.gif" alt="This figure shows that more unconfirmed journal entries are present in BJ1 than are known in PJ1." /><br /> </li>
|
|
<li class="stepexpand"><span><strong>Perform switch-over processing and prepare JKLINT2 to run applications</strong></span><ol type="a"><li><span>The hot-backup application reads unconfirmed journal entries
|
|
from BJ1 and replays them to the data replica. They are retrieved from BJ1
|
|
by using the Receive Journal Entry (RCVJRNE) command or QjoRetrieveJournalEntries
|
|
API, specifically requesting that unconfirmed journal entries be returned.
|
|
Journal entries 140-145 are generated into journal PJ2 when replaying these
|
|
changes to the data replica.</span></li>
|
|
<li><span>The QjoChangeJournalState API or CHGJRN command inactivates
|
|
the remote journal BJ1. During this operation, the system physically removes
|
|
the unconfirmed journal entries from BJ1. The last known sequence number in
|
|
BJ1 is now 19.</span></li>
|
|
<li id="stepsrequirerecov__switchoverc"><a name="stepsrequirerecov__switchoverc"><!-- --></a><span>The replay processing on JKLINT2 sends a user
|
|
entry that indicates the point in time when the database was switched-over.
|
|
The user entry in the following figure is sequence number 146, journal code
|
|
'U', entry type 'SW'.</span></li>
|
|
<li><span>After these steps are performed on system JKLINT2, applications
|
|
can now be started on JKLINT2 and use DB' as the database to be updated. Applications
|
|
continue to work and deposit journal entries 147-200.</span></li>
|
|
<li><span>System JKLINT restarts and normal IPL recovery finds the end
|
|
of the journal for PJ1 to be sequence number 19. IPL recovery ensures that
|
|
all changes up to sequence number 19 are reflected in the original data. The
|
|
IPL for JKLINT completes with journal PJ1 being left in the *ACTIVE state,
|
|
as this was the state of the journal when the system failed.</span></li>
|
|
</ol>
|
|
<p>The following figure shows the state of BJ1, PJ2, and DB' when system
|
|
JKLINT2 is ready to assume the role of the primary system.</p>
|
|
<br /><img src="rzaki510.gif" alt="This figure illustrates switch-over processing. System JKLINT2 is now ready to allow applications to run" /><br /> </li>
|
|
<li class="stepexpand"><span><strong>Activate remote journal PJ2 and transport journal to JKLINT</strong></span><ol type="a"><li class="substepexpand"><span>After JKLINT restarts, activate the remote journal BJ2. Specify
|
|
that the process will start with the attached journal receiver on JKLINT2.
|
|
This starts the transport of journal entries representing the changes made
|
|
on JKLINT2 as part of replaying the unconfirmed journal entries plus all changes
|
|
made to DB' while JKLINT was unavailable. While this transfer is progressing
|
|
(during catch-up processing, which then transitions into synchronous or asynchronous
|
|
remote journal function mode), changes are still being made by applications
|
|
to DB'.</span></li>
|
|
<li class="substepexpand"><span>Either before or during the transport of journal entries to
|
|
BJ2, send and make known the last known sequence number in BJ1 (19) to the
|
|
hot-backup application apply. This can be included as information in the SW
|
|
user journal entry. See step <a href="#stepsrequirerecov__switchoverc">2.c</a>.</span></li>
|
|
<li class="substepexpand" id="stepsrequirerecov__hotbackup"><a name="stepsrequirerecov__hotbackup"><!-- --></a><span>The hot-backup application backs-out changes
|
|
that are known to PJ1 (after the last known sequence number in BJ1) from the
|
|
original data DB on system JKLINT. For this particular scenario, no changes
|
|
need to be backed out of the original data.</span> <div class="note"><span class="notetitle">Note:</span> For scenarios
|
|
which require this back-out processing, both before-image and after-image
|
|
journal entries are required.</div>
|
|
</li>
|
|
</ol>
|
|
<p>The following figure shows the state of both systems after system
|
|
JKLINT has completed its IPL. This is after system JKLINT2 has been running
|
|
as the primary system, but before database DB is resynchronized with DB'.
|
|
(The database changes represented in PJ2 by journal sequence numbers 147-200
|
|
are not shown in DB' for simplicity.)</p>
|
|
<br /><img src="rzaki511.gif" alt="This figure illustrates that JKLINT2 assumes the role of the primary, and DB' is now being updated. IPL processing has completed on JKLINT." /><br /> </li>
|
|
<li class="stepexpand"><span><strong>Replay changes to DB on JKLINT</strong></span><ol type="a"><li class="substepexpand"><span>The hot-backup application replays the changes back to the original
|
|
data on system JKLINT. The changes that are replayed include those changes
|
|
that were made to DB' as part of the switch-over processing. The switch-over
|
|
processing replayed the data changes for the unconfirmed journal entries (sequence
|
|
numbers 140-145)). Additional changes include those data changes that were
|
|
deposited while system JKLINT2 had assumed the role of the primary system
|
|
(sequence numbers 147-300). Note that changes are still being made to DB'
|
|
on system JKLINT2 and journal entries are still being generated into local
|
|
journal PJ2 on system JKLINT2.</span></li>
|
|
<li class="substepexpand"><span>When you decide that JKLINT must again assume the role of the
|
|
primary system, end the applications on JKLINT2. The following figure shows
|
|
the state of both systems just before system JKLINT is going to assume the
|
|
role of the primary system.</span></li>
|
|
<li class="substepexpand"><span>Allow the remaining changes to be replicated to BJ2. After all
|
|
changes have been sent to BJ2, you can inactivate BJ2.</span></li>
|
|
<li class="substepexpand" id="stepsrequirerecov__LIRJCSTEP"><a name="stepsrequirerecov__LIRJCSTEP"><!-- --></a><span><img src="./delta.gif" alt="Start of change" />After all of the journal entries have
|
|
been replayed to the original data on JKLINT, attach a new journal receiver
|
|
to PJ1 to clearly denote a new recovery point.<img src="./deltaend.gif" alt="End of change" /></span> <p>The change journal
|
|
operation is not absolutely essential. However, attaching a new journal receiver
|
|
to PJ1 at this time makes clear where to start replaying changes back to the
|
|
data replica on system JKLINT2. Performing the change journal operation also
|
|
prevents the remote journal function from having to send back all of the journal
|
|
entries that were previously generated into the currently attached journal
|
|
receiver of PJ1. (The journal entries were generated in the receiver as part
|
|
of replaying the data changes back to the original data on system JKLINT.)</p>
|
|
</li>
|
|
</ol>
|
|
<p>The following figure shows the state of the journals and data just
|
|
before starting to replay the changes back to the original data DB.</p>
|
|
<br /><img src="rzaki512.gif" alt="This figure shows the state of the journals and data just before starting to replay the changes back to the original data DB." /><br /> </li>
|
|
<li class="stepexpand"><span><strong>Allow JKLINT to again assume role of the primary system</strong></span><ol type="a"><li class="substepexpand"><span>Application programs can now make changes to the original data
|
|
DB on system JKLINT.</span></li>
|
|
<li class="substepexpand"><span>When you determine that it is time to start replicating the
|
|
changes made on the primary system to the backup system, you can activate
|
|
the remote journal BJ1.</span> <p>When activating the remote journal,
|
|
you can indicate to send journal entries starting with the attached journal
|
|
receiver on the source system. If this occurs, then only those journal entries
|
|
that are required to be replayed to the data replica will be sent to system
|
|
JKLINT2.</p>
|
|
<div class="note"><span class="notetitle">Note:</span> You can start with the attached receiver, only if you did
|
|
the change journal to attach a new receiver that was mentioned in step <a href="#stepsrequirerecov__LIRJCSTEP">4.d</a>.</div>
|
|
</li>
|
|
<li class="substepexpand"><span>If you want the complete chain of journal receivers from system
|
|
JKLINT on JKLINT2, when you activate the remote journal, indicate to start
|
|
with the attached journal receiver as known to the remote journal, BJ1. This
|
|
will complete the sending of the journal receiver that contains the IPL entry
|
|
(sequence number 20). The process will then move on to the next journal receiver
|
|
that contains the journal entries where the hot-backup application apply will
|
|
start replaying changes to the data replica. An alternative to that approach
|
|
is to save and restore the detached journal receiver to system JKLINT2.</span></li>
|
|
<li class="substepexpand"><span>You change the state of local journal PJ2 on system JKLINT2
|
|
to *STANDBY state.</span></li>
|
|
<li class="substepexpand"><span>After local journal PJ2 has put in *STANDBY state, perform a
|
|
change journal operation to attach a new journal receiver to PJ2.</span> <p>The
|
|
change journal operation is not absolutely essential. However, attaching a
|
|
new journal receiver to PJ2 at this time makes clear where the replaying of
|
|
changes back to the data replica started on system JKLINT2. Performing the
|
|
change journal operation also avoids the remote journal function from having
|
|
to later send all of these hot-backup application apply generated journal
|
|
entries back to system JKLINT.</p>
|
|
<p>The newly attached journal receiver contains
|
|
journal entries that will not have to be sent back to system JKLINT.</p>
|
|
</li>
|
|
<li class="substepexpand"><span>After the operation is performed, the hot-backup application
|
|
apply can be started on system JKLINT2 to start replaying changes to the data
|
|
replica. The hot-backup application apply starts with the source system sending
|
|
the newly attached journal receiver.</span></li>
|
|
</ol>
|
|
<p>The following figure shows that JKLINT is preparing again assume
|
|
the role of the primary system.</p>
|
|
<br /><img src="rzaki513.gif" alt="This figure shows that JKLINT is preparing again assume the role of the primary system." /><br /> </li>
|
|
</ol>
|
|
</div>
|
|
</div>
|
|
|
|
</body>
|
|
</html> |