tuhaihe commented on code in PR #322:
URL: https://github.com/apache/cloudberry-site/pull/322#discussion_r2464274824
##########
docs/sys-admin/high-availability/check-for-failed-segments.md:
##########
@@ -0,0 +1,59 @@
+---
+title: Check for Failed Segments
+---
+
+# Check for Failed Segments
+
+With mirroring enabled, you can have failed segment instances in the system
without interruption of service or any indication that a failure has occurred.
You can verify the status of your system using the `gpstate` utility, by
examing the contents of the `gp_segment_configuration` catalog table, or by
checking log files.
+
+## Check for failed segments using gpstate
+
+The `gpstate` utility provides the status of each individual component of a
Apache Cloudberry system, including primary segments, mirror segments,
coordinator, and standby coordinator.
+
+On the coordinator host, run the [`gpstate`](../../sys-utilities/gpstate.md)
utility with the `-e` option to show segment instances with error conditions:
+
+```shell
+$ gpstate -e
+```
+
+If the utility lists `Segments with Primary and Mirror Roles Switched`, the
segment is not in its *preferred role* (the role to which it was assigned at
system initialization). This means the system is in a potentially unbalanced
state, as some segment hosts may have more active segments than is optimal for
top system performance.
+
+Segments that display the `Config status` as `Down` indicate the corresponding
mirror segment is down.
+
+See [Recovering from Segment Failures](./recover-from-segment-failures.md) for
instructions to fix this situation.
+
+## Check for failed segments using the gp_segment_configuration table
+
+To get detailed information about failed segments, you can check the
[`gp_segment_configuration`](../../sys-catalogs/sys-tables/gp-segment-configuration.md)
catalog table. For example:
+
+```shell
+$ psql postgres -c "SELECT * FROM gp_segment_configuration WHERE status='d';"
+```
+
+For failed segment instances, note the host, port, preferred role, and data
directory. This information will help determine the host and segment instances
to troubleshoot. To display information about mirror segment instances, run:
+
+```shell
+$ gpstate -m
+```
+
+## Check for failed segments by examining log files
+
+Log files can provide information to help determine an error's cause. The
coordinator and segment instances each have their own log file in `log` of the
data directory. The coordinator log file contains the most information and you
should always check it first.
+
+Use the [`gplogfilter`](../../sys-utilities/gplogfilter.md) utility to check
the Apache Cloudberry log files for additional information. To check the
segment log files, run `gplogfilter` on the segment hosts using
[`gpssh`](../../sys-utilities/gpssh.md).
+
+## To check the log files
+
+1. Use `gplogfilter` to check the coordinator log file for `WARNING`, `ERROR`,
`FATAL` or `PANIC` log level messages:
+
+ ```shell
+ $ gplogfilter -t
+ ```
+
+2. Use `gpssh` to check for `WARNING`, `ERROR`, `FATAL`, or `PANIC` log level
messages on each segment instance. For example:
+
+ ```shell
+ $ gpssh -f seg_hosts_file -e 'source
+ /usr/local/greenplum-db/greenplum_path.sh ; gplogfilter -t
Review Comment:
```suggestion
/usr/local/cloudberry-db/cloudberry-env.sh ; gplogfilter -t
```
##########
docs/sys-admin/expand-cluster/prepare-and-add-hosts.md:
##########
@@ -0,0 +1,132 @@
+---
+title: Prepare and Add Hosts
+---
+
+# Prepare and Add Hosts
+
+Verify your new host systems are ready for integration into the existing
Cloudberry system.
+
+To prepare new host systems for expansion, install the Apache Cloudberry
software binaries, exchange the required SSH keys, and run performance tests.
+
+Run performance tests first on the new hosts and then all hosts. Run the tests
on all hosts with the system offline so user activity does not distort results.
+
+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.
+
+:::note
+Preparing host systems for use by a Apache Cloudberry system assumes that the
new hosts' operating system has been properly configured to match the existing
hosts, described in [Configuring Your
Systems](../../cbdb-op-software-hardware.md#supported-os).
+:::
+
+## Add new hosts to the trusted host environment
+
+New hosts must exchange SSH keys with the existing hosts to enable Cloudberry
administrative utilities to connect to all segments without a password prompt.
Perform the key exchange process twice with the
[gpssh-exkeys](../../sys-utilities/gpssh-exkeys.md) 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:
+
+1. [To exchange SSH keys as root](#to-exchange-ssh-keys-as-root)
+2. [To create the gpadmin user](#to-create-the-gpadmin-user)
+3. [To exchange SSH keys as the gpadmin
user](#to-exchange-ssh-keys-as-the-gpadmin-user)
+
+:::note
+The Apache Cloudberry segment host naming convention is `sdwN` where `sdw` is
a prefix and `N` is an integer ( `sdw1`, `sdw2` and so on). For hosts with
multiple interfaces, the convention is to append a dash (`-`) and number to the
host name. For example, `sdw1-1` and `sdw1-2` are the two interface names for
host `sdw1`.
+:::
+
+### To exchange SSH keys as root
+
+1. Create a host file with the existing host names in your array and a
separate host file with the new expansion host names. For existing hosts, you
can use the same host file used to set up SSH keys in the system. In the files,
list all hosts (coordinator, backup coordinator, and segment hosts) with one
name per line and no extra lines or spaces. Exchange SSH keys using the
configured host names for a given host if you use a multi-NIC configuration. In
this example, `cdw` is configured with a single NIC, and `sdw1`, `sdw2`, and
`sdw3` are configured with 4 NICs:
+
+ ```
+ cdw
+ sdw1-1
+ sdw1-2
+ sdw1-3
+ sdw1-4
+ sdw2-1
+ sdw2-2
+ sdw2-3
+ sdw2-4
+ sdw3-1
+ sdw3-2
+ sdw3-3
+ sdw3-4
+ ```
+
+2. Log in as `root` on the coordinator host, and source the
`greenplum_path.sh` file from your Cloudberry installation.
Review Comment:
```suggestion
2. Log in as `root` on the coordinator host, and source the
`cloudberry-env.sh` file from your Cloudberry installation.
```
##########
versioned_docs/version-2.x/sys-admin/high-availability/check-for-failed-segments.md:
##########
@@ -0,0 +1,59 @@
+---
+title: Check for Failed Segments
+---
+
+# Check for Failed Segments
+
+With mirroring enabled, you can have failed segment instances in the system
without interruption of service or any indication that a failure has occurred.
You can verify the status of your system using the `gpstate` utility, by
examing the contents of the `gp_segment_configuration` catalog table, or by
checking log files.
+
+## Check for failed segments using gpstate
+
+The `gpstate` utility provides the status of each individual component of a
Apache Cloudberry system, including primary segments, mirror segments,
coordinator, and standby coordinator.
+
+On the coordinator host, run the [`gpstate`](../../sys-utilities/gpstate.md)
utility with the `-e` option to show segment instances with error conditions:
+
+```shell
+$ gpstate -e
+```
+
+If the utility lists `Segments with Primary and Mirror Roles Switched`, the
segment is not in its *preferred role* (the role to which it was assigned at
system initialization). This means the system is in a potentially unbalanced
state, as some segment hosts may have more active segments than is optimal for
top system performance.
+
+Segments that display the `Config status` as `Down` indicate the corresponding
mirror segment is down.
+
+See [Recovering from Segment Failures](./recover-from-segment-failures.md) for
instructions to fix this situation.
+
+## Check for failed segments using the gp_segment_configuration table
+
+To get detailed information about failed segments, you can check the
[`gp_segment_configuration`](../../sys-catalogs/sys-tables/gp-segment-configuration.md)
catalog table. For example:
+
+```shell
+$ psql postgres -c "SELECT * FROM gp_segment_configuration WHERE status='d';"
+```
+
+For failed segment instances, note the host, port, preferred role, and data
directory. This information will help determine the host and segment instances
to troubleshoot. To display information about mirror segment instances, run:
+
+```shell
+$ gpstate -m
+```
+
+## Check for failed segments by examining log files
+
+Log files can provide information to help determine an error's cause. The
coordinator and segment instances each have their own log file in `log` of the
data directory. The coordinator log file contains the most information and you
should always check it first.
+
+Use the [`gplogfilter`](../../sys-utilities/gplogfilter.md) utility to check
the Apache Cloudberry log files for additional information. To check the
segment log files, run `gplogfilter` on the segment hosts using
[`gpssh`](../../sys-utilities/gpssh.md).
+
+## To check the log files
+
+1. Use `gplogfilter` to check the coordinator log file for `WARNING`, `ERROR`,
`FATAL` or `PANIC` log level messages:
+
+ ```shell
+ $ gplogfilter -t
+ ```
+
+2. Use `gpssh` to check for `WARNING`, `ERROR`, `FATAL`, or `PANIC` log level
messages on each segment instance. For example:
+
+ ```shell
+ $ gpssh -f seg_hosts_file -e 'source
+ /usr/local/greenplum-db/greenplum_path.sh ; gplogfilter -t
Review Comment:
```suggestion
/usr/local/cloudberry-db/greenplum_path.sh ; gplogfilter -t
```
##########
versioned_docs/version-2.x/sys-admin/expand-cluster/prepare-and-add-hosts.md:
##########
@@ -0,0 +1,132 @@
+---
+title: Prepare and Add Hosts
+---
+
+# Prepare and Add Hosts
+
+Verify your new host systems are ready for integration into the existing
Cloudberry system.
+
+To prepare new host systems for expansion, install the Apache Cloudberry
software binaries, exchange the required SSH keys, and run performance tests.
+
+Run performance tests first on the new hosts and then all hosts. Run the tests
on all hosts with the system offline so user activity does not distort results.
+
+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.
+
+:::note
+Preparing host systems for use by a Apache Cloudberry system assumes that the
new hosts' operating system has been properly configured to match the existing
hosts, described in [Configuring Your
Systems](../../cbdb-op-software-hardware.md#supported-os).
+:::
+
+## Add new hosts to the trusted host environment
+
+New hosts must exchange SSH keys with the existing hosts to enable Cloudberry
administrative utilities to connect to all segments without a password prompt.
Perform the key exchange process twice with the
[gpssh-exkeys](../../sys-utilities/gpssh-exkeys.md) 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:
+
+1. [To exchange SSH keys as root](#to-exchange-ssh-keys-as-root)
+2. [To create the gpadmin user](#to-create-the-gpadmin-user)
+3. [To exchange SSH keys as the gpadmin
user](#to-exchange-ssh-keys-as-the-gpadmin-user)
+
+:::note
+The Apache Cloudberry segment host naming convention is `sdwN` where `sdw` is
a prefix and `N` is an integer ( `sdw1`, `sdw2` and so on). For hosts with
multiple interfaces, the convention is to append a dash (`-`) and number to the
host name. For example, `sdw1-1` and `sdw1-2` are the two interface names for
host `sdw1`.
+:::
+
+### To exchange SSH keys as root
+
+1. Create a host file with the existing host names in your array and a
separate host file with the new expansion host names. For existing hosts, you
can use the same host file used to set up SSH keys in the system. In the files,
list all hosts (coordinator, backup coordinator, and segment hosts) with one
name per line and no extra lines or spaces. Exchange SSH keys using the
configured host names for a given host if you use a multi-NIC configuration. In
this example, `cdw` is configured with a single NIC, and `sdw1`, `sdw2`, and
`sdw3` are configured with 4 NICs:
+
+ ```
+ cdw
+ sdw1-1
+ sdw1-2
+ sdw1-3
+ sdw1-4
+ sdw2-1
+ sdw2-2
+ sdw2-3
+ sdw2-4
+ sdw3-1
+ sdw3-2
+ sdw3-3
+ sdw3-4
+ ```
+
+2. Log in as `root` on the coordinator host, and source the
`greenplum_path.sh` file from your Cloudberry installation.
+
+ ```shell
+ $ su -
+ # source /usr/local/greenplum-db/greenplum_path.sh
Review Comment:
```suggestion
# source /usr/local/cloudberry-db/greenplum_path.sh
```
##########
docs/sys-admin/expand-cluster/prepare-and-add-hosts.md:
##########
@@ -0,0 +1,132 @@
+---
+title: Prepare and Add Hosts
+---
+
+# Prepare and Add Hosts
+
+Verify your new host systems are ready for integration into the existing
Cloudberry system.
+
+To prepare new host systems for expansion, install the Apache Cloudberry
software binaries, exchange the required SSH keys, and run performance tests.
+
+Run performance tests first on the new hosts and then all hosts. Run the tests
on all hosts with the system offline so user activity does not distort results.
+
+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.
+
+:::note
+Preparing host systems for use by a Apache Cloudberry system assumes that the
new hosts' operating system has been properly configured to match the existing
hosts, described in [Configuring Your
Systems](../../cbdb-op-software-hardware.md#supported-os).
+:::
+
+## Add new hosts to the trusted host environment
+
+New hosts must exchange SSH keys with the existing hosts to enable Cloudberry
administrative utilities to connect to all segments without a password prompt.
Perform the key exchange process twice with the
[gpssh-exkeys](../../sys-utilities/gpssh-exkeys.md) 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:
+
+1. [To exchange SSH keys as root](#to-exchange-ssh-keys-as-root)
+2. [To create the gpadmin user](#to-create-the-gpadmin-user)
+3. [To exchange SSH keys as the gpadmin
user](#to-exchange-ssh-keys-as-the-gpadmin-user)
+
+:::note
+The Apache Cloudberry segment host naming convention is `sdwN` where `sdw` is
a prefix and `N` is an integer ( `sdw1`, `sdw2` and so on). For hosts with
multiple interfaces, the convention is to append a dash (`-`) and number to the
host name. For example, `sdw1-1` and `sdw1-2` are the two interface names for
host `sdw1`.
+:::
+
+### To exchange SSH keys as root
+
+1. Create a host file with the existing host names in your array and a
separate host file with the new expansion host names. For existing hosts, you
can use the same host file used to set up SSH keys in the system. In the files,
list all hosts (coordinator, backup coordinator, and segment hosts) with one
name per line and no extra lines or spaces. Exchange SSH keys using the
configured host names for a given host if you use a multi-NIC configuration. In
this example, `cdw` is configured with a single NIC, and `sdw1`, `sdw2`, and
`sdw3` are configured with 4 NICs:
+
+ ```
+ cdw
+ sdw1-1
+ sdw1-2
+ sdw1-3
+ sdw1-4
+ sdw2-1
+ sdw2-2
+ sdw2-3
+ sdw2-4
+ sdw3-1
+ sdw3-2
+ sdw3-3
+ sdw3-4
+ ```
+
+2. Log in as `root` on the coordinator host, and source the
`greenplum_path.sh` file from your Cloudberry installation.
Review Comment:
For the main branch, the file name has been updated. Fox 2.1, we can still
use the old one. FYI.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
