je/docs/ReplicationGuide/hotupgrade.html
2021-06-06 13:46:45 -04:00

288 lines
13 KiB
HTML
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<?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>Upgrading a JE Replication Group</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, Java Edition High Availability Applications" />
<link rel="up" href="administration.html" title="Chapter 7. Administration" />
<link rel="prev" href="addremovenodes.html" title="Adding and Removing Nodes" />
<link rel="next" href="groupreset.html" title="Resetting a Replication Group" />
</head>
<body>
<div xmlns="" class="navheader">
<div class="libver">
<p>Library Version 12.2.7.5</p>
</div>
<table width="100%" summary="Navigation header">
<tr>
<th colspan="3" align="center">Upgrading a JE Replication Group</th>
</tr>
<tr>
<td width="20%" align="left"><a accesskey="p" href="addremovenodes.html">Prev</a> </td>
<th width="60%" align="center">Chapter 7. Administration</th>
<td width="20%" align="right"> <a accesskey="n" href="groupreset.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="hotupgrade"></a>Upgrading a JE Replication Group</h2>
</div>
</div>
</div>
<div class="toc">
<dl>
<dt>
<span class="sect2">
<a href="hotupgrade.html#idp1912848">Upgrade Process</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="hotupgrade.html#idp1949392">Things To Remember While Upgrading</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="hotupgrade.html#idp1959392">Handling Problems While Upgrading</a>
</span>
</dt>
</dl>
</div>
<p>
After deploying a BDB JE HA application, you may later want to
upgrade to a new version. Berkeley DB JE supports hot upgrade of a
replication group, by allowing mixed version operation. That is,
replication nodes running the newer software version can
inter-operate with older version nodes and both can be available for
user operations. However, in some cases, there are certain
constraints to performing such a hot upgrade.
</p>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="idp1912848"></a>Upgrade Process</h3>
</div>
</div>
</div>
<p>
Each release of Berkeley DB JE is tied to a given log file
on-disk format. Log file formats do not necessarily change
every release. The Change Log for each release specifies
whether the log file format has changed or not. There are
no restrictions on upgrades across releases that use the
same log file format. For best performance and to take
advantage of bug fixes, ensure all nodes in a replication
group run with the same BDB JE version during normal
operations. Occasionally, a new release of Berkeley DB JE
includes a log file format change. The constraints that
apply to upgrades which introduce new log file formats are
explained in this section.
</p>
<p>
In a replication group, the Master transmits log records that
must be read by the replicas. If a group is operating with
mixed version nodes, the Master must be running a version of
JE that is older than, equal to, or (by default) no more
than one version greater than the replicas. This is required
so that the Master can supply the replicas with a version of
the replication stream that they can understand.
</p>
<p>
Note that some releases may support online upgrades with
replicas running versions that are more than one log file
format version different from each other. But any such
additional flexibility will be called out in the release
notes.
</p>
<p>
To support the versioning requirement, make sure to upgrade
all nodes to the version with the next log file format before
upgrading any nodes to a still later log file format. If you
cannot meet this restriction, then a hot upgrade should be
performed. Instead, all nodes in the replication group should
be taken offline and upgraded before any are restarted.
</p>
<p>
The recommended steps for upgrading Berkeley DB JE HA when
log file formats have changed are as follows:
</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>
Determine if the upgrade skips any log file format
versions. If it has, and it is not possible to
upgrade to the intermediate versions, then plan to
perform an offline upgrade.
</p>
</li>
<li>
<p>
Bring all Replicas up to date with the Master. That
is, all Replicas must have the same environment
content as the Master. You can ascertain this by
using the <a class="ulink" href="../java/com/sleepycat/je/rep/util/DbGroupAdmin.html#dumpGroup()(com.sleepycat.je.rep.util.DbGroupAdmin)" target="_top">DbGroupAdmin.dumpGroup()</a> utility, or
programmatically using the
<a class="ulink" href="../java/com/sleepycat/je/ReplicaConsistencyPolicy.html" target="_top">ReplicaConsistencyPolicy</a>.
</p>
</li>
<li>
<p>
Perform the following upgrade procedures on each of
the environments that are part of the replication
group.
</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>
Shut down the old version of the application.
</p>
</li>
<li>
<p>
Install the new BDB JE jar file.
</p>
</li>
<li>
<p>
Restart the application.
</p>
</li>
</ul>
</div>
<p>
Upgrade each individual data node, both Replicas and
the Master, and restart them to join the replication
group.
</p>
</li>
</ol>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="idp1949392"></a>Things To Remember While Upgrading</h3>
</div>
</div>
</div>
<p>
During a hot replication upgrade:
</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>
Upgrading BDB JE 4.0 directly to BDB JE 5 and higher
versions is prohibited. Upgrade BDB JE 4.0 to BDB JE
4.1 first, and then upgrade BDB JE 4.1 to higher
versions. There is no constraint if you upgrade from
BDB JE 4.1 or later versions to a higher BDB JE
version.
</p>
</li>
</ul>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="idp1959392"></a>Handling Problems While Upgrading</h3>
</div>
</div>
</div>
<p>
There are exceptions that you may run into during the upgrade
process. The following exceptions may be thrown when a
replication group node is restarted during the upgrade, and a
ReplicatedEnvironment object is instantiated:
</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>
<a class="ulink" href="../java/com/sleepycat/je/rep/RollbackException.html" target="_top">RollbackException</a>
</p>
<p>
This exception can be thrown by a Replica when its log
is ahead of the current Master and the Replica is
unable to rollback without a recovery. As a
consequence, one or more of the most recently committed
transactions may need to be rolled back, before the
Replica can synchronize its state with that of the
current Master. This exception can also be thrown if
the current Master crashes. To solve this exception
restart the ReplicatedEnvironment with the new JE
version.
</p>
</li>
<li>
<p>
<a class="ulink" href="../java/com/sleepycat/je/rep/RollbackProhibitedException.html" target="_top">RollbackProhibitedException</a>
</p>
<p>
During synchronization, a Replica that has a newer log,
may have to roll back a number of committed
tranactions. If the number of rolled back transactions
exceeds the limit defined by <a class="ulink" href="../java/com/sleepycat/je/rep/ReplicationConfig.html#TXN_ROLLBACK_LIMIT" target="_top">TXN_ROLLBACK_LIMIT</a>, the
Replica throws a RollbackProhibitedException. To solve
this exception you may have to truncate logs manually
by using DbTruncateLog and restart the
ReplicatedEnvironment with the new JE version.
</p>
</li>
<li>
<p>
<a class="ulink" href="../java/com/sleepycat/je/EnvironmentFailureException.html" target="_top">EnvironmentFailureException</a>
</p>
<p>
EnvironmentFailureException is thrown due to log
version incompatibility between the Master and the
Replica. This exception is thrown with the message:
</p>
<p>
"Incompatible log versions. Feeder log version: xxxx,
Feeder JE version: xxxx, Replica log version: xxxx,
Replica JE version: xxxx".
</p>
<p>
To solve this exception restart the
ReplicatedEnvironment with the new JE version.
</p>
</li>
</ul>
</div>
</div>
</div>
<div class="navfooter">
<hr />
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left"><a accesskey="p" href="addremovenodes.html">Prev</a> </td>
<td width="20%" align="center">
<a accesskey="u" href="administration.html">Up</a>
</td>
<td width="40%" align="right"> <a accesskey="n" href="groupreset.html">Next</a></td>
</tr>
<tr>
<td width="40%" align="left" valign="top">Adding and Removing Nodes </td>
<td width="20%" align="center">
<a accesskey="h" href="index.html">Home</a>
</td>
<td width="40%" align="right" valign="top"> Resetting a Replication Group</td>
</tr>
</table>
</div>
</body>
</html>