mirror of
https://github.com/berkeleydb/libdb.git
synced 2024-11-16 17:16:25 +00:00
212 lines
8.9 KiB
HTML
212 lines
8.9 KiB
HTML
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
|
||
<title>Using Hot Failovers</title>
|
||
<link rel="stylesheet" href="gettingStarted.css" type="text/css" />
|
||
<meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
|
||
<link rel="start" href="index.html" title="Getting Started with Berkeley DB Transaction Processing" />
|
||
<link rel="up" href="filemanagement.html" title="Chapter 5. Managing DB Files" />
|
||
<link rel="prev" href="architectrecovery.html" title="Designing Your Application for Recovery" />
|
||
<link rel="next" href="logfileremoval.html" title="Removing Log Files" />
|
||
</head>
|
||
<body>
|
||
<div xmlns="" class="navheader">
|
||
<div class="libver">
|
||
<p>Library Version 11.2.5.3</p>
|
||
</div>
|
||
<table width="100%" summary="Navigation header">
|
||
<tr>
|
||
<th colspan="3" align="center">Using Hot Failovers</th>
|
||
</tr>
|
||
<tr>
|
||
<td width="20%" align="left"><a accesskey="p" href="architectrecovery.html">Prev</a> </td>
|
||
<th width="60%" align="center">Chapter 5. Managing DB Files</th>
|
||
<td width="20%" align="right"> <a accesskey="n" href="logfileremoval.html">Next</a></td>
|
||
</tr>
|
||
</table>
|
||
<hr />
|
||
</div>
|
||
<div class="sect1" lang="en" xml:lang="en">
|
||
<div class="titlepage">
|
||
<div>
|
||
<div>
|
||
<h2 class="title" style="clear: both"><a id="hotfailover"></a>Using Hot Failovers</h2>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>
|
||
You can maintain a backup that can be used for failover purposes.
|
||
Hot failovers differ from the backup and restore
|
||
procedures described previously in this chapter in that data
|
||
used for traditional backups is typically copied to offline storage.
|
||
Recovery time for a traditional backup is determined by:
|
||
</p>
|
||
<div class="itemizedlist">
|
||
<ul type="disc">
|
||
<li>
|
||
<p>
|
||
How quickly you can retrieve that storage media.
|
||
Typically storage media for critical backups is moved
|
||
to a safe facility in a remote location, so this step can
|
||
take a relatively long time.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
How fast you can read the backup from the storage media
|
||
to a local disk drive. If you have very large backups,
|
||
or if your storage media is very slow, this can be a
|
||
lengthy process.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
How long it takes you to run catastrophic recovery
|
||
against the newly restored backup. As described earlier
|
||
in this chapter, this process can be lengthy because
|
||
every log file must be examined during the recovery
|
||
process.
|
||
</p>
|
||
</li>
|
||
</ul>
|
||
</div>
|
||
<p>
|
||
When you use a hot failover, the backup is maintained
|
||
at a location that is reasonably fast to access. Usually, this
|
||
is a second disk drive local to the machine.
|
||
In this situation, recovery time is very quick
|
||
because you only have to reopen your
|
||
environment and database, using the failover environment
|
||
for the environment open.
|
||
</p>
|
||
<p>
|
||
Hot failovers obviously do not protect you from truly
|
||
catastrophic disasters (such as a fire in your machine room)
|
||
because the backup is still local to the machine. However,
|
||
you can guard against more mundane problems (such as a broken
|
||
disk drive) by keeping the backup on a
|
||
second drive that is managed by an alternate disk controller.
|
||
</p>
|
||
<p>
|
||
To maintain a hot failover:
|
||
</p>
|
||
<div class="orderedlist">
|
||
<ol type="1">
|
||
<li>
|
||
<p>
|
||
Copy all the active database files to the failover
|
||
directory. Use the <span class="command"><strong>db_archive</strong></span>
|
||
command line utility with the
|
||
<code class="literal">-s</code> option to identify all the active
|
||
database files.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
Identify all the inactive log files in your production
|
||
environment and <span class="emphasis"><em>move</em></span> these to the failover
|
||
directory. Use the <span class="command"><strong>db_archive</strong></span>
|
||
command with no command line options to obtain a list
|
||
of these log files.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
Identify the active log files in your production
|
||
environment, and <span class="emphasis"><em>copy</em></span> these to the
|
||
failover directory. Use the
|
||
<span class="command"><strong>db_archive</strong></span> command with the
|
||
<code class="literal">-l</code> option to obtain a list of these
|
||
log files.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
Run catastrophic recovery against the failover
|
||
directory. Use the <span class="command"><strong>db_recover</strong></span>
|
||
command with the <code class="literal">-c</code> option to do
|
||
this.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
Optionally copy the backup to an archival location.
|
||
</p>
|
||
</li>
|
||
</ol>
|
||
</div>
|
||
<p>
|
||
Once you have performed this procedure, you can maintain an
|
||
active hot backup by repeating steps 2 - 5 as often
|
||
as is required by your application.
|
||
</p>
|
||
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
|
||
<h3 class="title">Note</h3>
|
||
<p>
|
||
If you perform step 1, steps 2-5 must follow in order to
|
||
ensure consistency of your hot backup.
|
||
</p>
|
||
</div>
|
||
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
|
||
<h3 class="title">Note</h3>
|
||
<p>
|
||
Rather than use the previous procedure, you can use the <span class="command"><strong>db_hotbackup</strong></span> command line utility
|
||
to do the same thing. This utility will (optionally) run a checkpoint and then copy all necessary files to a target
|
||
directory for you.
|
||
</p>
|
||
</div>
|
||
<p>
|
||
To actually perform a failover, simply:
|
||
</p>
|
||
<div class="orderedlist">
|
||
<ol type="1">
|
||
<li>
|
||
<p>
|
||
Shut down all processes which are running against the original environment.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
If you have an archival copy of the backup environment, you can optionally try copying the remaining
|
||
log files from the original environment and running catastrophic recovery against that backup
|
||
environment. Do this <span class="emphasis"><em>only</em></span> if you have a an archival copy of the backup
|
||
environment.
|
||
</p>
|
||
<p>
|
||
This step can allow you to recover data created or modified in the original environment, but which
|
||
did not have a chance to be reflected in the hot backup environment.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
Reopen your environment and databases as normal, but use
|
||
the backup environment instead of the production
|
||
environment.
|
||
</p>
|
||
</li>
|
||
</ol>
|
||
</div>
|
||
</div>
|
||
<div class="navfooter">
|
||
<hr />
|
||
<table width="100%" summary="Navigation footer">
|
||
<tr>
|
||
<td width="40%" align="left"><a accesskey="p" href="architectrecovery.html">Prev</a> </td>
|
||
<td width="20%" align="center">
|
||
<a accesskey="u" href="filemanagement.html">Up</a>
|
||
</td>
|
||
<td width="40%" align="right"> <a accesskey="n" href="logfileremoval.html">Next</a></td>
|
||
</tr>
|
||
<tr>
|
||
<td width="40%" align="left" valign="top">Designing Your Application for Recovery </td>
|
||
<td width="20%" align="center">
|
||
<a accesskey="h" href="index.html">Home</a>
|
||
</td>
|
||
<td width="40%" align="right" valign="top"> Removing Log Files</td>
|
||
</tr>
|
||
</table>
|
||
</div>
|
||
</body>
|
||
</html>
|