189 lines
11 KiB
HTML
189 lines
11 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="concept" />
|
|
<meta name="DC.Title" content="Example: Merge" />
|
|
<meta name="abstract" content="Merge operations can occur in several different situations." />
|
|
<meta name="description" content="Merge operations can occur in several different situations." />
|
|
<meta name="DC.Relation" scheme="URI" content="rzaigconceptsmerge.htm" />
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 1998, 2006" />
|
|
<meta name="DC.Format" content="XHTML" />
|
|
<meta name="DC.Identifier" content="rzaigconceptsmergeexample" />
|
|
<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>Example: Merge</title>
|
|
</head>
|
|
<body id="rzaigconceptsmergeexample"><a name="rzaigconceptsmergeexample"><!-- --></a>
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
|
<h1 class="topictitle1">Example: Merge</h1>
|
|
<div><p>Merge operations can occur in several different situations.</p>
|
|
<p>A merge operation can occur with one of the following configurations:</p>
|
|
|
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><caption>Table 1. Merge between a primary and secondary partition</caption><thead align="left"><tr><th colspan="2" align="center" valign="top" id="d0e22">merge</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody><tr><td valign="top" headers="d0e22 ">primary partition</td>
|
|
<td valign="top" headers="d0e22 ">secondary partition</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><caption>Table 2. Merge between a secondary and secondary partition</caption><thead align="left"><tr><th colspan="2" align="center" valign="top" id="d0e38">merge</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody><tr><td valign="top" headers="d0e38 ">secondary partition</td>
|
|
<td valign="top" headers="d0e38 ">secondary partition</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
<p>Primary and secondary partitions are unique to cluster resource groups
|
|
(CRG). For a primary-backup CRG, a primary partition is defined as the partition
|
|
that contains the node identified as the primary access point. A secondary
|
|
partition is defined as a partition that does not contain the node identified
|
|
as the primary access point.</p>
|
|
<p><img src="./delta.gif" alt="Start of change" />For peer CRG, if the recovery domain nodes are fully contained
|
|
within one partition, it will be the primary partition. If the recovery domain
|
|
nodes span a partition, there will be no primary partition. Both partitions
|
|
will be secondary partitions. <img src="./deltaend.gif" alt="End of change" /></p>
|
|
<p><img src="./delta.gif" alt="Start of change" />In the case of a cluster administrative domain, if the domain
|
|
is partitioned into two or more partitions, then each partition will continue
|
|
to operate as a single group. Change to resources will continue to be synchronized
|
|
within each partition. When the partitions are merged back together, the system
|
|
will synchronize the changes from each partition. The end result is that the
|
|
monitored resources will be consistent across the domain. You cannot add or
|
|
remove MREs while the cluster administrative domain is partitioned.<img src="./deltaend.gif" alt="End of change" /></p>
|
|
|
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><caption>Table 3. Merge between a primary and secondary partition</caption><thead align="left"><tr><th colspan="4" align="center" valign="top" id="d0e62">merge operation</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody><tr><td colspan="2" align="center" valign="top" headers="d0e62 ">primary partition</td>
|
|
<td colspan="2" align="center" valign="top" headers="d0e62 ">secondary partition</td>
|
|
</tr>
|
|
<tr><td valign="top" headers="d0e62 ">contains copy of CRG</td>
|
|
<td valign="top" headers="d0e62 ">does NOT contain copy of CRG</td>
|
|
<td valign="top" headers="d0e62 ">contains copy of CRG</td>
|
|
<td valign="top" headers="d0e62 ">does NOT contain copy of CRG</td>
|
|
</tr>
|
|
<tr><td valign="top" headers="d0e62 ">(1)</td>
|
|
<td valign="top" headers="d0e62 ">(2)</td>
|
|
<td valign="top" headers="d0e62 ">(3)</td>
|
|
<td valign="top" headers="d0e62 ">(4)</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
<p> During a primary secondary merge as shown in the diagram above, the following
|
|
situations are possible:</p>
|
|
<ol><li>1 and 3</li>
|
|
<li>1 and 4</li>
|
|
<li>2 and 3 (Cannot happen since a majority partition has the primary node
|
|
active and must have a copy of the CRG.)</li>
|
|
<li>2 and 4 (Cannot happen since a majority partition has the primary node
|
|
active and must have a copy of the CRG.)</li>
|
|
</ol>
|
|
<div class="section"><h4 class="sectiontitle">Primary-secondary merge situations</h4><p>A copy of the
|
|
CRG object is sent to all nodes in the secondary partition. The following
|
|
actions can result on the nodes in the secondary partition:</p>
|
|
<ul><li>No action since the secondary node is not in the CRG's recovery domain.</li>
|
|
<li>A secondary node's copy of the CRG is updated with the data from the primary
|
|
partition.</li>
|
|
<li>The CRG object is deleted from a secondary node since the secondary node
|
|
is no longer in the CRG's recovery domain.</li>
|
|
<li>The CRG object is created on the secondary node since the object does
|
|
not exist. However, the node is in the recovery domain of the CRG copy that
|
|
is sent from the primary partition.</li>
|
|
</ul>
|
|
|
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><caption>Table 4. Secondary and secondary merge scenario</caption><thead align="left"><tr><th colspan="4" align="center" valign="top" id="d0e123">merge operation</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody><tr><td colspan="2" align="center" valign="top" headers="d0e123 ">secondary partition</td>
|
|
<td colspan="2" align="center" valign="top" headers="d0e123 ">secondary partition</td>
|
|
</tr>
|
|
<tr><td valign="top" headers="d0e123 ">contains copy of CRG</td>
|
|
<td valign="top" headers="d0e123 ">does NOT contain copy of CRG</td>
|
|
<td valign="top" headers="d0e123 ">contains copy of CRG</td>
|
|
<td valign="top" headers="d0e123 ">does NOT contain copy of CRG</td>
|
|
</tr>
|
|
<tr><td valign="top" headers="d0e123 ">(1)</td>
|
|
<td valign="top" headers="d0e123 ">(2)</td>
|
|
<td valign="top" headers="d0e123 ">(3)</td>
|
|
<td valign="top" headers="d0e123 ">(4)</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
<p> During a secondary-secondary merge as shown in the diagram above,
|
|
the following situations are possible:</p>
|
|
<ol><li>1 and 3</li>
|
|
<li>1 and 4</li>
|
|
<li>2 and 3</li>
|
|
<li>2 and 4</li>
|
|
</ol>
|
|
</div>
|
|
<div class="section"><h4 class="sectiontitle">Secondary-secondary merge situation 1</h4><p><img src="./delta.gif" alt="Start of change" />For
|
|
a primary-backup CRG, the node with the most recent change to the CRG is selected
|
|
to send a copy of the CRG object to all nodes in the other partition. If multiple
|
|
nodes are selected because they all appear to have the most recent change,
|
|
the recovery domain order is used to select the node. <img src="./deltaend.gif" alt="End of change" /></p>
|
|
<p><img src="./delta.gif" alt="Start of change" />When
|
|
merging two secondary partitions for peer CRG, the version of the peer CRG
|
|
with Active status will copied to other nodes in the other partition. If both
|
|
partitions have the same status for peer CRG, the partition which contains
|
|
the first node listed in the cluster resource group recovery domain will be
|
|
copied to nodes in another partition.<img src="./deltaend.gif" alt="End of change" /></p>
|
|
<p><img src="./delta.gif" alt="Start of change" />The
|
|
following actions can occur on the receiving partition nodes in either a primary-backup
|
|
CRG or a peer CRG:<img src="./deltaend.gif" alt="End of change" /></p>
|
|
<ul><li>No action since the node is not the CRG's recovery domain.</li>
|
|
<li>The CRG is created on the node since the node is in the recovery domain
|
|
of the copy of the CRG object it receives.</li>
|
|
<li>The CRG is deleted from the node since the node is not in the recovery
|
|
domain of the copy of the CRG object it receives.</li>
|
|
</ul>
|
|
</div>
|
|
<div class="section"><h4 class="sectiontitle">Secondary-secondary merge situations 2 and 3</h4><p>A node
|
|
from the partition which has a copy of the CRG object is selected to send
|
|
the object data to all nodes in the other partition. The CRG object may be
|
|
created on nodes in the receiving partition if the node is in the CRG's recovery
|
|
domain.</p>
|
|
</div>
|
|
<div class="section"><h4 class="sectiontitle">Secondary-secondary merge situation 4</h4><p>Internal data
|
|
is exchanged to ensure consistency throughout the cluster.</p>
|
|
<p>A primary
|
|
partition can subsequently be partitioned into a primary and secondary partition.
|
|
If the primary node fails, Cluster Resource Service (CRS) detects it as a
|
|
node failure. The primary partition becomes a secondary partition. The same
|
|
result occurs if you ended the primary node that uses the End Cluster Node
|
|
API. A secondary partition can become a primary partition if the primary node
|
|
becomes active in the partition either through a rejoin or merge operation.</p>
|
|
<p>For
|
|
a merge operation, the exit program is called on all nodes in the CRG's recovery
|
|
domain regardless of which partition the node is in. The same action code
|
|
as rejoin is used. No roles are changed as a result of the merge, but the
|
|
membership status of the nodes in the CRG's recovery domain is changed from <var class="varname">partition</var> to <var class="varname">active</var>.
|
|
Once all partitions merge together, the partition condition is cleared, and
|
|
all CRG API's can be used.</p>
|
|
</div>
|
|
</div>
|
|
<div>
|
|
<div class="familylinks">
|
|
<div class="parentlink"><strong>Parent topic:</strong> <img src="./delta.gif" alt="Start of change" /><a href="rzaigconceptsmerge.htm" title="A merge operation is similar to a rejoin operation except that it occurs when nodes that are partitioned begin communicating again.">Merge</a><img src="./deltaend.gif" alt="End of change" /></div>
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html> |