当前位置：网站首页>Not just running away, but saving the guy who mishandled rm -rf /*

Not just running away, but saving the guy who mishandled rm -rf /*

2022-08-10 11:34:00 【InfoQ】

This article is shared from HUAWEI CLOUD Community "

Save the guy injured by rm -rf

", author: Gauss Squirrel Club.

Soul Painter is online again

Before dinner, let's understand the next two key configuration files

1. postgresql.conf in the data directory

Compare the active and standby nodesThe postgresql.conf should have the following inconsistent parameters

listen_addresses The database master node ip or host name used by the remote client connection
local_bind_address The current node is bound when connecting to other openGauss nodesThe local IP address
replconninfo1 Set the first node information for local listening and authentication. If there are 2 standby machines, there will be replconninfo2
log_directory Determines the directory where the server log files are stored, and om is initializedThe name is related to the instance id during installation.
audit_directory The storage directory of the audit file. When the om is initialized, the name is related to the instance id.Relevant

Warning from those who step on the pit:

Generate the postgresql.conf file of an exception node according to a certain node, please modify it one by one according to the parameters, not fully replaceable, easy to change ip, etc.

2.$GAUSSHOME/box/cluster_static_config

Commonly known as static configuration file, the core of OM tool, records the current node andBasic information of the cluster, binary structured file

You can view it through gs_om -t view

You can reset it through gs_om -t generateconf -X XMLFILE --distributGenerate

If there is a static configuration file, there is a dynamic configuration file cluster_static_config

The biggest function of the dynamic configuration file is to record the current node status and mark the active and standby roles of the node, so that when restarting, you know how the node is started

It can be generated by gs_om -t refreshconf This command is only necessary to execute this command after the master/slave switchover has been performed

The data directory of the backup machine of the appetizer platter is lost

The postgresql.conf file can be built after the file is created

postgresql.conf can be copied and modified from the host machine. It will be more convenient if you develop the habit of backup every day.

gs_om -t status --detail

scp xb01:/data1/zxbog/openGauss/data/dn1/postgresql.conf ./data1/zxbog/openGauss/data/dn2/

gs_ctl build -D /data1/zxbog/openGauss/data/dn2

The data directory of the host of the appetizer platter is lost

It is definitely not possible to repair the standby machine, you need to upgrade the host first, and then repair it according to the standby mode, and finally switch between the active and standby.

When the host is down, it is necessary to failover the standby to achieve the standby upgrade.

The host is normalAt the time, you need to switchover the standby machine to realize the standby upgrade.

gs_ctl failover -D /data1/zxbog/openGauss/data/dn2

gs_ctl switchover -D /data1/zxbog/openGauss/data/dn1

The GPHOME/GAUSSHOME directory of the appetizer platter is missing

GPHOME is mainly OM script (database operation and maintenance tool), python language

If it is lost, you can directly cp from other nodes (recommended), or the installation package can be directly decompressed and overwritten, or you can re-execute gs_preinstall

The database kernel is mainly stored under GAUSSHOMEExecutable file, compiled in C/C++

If it is lost, you can cp from other nodes in the same cluster (recommended) or decompress the bz compressed package in the installation package, because the GAUSSHOME/bin directory storesThe respective static configuration files need to be modified

Why do I recommend cp from other nodes? The database installed through om will generate certificates on each node, and the decompression package will not generate theseYes, if openssl is used, you need to manually generate

node replacement and repair of the main dish

There are generally two scenarios for node replacement and repair

The machine is damaged and needs to be rebuilt. The configuration such as ip remains unchanged

The machine is requisitioned and needs to beFor a new machine, the ip address has also changed

In this case, you can use gs_dropnode to delete the old node, and then expand the new node through gs_expansion

div>

These two commands are required to be executed under the main node. If you want to modify the main node, please switch between the active and standby first, and refresh the static/dynamic configuration file

gs_dropnode need to be inExecuted under ordinary users, gs_expansion needs to be executed under the root user

[[email protected] ~]$ gs_dropnode -U xb0608 -G xb0608 -h 192.168.0.26

[[email protected] script]# /opt/software/script/gs_expansion -U xb0608 -G xb0608 -X ../double.xml -h 192.168.0.26

Before executing the expansion node, to reduce unnecessary trouble, please make sure the new node is clean enough, the evil code is as follows, use it with caution

ps -ef|grep ^xb0608|awk '{print $2}'|xargs kill -9 && userdel -r xb0608

rm -rf /data1/zxbog/openGauss/

groupadd xb0608 && useradd xb0608 -g xb0608

passwd xb0608