diff --git a/gpdb-doc/dita/admin_guide/expand/expand-nodes.xml b/gpdb-doc/dita/admin_guide/expand/expand-nodes.xml index 6012b480ed10ddb658d7a0971350ad2b4149413a..bd47c9741fbb76444315615f57bb2343efe8a6be 100644 --- a/gpdb-doc/dita/admin_guide/expand/expand-nodes.xml +++ b/gpdb-doc/dita/admin_guide/expand/expand-nodes.xml @@ -13,15 +13,17 @@

Generally, you should run performance tests when an administrator modifies host networking or other special conditions in the system. For example, if you will run the expanded system on two network clusters, run tests on each cluster.

+ Preparing host systems for use by a Greenplum Database system assumes that the new hosts' + operating system has been properly configured to match the existing hosts, described in . Adding New Hosts to the Trusted Host Environment

New hosts must exchange SSH keys with the existing hosts to enable Greenplum administrative utilities to connect to all segments without a password prompt. Perform the key exchange - process twice with the gpssh-exkeys - utility.

+ process twice with the gpssh-exkeys utility.

First perform the process as root, for administration convenience, and then as the user gpadmin, for management utilities. Perform the following tasks in order:

@@ -84,7 +86,7 @@ sdw3-4 To create the <codeph>gpadmin</codeph> user
  1. Use gpssh to create the gpadmin user on all the new + >gpssh to create the gpadmin user on all the new segment hosts (if it does not exist already). Use the list of new hosts you created for the key exchange. For example:# gpssh -f new_hosts_file '/usr/sbin/useradd gpadmin -d @@ -117,7 +119,7 @@ gpadmin --stdin'
    2. Validating Disk I/O and Memory Bandwidth

    Use the gpcheckperf utility to test disk I/O and memory bandwidth.

    + >gpcheckperf utility to test disk I/O and memory bandwidth.

    To run gpcheckperf
      diff --git a/gpdb-doc/dita/admin_guide/expand/expand-planning.xml b/gpdb-doc/dita/admin_guide/expand/expand-planning.xml index d29cd01a464344941f66312523e672023212f101..4475cf17e3d6033c5eaf8a87949e9f4444add997 100644 --- a/gpdb-doc/dita/admin_guide/expand/expand-planning.xml +++ b/gpdb-doc/dita/admin_guide/expand/expand-planning.xml @@ -127,7 +127,7 @@ - Initialize new segments into the array and create an expansion schema + Initialize new segments into the system and create an expansion schema (gpexpand -i input_file). @@ -208,29 +208,26 @@ configuration in the particular site and environment.

      After selecting and adding new hardware to your network environment, ensure you perform the - burn-in tasks described in .

      + tasks described in .

      Planning New Segment Initialization

      Expanding Greenplum Database can be performed when the system is up and available. Run - gpexpand to initialize new segment instances into the array and create an - expansion schema.

      + gpexpand to initialize new segment instances into the system and create + an expansion schema.

      The time required depends on the number of schema objects in the Greenplum system and other factors related to hardware performance. In most environments, the initialization of new segments requires less than thirty minutes offline.

      These utilities cannot be run while gpexpand is performing segment - initialization. -

        + initialization.
        • gpbackup
        • gpcheckcat
        • gpconfig
        • gppkg
        • gprestore

        - After you begin initializing new segments, you can no longer restore the system using backup files created for the pre-expansion system. When initialization successfully completes, the expansion is committed and cannot be rolled back. @@ -241,25 +238,27 @@

        If your existing system has mirror segments, the new segments must have mirroring configured. If there are no mirrors configured for existing segments, you cannot add mirrors to new hosts with the gpexpand utility. For more information - about segment mirroring, see .

        -

        For Greenplum Database arrays with mirror segments, ensure you add enough new host +

        For Greenplum Database systems with mirror segments, ensure you add enough new host machines to accommodate new mirror segments. The number of new hosts required depends on your mirroring strategy:

          -
        • Spread Mirroring — Add at least one more host to the array than +
        • Group Mirroring — Add at least two new hosts so the mirrors for + the first host can reside on the second host, and the mirrors for the second host can + reside on the first. This is the default type of mirroring if you enable segment + mirroring during system initialization.
          • +
        • Spread Mirroring — Add at least one more host to the system than the number of segments per host. The number of separate hosts must be greater than the number of segment instances per host to ensure even spreading. You can specify this type of mirroring during system initialization or when you enable segment mirroring for an existing system.
          • -
        • Grouped Mirroring — Add at least two new hosts so the mirrors for - the first host can reside on the second host, and the mirrors for the second host can - reside on the first. This is the default type of mirroring if you enable segment - mirroring during system initialization.
        • Block Mirroring — Adding one or more blocks of host systems. For example add a block of four or eight hosts. Block mirroring is a custom mirroring configuration. For more information about block mirroring, see in the + href="../../best_practices/ha.xml#topic_ngz_qf4_tt"/> in the Greenplum Database Best Practices Guide.
        @@ -367,7 +366,7 @@

        If your existing hosts have limited disk space, you may prefer to first redistribute smaller tables (such as dimension tables) to clear space to store a copy of the largest table. Available disk space on the original segments increases as each table is - redistributed across the expanded array. When enough free space exists on all segments + redistributed across the expanded system. When enough free space exists on all segments to store a copy of the largest table, you can redistribute large or critical tables. Redistribution of large tables requires exclusive locks; schedule this procedure for off-peak hours.

        diff --git a/gpdb-doc/dita/admin_guide/highavail/topics/g-overview-of-segment-mirroring.xml b/gpdb-doc/dita/admin_guide/highavail/topics/g-overview-of-segment-mirroring.xml index f731f994b3a4f48fa123a8358e18766531cb6357..783933af0aee631a117735653cef936c56ad8cdf 100644 --- a/gpdb-doc/dita/admin_guide/highavail/topics/g-overview-of-segment-mirroring.xml +++ b/gpdb-doc/dita/admin_guide/highavail/topics/g-overview-of-segment-mirroring.xml @@ -12,8 +12,9 @@ unavailable, it changes the role of its mirror segment to primary segment and the role of the unavailable primary segment to mirror segment. Transactions in progress when the failure occurred roll back and must be restarted. The administrator must then recover - the mirror segment, allow the mirror to synchronize with the current primary segment, and - then exchange the primary and mirror segments so they are in their preferred roles.

        + the mirror segment, allow the mirror to synchronize with the current primary segment, + and then exchange the primary and mirror segments so they are in their preferred + roles.

        If segment mirroring is not enabled, the Greenplum Database system shuts down if a segment instance fails. Administrators must manually recover all failed segments before Greenplum Database operations can resume.

        @@ -48,39 +49,47 @@ walsender processes that are used for Greenplum Database master and segment mirroring.

      -
      +
      About Segment Mirroring Configurations

      Mirror segment instances can be placed on hosts in the cluster in different configurations. As a best practice, a primary segment and the corresponding mirror are placed on different hosts. Each host must have the same number of primary and mirror segments. When you create segment mirrors with the Greenplum Database - utilities or - or you can specify the segment mirror configuration, group mirroring (the default) or spread mirroring. With gpaddmirrors, you can create custom mirroring configurations with a gpaddmirrors configuration file and specify the file on the command line.

      -

      Group mirroring is the default mirroring configuration. The mirror segments - for each host's primary segments are placed on one other host. If a single host - fails, the number of active primary segments doubles on the host that backs the - failed host. The diagram - illustrates a group mirroring configuration.

      - +

      Group mirroring is the default mirroring configuration when you enable + mirroring during system initialization. The mirror segments for each host's primary + segments are placed on one other host. If a single host fails, the number of active + primary segments doubles on the host that backs the failed host. illustrates a group mirroring + configuration.

      Group Segment Mirroring in Greenplum Database -

      Spread mirroring spreads each host's mirrors over multiple hosts so that if - any single host fails, no other host will have more than one mirror promoted to an - active primary segment. Spread mirroring is possible only if there are more hosts - than segments per host. The diagram illustrates the placement of mirrors in a spread segment - mirroring configuration.

      +

      Spread mirroring can be specified during system initialization. This + configuration spreads each host's mirrors over multiple hosts so that if any single + host fails, no other host will have more than one mirror promoted to an active + primary segment. Spread mirroring is possible only if there are more hosts than + segments per host. illustrates + the placement of mirrors in a spread segment mirroring configuration.

      Spread Segment Mirroring in Greenplum Database + You must ensure you have the appropriate number of host systems for your mirroring + configuration when you create a system or when you expand a system. For example, to + create a system that is configured with spread mirroring requires more hosts than + segment instances per host, and a system that is configured with group mirroring + requires at least two new hosts when expanding the system. For information about + segment mirroring configurations, see . For information about + expanding systems with segment mirroring enabled, see .

      diff --git a/gpdb-doc/dita/best_practices/ha.xml b/gpdb-doc/dita/best_practices/ha.xml index e37f984085255fd555cd4a3f84a3999b76719b80..6a011726744410739a7d391b7f3b3b8751a85319 100644 --- a/gpdb-doc/dita/best_practices/ha.xml +++ b/gpdb-doc/dita/best_practices/ha.xml @@ -130,11 +130,11 @@ work, so performance can be degraded until the balance is restored by recovering the original primary.

      Administrators perform the recovery while Greenplum Database is up and running by running - the gprecoverseg utility. This utility locates the failed segments, verifies - they are valid, and compares the transactional state with the currently active segment to - determine changes made while the segment was offline. gprecoverseg - synchronizes the changed database files with the active segment and brings the segment back - online.

      + the gprecoverseg utility. This utility locates the failed segments, + verifies they are valid, and compares the transactional state with the currently active + segment to determine changes made while the segment was offline. + gprecoverseg synchronizes the changed database files with the active + segment and brings the segment back online.

      It is important to reserve enough memory and CPU resources on segment hosts to allow for increased activity from mirrors that assume the primary role during a failure. The formulas provided in for configuring @@ -217,16 +217,16 @@

    1. Use the gpbackup command to specify only the schema and - tables that you want backed up. See the gpbackup reference in the Greenplum - Database Utility Reference Guide for more information.

      + tables that you want backed up. See the gpbackup reference for more + information.

    2. -

      gpbackup places SHARED ACCESS locks on the set of tables - to back up. Backups with fewer tables are more efficient for selectively restoring - schemas and tables, since gprestore does not have to search through - the entire database.

      +

      gpbackup places SHARED ACCESS locks on + the set of tables to back up. Backups with fewer tables are more efficient for + selectively restoring schemas and tables, since gprestore does not + have to search through the entire database.

    3. If backups are saved to local cluster storage, move the files to a safe, off-cluster location when the backup is complete. Backup files and database files that @@ -267,19 +267,22 @@
      4. Additional InformationGreenplum Database Administrator Guide:
        -
      • Monitoring a Greenplum System
        • -
      • Recovering a Failed Segment
        • +
        • +

      Greenplum Database Utility Guide:

        -
      • gpstate—view state of the Greenplum system
        • -
      • gprecoverseg—recover a failed segment
        • -
      • gpactivatestandby—make the standby master the active +
      • gpstate - view + state of the Greenplum system
        • +
      • gprecoverseg - recover a failed segment
        • +
      • gpactivatestandby - make the standby master the active master

      RDBMS MIB Specification

       - Segment Mirroring Configuration + Segment Mirroring Configurations

      Segment mirroring allows database queries to fail over to a backup segment if the primary segment fails or becomes unavailable. Pivotal requires mirroring for supported production @@ -309,15 +312,16 @@ mirroring:

      • Group mirroring — Each host mirrors another host's primary segments. This is the default for gpinitsystem and gpaddmirrors.
        • + >gpinitsystem and gpaddmirrors.
      • Spread mirroring — Mirrors are spread across the available hosts. This requires that the number of hosts in the cluster is greater than the number of segments per host.

      -

      You can design a custom mirroring configuration and use the Greenplum gpaddmirrors or - gpaddmirrors - utilities to set up the configuration.

      +

      You can design a custom mirroring configuration and use the Greenplum + gpaddmirrors or gpmovemirrors utilities to + set up the configuration.

      Block mirroring is a custom mirror configuration that divides hosts in the cluster into equally sized blocks and distributes mirrors evenly to hosts within the block. If a primary segment fails, its mirror on another host within the same block becomes the active