<commit_before><?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE topic
  PUBLIC "-//OASIS//DTD DITA Composite//EN" "ditabase.dtd">
<topic id="topic1">
  <title id="mb20941">gprecoverseg</title>
  <body>
    <p>Recovers a primary or mirror segment instance that has been marked as down (if mirroring is
      enabled).</p>
    <section id="section2">
      <title>Synopsis</title>
      <codeblock><b>gprecoverseg</b> [[<b>-p</b> <varname>new_recover_host</varname>[,...]] | <b>-i</b> <varname>recover_config_file</varname>] [<b>-d</b> <varname>coordinator_data_directory</varname>] 
             [<b>-B</b> <varname>parallel_processes</varname>] [<b>-F</b> [<b>-s</b>]] [<b>-a</b>] [<b>-q</b>] 
	      [<b>--hba-hostnames</b> <varname>boolean</varname>] 
             [<b>--no-progress</b>] [<b>-l</b> <varname>logfile_directory</varname>]

<b>gprecoverseg</b> <b>-r</b> 

<b>gprecoverseg</b> <b>-o</b> <varname>output_recover_config_file</varname> 
             [<b>-p</b> <varname>new_recover_host</varname>[,...]]

<b>gprecoverseg</b> <b>-?</b> | <b>--help</b>

<b>gprecoverseg</b> <b>--version</b></codeblock>
    </section>
    <section id="section3">
      <title>Description</title>
      <p>In a system with mirrors enabled, the <codeph>gprecoverseg</codeph> utility reactivates a
        failed segment instance and identifies the changed database files that require
        resynchronization. Once <codeph>gprecoverseg</codeph> completes this process, the system
        goes into <i>resynchronizing</i> mode until the recovered segment is brought up to date. The
        system is online and fully operational during resynchronization.</p>
      <p>During an incremental recovery (the <codeph>-F</codeph> option is not specified), if
          <codeph>gprecoverseg</codeph> detects a segment instance with mirroring disabled in a
        system with mirrors enabled, the utility reports that mirroring is disabled for the segment,
        does not attempt to recover that segment instance, and continues the recovery process. </p>
      <p>A segment instance can fail for several reasons, such as a host failure, network failure,
        or disk failure. When a segment instance fails, its status is marked as <i>down</i> in the
        Greenplum Database system catalog, and its mirror is activated in <i>change tracking</i>
        mode. In order to bring the failed segment instance back into operation again, you must
        first correct the problem that made it fail in the first place, and then recover the segment
        instance in Greenplum Database using <codeph>gprecoverseg</codeph>.</p>
      <note otherprops="pivotal"> If incremental recovery was not successful and the down segment
        instance data is not corrupted, contact VMware Support. </note>
      <p>Segment recovery using <codeph>gprecoverseg</codeph> requires that you have an active
        mirror to recover from. For systems that do not have mirroring enabled, or in the event of a
        double fault (a primary and mirror pair both down at the same time) — you must take manual
        steps to recover the failed segment instances and then perform a system restart to bring the
        segments back online. For example, this command restarts a system.</p>
      <codeblock>gpstop -r</codeblock>
      <p>By default, a failed segment is recovered in place, meaning that the system brings the
        segment back online on the same host and data directory location on which it was originally
        configured. In this case, use the following format for the recovery configuration file
        (using <codeph>-i</codeph>).</p>
      <codeblock>&lt;failed_host_address&gt;|&lt;port&gt;|&lt;data_directory&gt; </codeblock>
      <p>In some cases, this may not be possible (for example, if a host was physically damaged and
        cannot be recovered). In this situation, <codeph>gprecoverseg</codeph> allows you to recover
        failed segments to a completely new host (using <codeph>-p</codeph>), on an alternative data
        directory location on your remaining live segment hosts (using <codeph>-s</codeph>), or by
        supplying a recovery configuration file (using <codeph>-i</codeph>) in the following format.
        The word <b>SPACE</b> indicates the location of a required space. Do not add additional
        spaces.</p>
      <codeblock>&lt;failed_host_address&gt;|&lt;port&gt;|&lt;data_directory&gt;<b>SPACE</b>
&lt;recovery_host_address&gt;|&lt;port&gt;|&lt;data_directory&gt;
</codeblock>
      <p>See the <codeph>-i</codeph> option below for details and examples of a recovery
        configuration file.</p>
      <p>The <codeph>gp_segment_configuration</codeph> system catalog table can help you determine
        your current segment configuration so that you can plan your mirror recovery configuration.
        For example, run the following query:</p>
      <codeblock>=# SELECT dbid, content, address, port, datadir 
   FROM gp_segment_configuration
   ORDER BY dbid;</codeblock>
      <p>The new recovery segment host must be pre-installed with the Greenplum Database software
        and configured exactly the same as the existing segment hosts. A spare data directory
        location must exist on all currently configured segment hosts and have enough disk space to
        accommodate the failed segments.</p>
      <p>The recovery process marks the segment as up again in the Greenplum Database system
        catalog, and then initiates the resynchronization process to bring the transactional state
        of the segment up-to-date with the latest changes. The system is online and available during
        resynchronization. </p>
    </section>
    <section id="section4">
      <title>Options</title>
      <parml>
        <plentry>
          <pt>-a (do not prompt)</pt>
          <pd>Do not prompt the user for confirmation.</pd>
        </plentry>
        <plentry>
          <pt>-B <varname>parallel_processes</varname></pt>
          <pd>The number of segments to recover in parallel. If not specified, the utility will
            start up to 16 parallel processes depending on how many segment instances it needs to
            recover.</pd>
        </plentry>
        <plentry>
          <pt>-d <varname>coordinator_data_directory</varname></pt>
          <pd>Optional. The coordinator host data directory. If not specified, the value set for
              <codeph>$COORDINATOR_DATA_DIRECTORY</codeph> will be used.</pd>
        </plentry>
        <plentry>
          <pt>-F (full recovery)</pt>
          <pd>Optional. Perform a full copy of the active segment instance in order to recover the
            failed segment. The default is to only copy over the incremental changes that occurred
            while the segment was down.
            <note type="warning">A full recovery deletes the data directory of the down segment
              instance before copying the data from the active (current primary) segment instance.
              Before performing a full recovery, ensure that the segment failure did not cause data
              corruption and that any host segment disk issues have been fixed.<p>Also, for a full
                recovery, the utility does not restore custom files that are stored in the segment
                instance data directory even if the custom files are also in the active segment
                instance. You must restore the custom files manually. For example, when using the
                  <codeph>gpfdists</codeph> protocol (<codeph>gpfdist</codeph> with SSL encryption)
                to manage external data, client certificate files are required in the segment
                instance <codeph>$PGDATA/gpfdists</codeph> directory. These files are not restored.
                For information about configuring <codeph>gpfdists</codeph>, see <xref
                  href="../../security-guide/topics/Encryption.xml#gpfdist_connections"
              />.</p></note></pd>
          <pd>Full recovery can take a long time for large databases, so
              <codeph>gprecoverseg</codeph> displays a running estimate of the completion progress
            of the copy for each segment. Progress for each segment is updated once per second,
            using ANSI escape codes to update the line for each segment in-place. If you are
            redirecting the <codeph>gprecoverseg</codeph> output to a file, or if the ANSI escape
            codes do not work correctly on your terminal, you can include the <codeph>-s</codeph>
            option on the command line to omit the ANSI escape codes. This outputs a new line once
            per second for each segment. Include the <codeph>--no-progress</codeph> option to
            completely disable the progress reports.</pd>
        </plentry>
        <plentry>
          <pt>--hba-hostnames <varname>boolean</varname></pt>
          <pd>Optional. Controls whether this utility uses IP addresses or host names in the
              <codeph>pg_hba.conf</codeph> file when updating this file with addresses that can
            connect to Greenplum Database. When set to 0 -- the default value -- this utility uses
            IP addresses when updating this file. When set to 1, this utility uses host names when
            updating this file. For consistency, use the same value that was specified for
              <codeph>HBA_HOSTNAMES</codeph> when the Greenplum Database system was initialized. For
            information about how Greenplum Database resolves host names in the
              <codeph>pg_hba.conf</codeph> file, see <xref href="../../admin_guide/client_auth.xml"
            />.</pd>
        </plentry>
        <plentry>
          <pt>-i <varname>recover_config_file</varname></pt>
          <pd>Specifies the name of a file with the details about failed segments to recover. Each
            line in the file is in the following format. The word <b>SPACE</b> indicates the
            location of a required space. Do not add additional
                spaces.<codeblock>&lt;failed_host_address&gt;|&lt;port&gt;|&lt;data_directory&gt;<b>SPACE</b> 
&lt;recovery_host_address&gt;|&lt;port&gt;|&lt;data_directory&gt;
</codeblock><p><b>Comments</b></p><p>Lines
              beginning with <codeph>#</codeph> are treated as comments and ignored.</p>
            <p><b>Segments to Recover</b></p><p>Each line after the first specifies a segment to
              recover. This line can have one of two formats. In the event of in-place recovery,
              enter one group of colon delimited fields in the line. For example:</p><p>
              <codeblock>failedAddress|failedPort|failedDataDirectory</codeblock>
            </p><p>For recovery to a new location, enter two groups of fields separated by a space
              in the line. The required space is indicated by <b>SPACE</b>. Do not add additional
              spaces.</p><p>
              <codeblock>failedAddress|failedPort|failedDataDirectory<b>SPACE</b>newAddress|
newPort|newDataDirectory</codeblock>
            </p><p><b>Examples</b></p><p><b>In-place recovery of a single mirror</b></p>
            <codeblock>sdw1-1|50001|/data1/mirror/gpseg16</codeblock>
            <p><b>Recovery of a single mirror to a new host</b></p>
            <codeblock>sdw1-1|50001|/data1/mirror/gpseg16<b>SPACE</b>sdw4-1|50001|/data1/recover1/gpseg16</codeblock>
            <p><b>Obtaining a Sample File</b></p>
            <p>You can use the <codeph>-o</codeph> option to output a sample recovery configuration
              file to use as a starting point.</p></pd>
        </plentry>
        <plentry>
          <pt>-l <varname>logfile_directory</varname></pt>
          <pd>The directory to write the log file. Defaults to <codeph>~/gpAdminLogs</codeph>.</pd>
        </plentry>
        <plentry>
          <pt>-o <varname>output_recover_config_file</varname></pt>
          <pd>Specifies a file name and location to output a sample recovery configuration file. The
            output file lists the currently invalid segments and their default recovery location in
            the format that is required by the <codeph>-i</codeph> option. Use together with the
              <codeph>-p</codeph> option to output a sample file for recovering on a different host.
            This file can be edited to supply alternate recovery locations if needed. The following
            example outputs the default recovery configuration file:
            <codeblock>$ gprecoverseg -o /home/gpadmin/recover_config_file</codeblock></pd>
        </plentry>
        <plentry>
          <pt>-p <varname>new_recover_host</varname>[,...]</pt>
          <pd>Specifies a spare host outside of the currently configured Greenplum Database array on
            which to recover invalid segments. In the case of multiple failed segment hosts, you can
            specify a comma-separated list. The spare host must have the Greenplum Database software
            installed and configured, and have the same hardware and OS configuration as the current
            segment hosts (same OS version, locales, <codeph>gpadmin</codeph> user account, data
            directory locations created, ssh keys exchanged, number of network interfaces, network
            interface naming convention, and so on.).</pd>
        </plentry><commit_msg>Docs: modified gprecoverseg -p utility guide (#11814)<commit_after><?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE topic
  PUBLIC "-//OASIS//DTD DITA Composite//EN" "ditabase.dtd">
<topic id="topic1">
  <title id="mb20941">gprecoverseg</title>
  <body>
    <p>Recovers a primary or mirror segment instance that has been marked as down (if mirroring is
      enabled).</p>
    <section id="section2">
      <title>Synopsis</title>
      <codeblock><b>gprecoverseg</b> [[<b>-p</b> <varname>new_recover_host</varname>[,...]] | <b>-i</b> <varname>recover_config_file</varname>] [<b>-d</b> <varname>master_data_directory</varname>] 
             [<b>-B</b> <varname>parallel_processes</varname>] [<b>-F</b> [<b>-s</b>]] [<b>-a</b>] [<b>-q</b>] 
	      [<b>--hba-hostnames</b> <varname>boolean</varname>] 
             [<b>--no-progress</b>] [<b>-l</b> <varname>logfile_directory</varname>]

<b>gprecoverseg</b> <b>-r</b> 

<b>gprecoverseg</b> <b>-o</b> <varname>output_recover_config_file</varname> 
             [<b>-p</b> <varname>new_recover_host</varname>[,...]]

<b>gprecoverseg</b> <b>-?</b> | <b>--help</b>

<b>gprecoverseg</b> <b>--version</b></codeblock>
    </section>
    <section id="section3"><title>Description</title>In a system with mirrors enabled, the
        <codeph>gprecoverseg</codeph> utility reactivates a failed segment instance and identifies
      the changed database files that require resynchronization. Once <codeph>gprecoverseg</codeph>
      completes this process, the system goes into <i>resynchronizing</i> mode until the recovered
      segment is brought up to date. The system is online and fully operational during
        resynchronization.<p>During an incremental recovery (the <codeph>-F</codeph> option is not
        specified), if <codeph>gprecoverseg</codeph> detects a segment instance with mirroring
        disabled in a system with mirrors enabled, the utility reports that mirroring is disabled
        for the segment, does not attempt to recover that segment instance, and continues the
        recovery process. </p><p>A segment instance can fail for several reasons, such as a host
        failure, network failure, or disk failure. When a segment instance fails, its status is
        marked as <i>down</i> in the Greenplum Database system catalog, and its mirror is activated
        in <i>change tracking</i> mode. In order to bring the failed segment instance back into
        operation again, you must first correct the problem that made it fail in the first place,
        and then recover the segment instance in Greenplum Database using
          <codeph>gprecoverseg</codeph>.</p><note otherprops="pivotal"> If incremental recovery was
        not successful and the down segment instance data is not corrupted, contact VMware Support.
        </note><p>Segment recovery using <codeph>gprecoverseg</codeph> requires that you have an
        active mirror to recover from. For systems that do not have mirroring enabled, or in the
        event of a double fault (a primary and mirror pair both down at the same time) — you must
        take manual steps to recover the failed segment instances and then perform a system restart
        to bring the segments back online. For example, this command restarts a
        system.</p><codeblock>gpstop -r</codeblock><p>By default, a failed segment is recovered in
        place, meaning that the system brings the segment back online on the same host and data
        directory location on which it was originally configured. In this case, use the following
        format for the recovery configuration file (using
        <codeph>-i</codeph>).</p><codeblock>&lt;failed_host_address&gt;|&lt;port&gt;|&lt;data_directory&gt; </codeblock><p>In
        some cases, this may not be possible (for example, if a host was physically damaged and
        cannot be recovered). In this situation, <codeph>gprecoverseg</codeph> allows you to recover
        failed segments to a completely new host (using <codeph>-p</codeph>), on an alternative data
        directory location on your remaining live segment hosts (using <codeph>-s</codeph>), or by
        supplying a recovery configuration file (using <codeph>-i</codeph>) in the following format.
        The word <b>SPACE</b> indicates the location of a required space. Do not add additional
        spaces.</p><codeblock>&lt;failed_host_address&gt;|&lt;port&gt;|&lt;data_directory&gt;<b>SPACE</b>
&lt;recovery_host_address&gt;|&lt;port&gt;|&lt;data_directory&gt;
</codeblock><p>See
        the <codeph>-i</codeph> option below for details and examples of a recovery configuration
        file.</p><p>The <codeph>gp_segment_configuration</codeph> system catalog table can help you
        determine your current segment configuration so that you can plan your mirror recovery
        configuration. For example, run the following
        query:</p><codeblock>=# SELECT dbid, content, address, port, datadir 
   FROM gp_segment_configuration
   ORDER BY dbid;</codeblock><p>The
        new recovery segment host must be pre-installed with the Greenplum Database software and
        configured exactly the same as the existing segment hosts. A spare data directory location
        must exist on all currently configured segment hosts and have enough disk space to
        accommodate the failed segments.</p><p>The recovery process marks the segment as up again in
        the Greenplum Database system catalog, and then initiates the resynchronization process to
        bring the transactional state of the segment up-to-date with the latest changes. The system
        is online and available during resynchronization. </p></section>
    <section id="section4">
      <title>Options</title>
      <parml>
        <plentry>
          <pt>-a (do not prompt)</pt>
          <pd>Do not prompt the user for confirmation.</pd>
        </plentry>
        <plentry>
          <pt>-B <varname>parallel_processes</varname></pt>
          <pd>The number of segments to recover in parallel. If not specified, the utility will
            start up to 16 parallel processes depending on how many segment instances it needs to
            recover.</pd>
        </plentry>
        <plentry>
          <pt>-d <varname>master_data_directory</varname></pt>
          <pd>Optional. The master host data directory. If not specified, the value set for
              <codeph>$MASTER_DATA_DIRECTORY</codeph> will be used.</pd>
        </plentry>
        <plentry>
          <pt>-F (full recovery)</pt>
          <pd>Optional. Perform a full copy of the active segment instance in order to recover the
            failed segment. The default is to only copy over the incremental changes that occurred
            while the segment was down.
            <note type="warning">A full recovery deletes the data directory of the down segment
              instance before copying the data from the active (current primary) segment instance.
              Before performing a full recovery, ensure that the segment failure did not cause data
              corruption and that any host segment disk issues have been fixed.<p>Also, for a full
                recovery, the utility does not restore custom files that are stored in the segment
                instance data directory even if the custom files are also in the active segment
                instance. You must restore the custom files manually. For example, when using the
                  <codeph>gpfdists</codeph> protocol (<codeph>gpfdist</codeph> with SSL encryption)
                to manage external data, client certificate files are required in the segment
                instance <codeph>$PGDATA/gpfdists</codeph> directory. These files are not restored.
                For information about configuring <codeph>gpfdists</codeph>, see <xref
                  href="../../security-guide/topics/Encryption.xml#gpfdist_connections"
              />.</p></note></pd>
          <pd>Full recovery can take a long time for large databases, so
              <codeph>gprecoverseg</codeph> displays a running estimate of the completion progress
            of the copy for each segment. Progress for each segment is updated once per second,
            using ANSI escape codes to update the line for each segment in-place. If you are
            redirecting the <codeph>gprecoverseg</codeph> output to a file, or if the ANSI escape
            codes do not work correctly on your terminal, you can include the <codeph>-s</codeph>
            option on the command line to omit the ANSI escape codes. This outputs a new line once
            per second for each segment. Include the <codeph>--no-progress</codeph> option to
            completely disable the progress reports.</pd>
        </plentry>
        <plentry>
          <pt>--hba-hostnames <varname>boolean</varname></pt>
          <pd>Optional. Controls whether this utility uses IP addresses or host names in the
              <codeph>pg_hba.conf</codeph> file when updating this file with addresses that can
            connect to Greenplum Database. When set to 0 -- the default value -- this utility uses
            IP addresses when updating this file. When set to 1, this utility uses host names when
            updating this file. For consistency, use the same value that was specified for
              <codeph>HBA_HOSTNAMES</codeph> when the Greenplum Database system was initialized. For
            information about how Greenplum Database resolves host names in the
              <codeph>pg_hba.conf</codeph> file, see <xref href="../../admin_guide/client_auth.xml"
            />.</pd>
        </plentry>
        <plentry>
          <pt>-i <varname>recover_config_file</varname></pt>
          <pd>Specifies the name of a file with the details about failed segments to recover. Each
            line in the file is in the following format. The word <b>SPACE</b> indicates the
            location of a required space. Do not add additional
                spaces.<codeblock>&lt;failed_host_address&gt;|&lt;port&gt;|&lt;data_directory&gt;<b>SPACE</b> 
&lt;recovery_host_address&gt;|&lt;port&gt;|&lt;data_directory&gt;
</codeblock><p><b>Comments</b></p><p>Lines
              beginning with <codeph>#</codeph> are treated as comments and ignored.</p>
            <p><b>Segments to Recover</b></p><p>Each line after the first specifies a segment to
              recover. This line can have one of two formats. In the event of in-place recovery,
              enter one group of colon delimited fields in the line. For example:</p><p>
              <codeblock>failedAddress|failedPort|failedDataDirectory</codeblock>
            </p><p>For recovery to a new location, enter two groups of fields separated by a space
              in the line. The required space is indicated by <b>SPACE</b>. Do not add additional
              spaces.</p><p>
              <codeblock>failedAddress|failedPort|failedDataDirectory<b>SPACE</b>newAddress|
newPort|newDataDirectory</codeblock>
            </p><p><b>Examples</b></p><p><b>In-place recovery of a single mirror</b></p>
            <codeblock>sdw1-1|50001|/data1/mirror/gpseg16</codeblock>
            <p><b>Recovery of a single mirror to a new host</b></p>
            <codeblock>sdw1-1|50001|/data1/mirror/gpseg16<b>SPACE</b>sdw4-1|50001|/data1/recover1/gpseg16</codeblock>
            <p><b>Obtaining a Sample File</b></p>
            <p>You can use the <codeph>-o</codeph> option to output a sample recovery configuration
              file to use as a starting point.</p></pd>
        </plentry>
        <plentry>
          <pt>-l <varname>logfile_directory</varname></pt>
          <pd>The directory to write the log file. Defaults to <codeph>~/gpAdminLogs</codeph>.</pd>
        </plentry>
        <plentry>
          <pt>-o <varname>output_recover_config_file</varname></pt>
          <pd>Specifies a file name and location to output a sample recovery configuration file. The
            output file lists the currently invalid segments and their default recovery location in
            the format that is required by the <codeph>-i</codeph> option. Use together with the
              <codeph>-p</codeph> option to output a sample file for recovering on a different host.
            This file can be edited to supply alternate recovery locations if needed. The following
            example outputs the default recovery configuration file:
            <codeblock>$ gprecoverseg -o /home/gpadmin/recover_config_file</codeblock></pd>
        </plentry>
        <plentry>
          <pt>-p <varname>new_recover_host</varname>[,...]</pt>
          <pd>Specifies a spare host outside of the currently configured Greenplum Database array on
            which to recover invalid segments.</pd>
          <pd>
            <note type="important">The hostname of the new node needs to match the hostname being
              recovered.</note>
          </pd>
          <pd>The spare host must have the Greenplum Database software installed and configured, and
            have the same hardware and OS configuration as the current segment hosts (same hostname,
            OS version, locales, <codeph>gpadmin</codeph> user account, data directory locations
            created, ssh keys exchanged, number of network interfaces, network interface naming
            convention, and so on). Specifically, the Greenplum Database binaries must be installed,
            the spare host must be able to connect password-less with all segments including the
            Greenplum master, and any other Greenplum Database specific OS configuration parameters
            must be applied.</pd>
          <pd>
            <note>In the case of multiple failed segment hosts, you can specify the hosts to recover
              with a comma-separated list. However, it is strongly recommended to recover one host
              at a time. If you must recover more than one host at a time, then it is critical to
              ensure that a double fault scenario does not occur, in which both the segment primary
              and corresponding mirror are offline.</note>
          </pd>
        </plentry>
{'fraction_non_alphanumeric': 0.09132834628513327, 'fraction_numerical': 0.0035950323189774132, 'mean_word_length': 2.854303708887334, 'pattern_counts': {'":': 0, '<': 647, '<?xml version=': 2, '>': 647, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 6}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '127623', 'n_tokens_mistral': 7452, 'n_tokens_neox': 7203, 'n_words': 2914}