Update HA documentation
* Update HA documentation
Mirrors must reside on different storage systems too.
Master fail-over must be triggered externally.
10-Gb Ethernet is optional.
segment becomes unavailable. Mirroring is strongly recommended for production systems<ph
otherprops="pivotal"> and required for Pivotal support</ph>. </p>
<p>The secondary (mirror) segment must always reside on a different host than its primary
- segment to protect against a single host failure. Mirror segments can be arranged over the
- remaining hosts in the cluster in configurations designed to maximize availability or
- minimize the performance degradation when hosts or multiple primary segments fail. </p>
+ segment to protect against a single host failure. In virtualized environments, the
+ secondary (mirror) must always reside on a different storage system than the master.
+ Mirror segments can be arranged over the remaining hosts in the cluster in configurations
+ designed to maximize availability, or minimize the performance degradation when hosts or
+ multiple primary segments fail. </p>
<p>Two standard mirroring configurations are available when you initialize or expand a
Greenplum system. The default configuration, called <i>group mirroring</i>, places all the
mirrors for a host's primary segments on one other host in the cluster. The other standard
<p>If the master cannot connect to a segment instance, it marks that segment instance as down
in the Greenplum Database system catalog and brings up the mirror segment in its place. A
failed segment instance will remain out of operation until an administrator takes steps to
- bring that segment back online. An administrator can recover a failed segment while the
- system is up and running. The recovery process copies over only the changes that were missed
- while the segment was out of operation.</p>
+ bring that segment back online. The <codeph><xref href="../../utility_guide/admin_utilities/gpstate.xml#topic1"
+ type="topic" format="dita"/></codeph> utility can be used to identify failed segments.
+ An administrator can recover a failed segment while the system is up and running. The
+ recovery process copies over only the changes that were missed while the segment was out
+ of operation.</p>
<p>If you do not have mirroring enabled, the system will automatically shut down if a segment
instance becomes invalid. You must recover all failed segments before operations can
continue.</p>
to date by a transaction log replication process, which runs on the standby master host and
synchronizes the data between the primary and standby master hosts.</p>
<p>If the primary master fails, the log replication process stops, and the standby master can
- be activated in its place. Upon activation of the standby master, the replicated logs are
+ be activated in its place. The switchover does not happen automatically, but must be triggered
+ externally. Upon activation of the standby master, the replicated logs are
used to reconstruct the state of the master host at the time of the last successfully
committed transaction. The activated standby master effectively becomes the Greenplum
Database master, accepting client connections on the master port (which must be set to the
<title id="iw157609">About Interconnect Redundancy</title>
<p>The <i>interconnect</i> refers to the inter-process communication between the segments and
the network infrastructure on which this communication relies. You can achieve a highly
- available interconnect using by deploying dual 10-Gigabit Ethernet switches on your network
- and redundant 10-Gigabit connections to the Greenplum Database host (master and segment)
- servers. </p>
+ available interconnect using by deploying dual Gigabit Ethernet switches on your network
+ and redundant Gigabit connections to the Greenplum Database host (master and segment)
+ servers. For performance reasons, 10-Gb Ethernet, or faster, is recommended. </p>
</section>
</body>
</topic>
