Clusterware启动顺序

Clusterware启动顺序

[root@ebsdb1 etc]# crsctl check crs

CRS-4638: Oracle High Availability Services is online

CRS-4537: Cluster Ready Services is online

CRS-4529: Cluster Synchronization Services is online

CRS-4533: Event Manager is online

根据以上输出，集群大概可分为4个层次：

层次1：OHAS层面，负责集群的初始化资源和进程。

层次2：CSS层面，负责构建集群并保证集群的一致性。

层次3：CRS层面，负责管理集群的各种应用程序资源。

层次4：EVM层面，负责在集群节点间传递集群事件。

接下来详细地介绍每一个层面的启动过程：

OHASD层面

该层面主要负责启动集群的初始化资源和进程，具体的过程如下：

1./etc/inittab中的以下行被调用

$cat /etc/inittab|grep init.d | grep –v grep
h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
2.操作系统进程init.ohasd run被启动，该进程负责启动ohasd.bin守护进程

[root@ebsdb1 etc]# ps -ef | grep ohasd | grep -v grep

root3813     1  0 Feb03 ?        00:00:00 /bin/sh /etc/init.d/init.ohasd run

root56333     1  0 Feb03 ?        01:03:52 /ebsdb/grid/11.2.0/bin/ohasd.bin reboot

而init.ohasd在启动ohasd.bin守护进程之前需要执行以下的操作。

1）集群自动启动是否被禁用

2）GI home所在文件系统是否被正常挂载

3）管道文件（npohasd）是否能够被访问

[grid@ebsdb1 ~]$ ls -l /var/tmp/.oracle

total 4

srwxr-xr-x 1 grid    oinstall 0 Feb  3 10:41 mdnsd

-rwxrwxrwx 1 grid    oinstall 6 Feb  3 10:41 mdnsd.pid

prwxrwxrwx 1 root    root0 Oct 26 15:43 npohasd

对于ohasd.bin进程，他需要经过以下过程才能够正常运行。

1）确认OLR存在，而且能够被正常访问

[grid@ebsdb1 ~]$ ls -l $GRID_HOME/cdata/

total 2928

drwxr-xr-x 2 grid oinstall      4096 Feb 14 10:21 ebsdb1

-rw------- 1 root oinstall 272756736 Feb 14 15:02 ebsdb1.olr

drwxrwxr-x 2 grid oinstall      4096 Jan 25 13:11 ebsdb-cluster

drwxr-xr-x 2 grid oinstall      4096 Oct 26 15:38 localhost

2）ohasd所使用的套接字文件（socket file）存在

[grid@ebsdb1 ~]$ ls -l /var/tmp/.oracle/*HAS*

srwxrwxrwx 1 root root 0 Feb  3 10:41 /var/tmp/.oracle/sebsdb1DBG_OHASD

srwxrwxrwx 1 root root 0 Feb  3 10:41 /var/tmp/.oracle/sOHASD_IPC_SOCKET_11

-rwxrwxrwx 1 root root 0 Oct 26 15:43 /var/tmp/.oracle/sOHASD_IPC_SOCKET_11_lock

srwxrwxrwx 1 root root 0 Feb  3 10:41 /var/tmp/.oracle/sOHASD_UI_SOCKET

3）ohasd对应的日志文件能够被正常访问

[grid@ebsdb1 11.2.0]$ ls -l $GRID_HOME/log/ebsdb1/ohasd

total 106192

-rw-r--r-- 1 root root 10579981 Feb 12 16:01 ohasd.l01

-rw-r--r-- 1 root root 10520765 Feb  5 20:22 ohasd.l02

-rw-r--r-- 1 root root 10547596 Jan 24 14:24 ohasd.l03

-rw-r--r-- 1 root root 10544559 Jan 22 18:01 ohasd.l04

-rw-r--r-- 1 root root 10546879 Jan 20 21:42 ohasd.l05

-rw-r--r-- 1 root root 10551400 Jan 19 01:21 ohasd.l06

-rw-r--r-- 1 root root 10552985 Jan 17 04:50 ohasd.l07

-rw-r--r-- 1 root root 10550884 Jan 15 08:21 ohasd.l08

-rw-r--r-- 1 root root 10548055 Jan 13 11:52 ohasd.l09

-rw-r--r-- 1 root root 10548999 Jan 11 15:09 ohasd.l10

-rw-r--r-- 1 root root  3171780 Feb 14 17:03 ohasd.log

-rw-r--r-- 1 root root     1260 Feb3 10:41 ohasdOUT.log

 

如果发现init.ohasd进程没有出现，那么说明操作系统进程没有成功地调用/etc/init.d/init.ohasd run命令，比较常见的原因可能如下：

原因1：操作系统运行在了错误的runlevel（可使用who –r查看当前的运行级别）

原因2:/etc/rc<n>.d当中有些脚本被挂起，导致了S<nn>ohasd没有被调用

原因3：GI的自动启动功能被关闭（crsctl disable crs）

而对应的解决办法如下：

办法1：重新启动操作系统到正确的运行级别

办法2：手工运行init.ohasd脚本（例如： nohup /etc/init.d/ohasd run &）

办法3：启动GI自动启动功能（crsctl enable crs）

 

如果发现init.ohasd已经启动，但是ohasd.bin没有被正常启动，比较常见的原因如下：

原因1：OLR不能被访问或者已经丢失。

原因2：ohasd对应的套接字文件无法访问或者已经丢失

原因3：ohasd对应的日志文件无法被访问

而对应的解决办法如下：

办法1:从OLR备份中恢复OLR（默认情况下，在集群安装结束后，OLR会备份<$GRID_HOME/cdata/<节点名>/backup_<时间>.olr>）

ocrconfig –local –restore <OLR备份文件>

办法2：重新启动GI，以便重建套接字文件

crsctl stop crs

crsctl start crs

办法3：修改ohasd日志文件的属性，确认它能够被访问到

-rw-r--r-- 1 root root3171780 Feb 14 17:03 ohasd.log

当然，如果遇到了其他问题，那就需要查看ohasd.log来进行问题分析了

 

3.ohasd.bin开始启动集群的初始化资源和进程

根据前面的介绍，ohasd.bin会启动4个代理进程来启动所有的集群初始化资源。

oraagnet：启动ora.asm、ora.evmd、ora.gipcd、ora.gpnpd、ora.mdnsd等

orarootagent：启动ora.crsd、ora.ctssd、ora.cluster_interconnect.haip、ora.crf、ora.diskmon等

cssdagnet：启动ora.cssd

cssdmonitor：启动ora.cssdmonitor

如果对应的代理进程无法启动的话，那么以上的集群初始化资源也就无法启动，而代理进程无法启动的主要原因有以下两种：

原因1：代理进程对应的二进制文件损坏

原因2：代理进程的日志文件无法访问

[grid@ebsdb1 oraagent_grid]$ ls -l $GRID_HOME/log/ebsdb1/agent/ohasd/oraagent_grid

total 109976

……

-rw-r--r-- 1 grid oinstall  6895201 Feb 14 19:28 oraagent_grid.log

……

 

[grid@ebsdb1 oracssdagent_root]$ ls -l $GRID_HOME/log/ebsdb1/agent/ohasd/orarootagent_root

total 112468

……

-rw-r--r-- 1 root root  9467315 Feb 14 19:30 orarootagent_root.log

……

 

[grid@ebsdb1 oraagent_grid]$ ls -l $GRID_HOME/log/ebsdb1/agent/ohasd/oracssdagent_root

total 852

-rw-r--r-- 1 root root 865091 Feb 14 16:04 oracssdagent_root.log

 

[grid@ebsdb1 oracssdagent_root]$ ls -l $GRID_HOME/log/ebsdb1/agent/ohasd/oracssdmonitor_root

total 844

-rw-r--r-- 1 root root 856526 Feb 14 19:25 oracssdmonitor_root.log

 

对应的解决办法如下：

办法1：将有问题节点的代理进程二进制文件和健康节点的文件进行比较，发现不同后，把健康节点的文件复制到问题节点的对应位置。

办法2：确认代理进程的日志文件能够被对应的用户访问。

 

4.集群的初始化资源开始启动

虽然ohasd的代理进程会同时启动所有的集群初始化资源，但是它们之间还是有依赖关系的，集群初始化资源的启动依赖关系如下：

有些对集群不重要的初始化资源，在上图中并没有显示

从上面的途中大家可以看到gipcd、gpnpd、mdnsd负责完成集群的bootstrap过程；cssdagent和cssdmonitor负责启动和监控cssd守护进程；而集群的其他初始化资源都要依赖于cssd。

下面对集群的bootstrap过程进行简单的介绍（详细的过程在css管理中）

1）mdnsd守护进程被启动，并启动mdns服务，以便gpnpd能够通过mdns在节点之间传输gpnp profile文件。

2）gpnpd守护进程被启动，gpnpd开始读取本地节点的gpnp profile，之后和远程节点的gpnpd守护进程通信，以便获得集群中最新的gpnp profile信息。

3）gpnpd启动完毕，向本地节点的其他集群初始化资源提供gpnp profile服务。

4）gipcd守护进程被启动，从gpnpd守护进程获得集群的私网信息，并和远程节点的gpipcd守护进程通信，最后开监控本地节点的私网。

5）cssdagent代理进程启动ocssd.bin守护进程。

6）cssdmonitor守护进程启动，并开始监控ocssd.bin守护进程的状态。

在整个过程中，可能导致集群的bootstrap过程无法成功的主要原因如下。

原因1：集群中有其他的mdns软件运行，这会导致GI的mdnsd服务无法正常工作。

原因2：gpnp profile文件中的信息出现错误，这会导致集群的bootstrap过程无法完成。

[grid@ebsdb1 peer]$ gpnptool get

或

[grid@ebsdb1 peer]$ cat $GRID_HOME/gpnp/<hostname>/profiles/peer/profile.xml

原因3：节点之间的网络通信存在问题，这会导致gpnp profile无法正常传输。

原因4：gpnp的一些线程被挂起，这会导致gpnpd守护进程无法成功完成启动任务。

原因5：集群的私网网卡出现问题，这会导致gipcd无法和其他节点的gipcd进行通信或者集群没有可用的私网进行通信。

原因6：gipcd存在问题，这会导致它错误地认为集群私网网卡存在问题。

原因7：以上守护进程的套接字文件丢失。

对应的解决方法如下。

方法1：停止并禁用其他的mdns软件。

方法2：如果gpnp profile只是在集群的某一个节点上出现了错误，可以从集群的其他节点将其复制过来。如果集群所有几点的gpnp pfile都出现了问题，那么就需要使用gpnp工具来进行修正。

下面的例子演示了如何使用gpnp tool修改gpnp profile中集群的私网信息。

1）  检查当前的gpnp profile，确认gpnpd能够通过mdns找到集群的其他节点。

[grid@ebsdb1 peer]$ gpnptool get

[grid@ebsdb1 peer]$ gpnptool find

2）  创建一个工作路径以用于编辑gpnp profile

mkdir /home/grid/gpnp

export GPNPDIR=/home/grid/gpnp

$GRID_HOME/bing/gpnptool get -o=$GPNPDIR/profile.original

3）  创建一个用于修改的gpnp profile副本

cp $GPNPDIR/profile.original $GPNPDIR/p.xml

4）  查看gpnp profile的序列号和私网信息

$gpnptool getpval -p=$GPNPDIR/p.xml -prf_sq -o-

$gpnptool getpval -p=$GPNPDIR/p.xml -net -o-

5）  修改集群私网的网卡信息

gpnptool edit -p=$GPNPDIR/p.xml -o=$GPNPDIR/p.xml -ovr -prf_sq=<当前序列号+1> -net<私网编号>:net_ada=<私网网卡名>

例如：

gpnptool edit -p=$GPNPDIR/p.xml -o=$GPNPDIR/p.xml -ovr -prf_sq=9 -net2:net_ada=eth1

6）  确认之前的修改

gpnptool sign -p=$GPNPDIR/p.xml -o=$GPNPDIR/p.xml -ovr -w=cw-fs:peer

7）  将修改后的gpnp profile应用到gpnpd守护进程中。

gpnptool put -p=$GPNPDIR/p.xml

8）  将改变后的gpnp profile推送到集群的其他节点

gpnptool find -c=<集群名>

gpnptool rget -c=<集群名>

方法3：确认件私网通信正常（例如：使用ping、traceroute等命令确认集群私网的连通性）

方法4：在操作系统层面重新启动gpnp守护进程，例如：kill -9 <gpnp进程ID>

当gpnpd守护进程被总之之后，对应的ohasd代理进程oraagent会及时发现这一情况，并启动新的gpnpd守护进程。

方法5：确认集群私网通信正常（例如：使用ping、traceroute等命令确认集群私网的连通性）

方法6：在操作系统层面重新启动gipcd守护进程，例如：kill -9 <gipcd进程ID>

当gipcd守护进程被总之之后，对应的ohasd代理进程oraagent会及时发现这一情况，并启动新的gipcd守护进程。

方法7：重新启动GI，以便重建套接字文件。

crsctl stop crs

crsctl start crs

<wiz_tmp_tag id="wiz-table-range-border" contenteditable="false" style="display: none;">

Clusterware启动顺序

[root@ebsdb1 etc]# crsctl check crs

CRS-4638: Oracle High Availability Services is online

CRS-4537: Cluster Ready Services is online

CRS-4529: Cluster Synchronization Services is online

CRS-4533: Event Manager is online

根据以上输出，集群大概可分为4个层次：

层次1：OHAS层面，负责集群的初始化资源和进程。

层次2：CSS层面，负责构建集群并保证集群的一致性。

层次3：CRS层面，负责管理集群的各种应用程序资源。

层次4：EVM层面，负责在集群节点间传递集群事件。

接下来详细地介绍每一个层面的启动过程：

OHASD层面

该层面主要负责启动集群的初始化资源和进程，具体的过程如下：

1./etc/inittab中的以下行被调用

$cat /etc/inittab|grep init.d | grep –v grep
h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
2.操作系统进程init.ohasd run被启动，该进程负责启动ohasd.bin守护进程

[root@ebsdb1 etc]# ps -ef | grep ohasd | grep -v grep

root3813     1  0 Feb03 ?        00:00:00 /bin/sh /etc/init.d/init.ohasd run

root56333     1  0 Feb03 ?        01:03:52 /ebsdb/grid/11.2.0/bin/ohasd.bin reboot

而init.ohasd在启动ohasd.bin守护进程之前需要执行以下的操作。

1）集群自动启动是否被禁用

2）GI home所在文件系统是否被正常挂载

3）管道文件（npohasd）是否能够被访问

[grid@ebsdb1 ~]$ ls -l /var/tmp/.oracle

total 4

srwxr-xr-x 1 grid    oinstall 0 Feb  3 10:41 mdnsd

-rwxrwxrwx 1 grid    oinstall 6 Feb  3 10:41 mdnsd.pid

prwxrwxrwx 1 root    root0 Oct 26 15:43 npohasd

对于ohasd.bin进程，他需要经过以下过程才能够正常运行。

1）确认OLR存在，而且能够被正常访问

[grid@ebsdb1 ~]$ ls -l $GRID_HOME/cdata/

total 2928

drwxr-xr-x 2 grid oinstall      4096 Feb 14 10:21 ebsdb1

-rw------- 1 root oinstall 272756736 Feb 14 15:02 ebsdb1.olr

drwxrwxr-x 2 grid oinstall      4096 Jan 25 13:11 ebsdb-cluster

drwxr-xr-x 2 grid oinstall      4096 Oct 26 15:38 localhost

2）ohasd所使用的套接字文件（socket file）存在

[grid@ebsdb1 ~]$ ls -l /var/tmp/.oracle/*HAS*

srwxrwxrwx 1 root root 0 Feb  3 10:41 /var/tmp/.oracle/sebsdb1DBG_OHASD

srwxrwxrwx 1 root root 0 Feb  3 10:41 /var/tmp/.oracle/sOHASD_IPC_SOCKET_11

-rwxrwxrwx 1 root root 0 Oct 26 15:43 /var/tmp/.oracle/sOHASD_IPC_SOCKET_11_lock

srwxrwxrwx 1 root root 0 Feb  3 10:41 /var/tmp/.oracle/sOHASD_UI_SOCKET

3）ohasd对应的日志文件能够被正常访问

[grid@ebsdb1 11.2.0]$ ls -l $GRID_HOME/log/ebsdb1/ohasd

total 106192

-rw-r--r-- 1 root root 10579981 Feb 12 16:01 ohasd.l01

-rw-r--r-- 1 root root 10520765 Feb  5 20:22 ohasd.l02

-rw-r--r-- 1 root root 10547596 Jan 24 14:24 ohasd.l03

-rw-r--r-- 1 root root 10544559 Jan 22 18:01 ohasd.l04

-rw-r--r-- 1 root root 10546879 Jan 20 21:42 ohasd.l05

-rw-r--r-- 1 root root 10551400 Jan 19 01:21 ohasd.l06

-rw-r--r-- 1 root root 10552985 Jan 17 04:50 ohasd.l07

-rw-r--r-- 1 root root 10550884 Jan 15 08:21 ohasd.l08

-rw-r--r-- 1 root root 10548055 Jan 13 11:52 ohasd.l09

-rw-r--r-- 1 root root 10548999 Jan 11 15:09 ohasd.l10

-rw-r--r-- 1 root root  3171780 Feb 14 17:03 ohasd.log

-rw-r--r-- 1 root root     1260 Feb3 10:41 ohasdOUT.log

 

如果发现init.ohasd进程没有出现，那么说明操作系统进程没有成功地调用/etc/init.d/init.ohasd run命令，比较常见的原因可能如下：

原因1：操作系统运行在了错误的runlevel（可使用who –r查看当前的运行级别）

原因2:/etc/rc<n>.d当中有些脚本被挂起，导致了S<nn>ohasd没有被调用

原因3：GI的自动启动功能被关闭（crsctl disable crs）

而对应的解决办法如下：

办法1：重新启动操作系统到正确的运行级别

办法2：手工运行init.ohasd脚本（例如： nohup /etc/init.d/ohasd run &）

办法3：启动GI自动启动功能（crsctl enable crs）

 

如果发现init.ohasd已经启动，但是ohasd.bin没有被正常启动，比较常见的原因如下：

原因1：OLR不能被访问或者已经丢失。

原因2：ohasd对应的套接字文件无法访问或者已经丢失

原因3：ohasd对应的日志文件无法被访问

而对应的解决办法如下：

办法1:从OLR备份中恢复OLR（默认情况下，在集群安装结束后，OLR会备份<$GRID_HOME/cdata/<节点名>/backup_<时间>.olr>）

ocrconfig –local –restore <OLR备份文件>

办法2：重新启动GI，以便重建套接字文件

crsctl stop crs

crsctl start crs

办法3：修改ohasd日志文件的属性，确认它能够被访问到

-rw-r--r-- 1 root root3171780 Feb 14 17:03 ohasd.log

当然，如果遇到了其他问题，那就需要查看ohasd.log来进行问题分析了

 

3.ohasd.bin开始启动集群的初始化资源和进程

根据前面的介绍，ohasd.bin会启动4个代理进程来启动所有的集群初始化资源。

oraagnet：启动ora.asm、ora.evmd、ora.gipcd、ora.gpnpd、ora.mdnsd等

orarootagent：启动ora.crsd、ora.ctssd、ora.cluster_interconnect.haip、ora.crf、ora.diskmon等

cssdagnet：启动ora.cssd

cssdmonitor：启动ora.cssdmonitor

如果对应的代理进程无法启动的话，那么以上的集群初始化资源也就无法启动，而代理进程无法启动的主要原因有以下两种：

原因1：代理进程对应的二进制文件损坏

原因2：代理进程的日志文件无法访问

[grid@ebsdb1 oraagent_grid]$ ls -l $GRID_HOME/log/ebsdb1/agent/ohasd/oraagent_grid

total 109976

……

-rw-r--r-- 1 grid oinstall  6895201 Feb 14 19:28 oraagent_grid.log

……

 

[grid@ebsdb1 oracssdagent_root]$ ls -l $GRID_HOME/log/ebsdb1/agent/ohasd/orarootagent_root

total 112468

……

-rw-r--r-- 1 root root  9467315 Feb 14 19:30 orarootagent_root.log

……

 

[grid@ebsdb1 oraagent_grid]$ ls -l $GRID_HOME/log/ebsdb1/agent/ohasd/oracssdagent_root

total 852

-rw-r--r-- 1 root root 865091 Feb 14 16:04 oracssdagent_root.log

 

[grid@ebsdb1 oracssdagent_root]$ ls -l $GRID_HOME/log/ebsdb1/agent/ohasd/oracssdmonitor_root

total 844

-rw-r--r-- 1 root root 856526 Feb 14 19:25 oracssdmonitor_root.log

 

对应的解决办法如下：

办法1：将有问题节点的代理进程二进制文件和健康节点的文件进行比较，发现不同后，把健康节点的文件复制到问题节点的对应位置。

办法2：确认代理进程的日志文件能够被对应的用户访问。

 

4.集群的初始化资源开始启动

虽然ohasd的代理进程会同时启动所有的集群初始化资源，但是它们之间还是有依赖关系的，集群初始化资源的启动依赖关系如下：

有些对集群不重要的初始化资源，在上图中并没有显示

从上面的途中大家可以看到gipcd、gpnpd、mdnsd负责完成集群的bootstrap过程；cssdagent和cssdmonitor负责启动和监控cssd守护进程；而集群的其他初始化资源都要依赖于cssd。

下面对集群的bootstrap过程进行简单的介绍（详细的过程在css管理中）

1）mdnsd守护进程被启动，并启动mdns服务，以便gpnpd能够通过mdns在节点之间传输gpnp profile文件。

2）gpnpd守护进程被启动，gpnpd开始读取本地节点的gpnp profile，之后和远程节点的gpnpd守护进程通信，以便获得集群中最新的gpnp profile信息。

3）gpnpd启动完毕，向本地节点的其他集群初始化资源提供gpnp profile服务。

4）gipcd守护进程被启动，从gpnpd守护进程获得集群的私网信息，并和远程节点的gpipcd守护进程通信，最后开监控本地节点的私网。

5）cssdagent代理进程启动ocssd.bin守护进程。

6）cssdmonitor守护进程启动，并开始监控ocssd.bin守护进程的状态。

在整个过程中，可能导致集群的bootstrap过程无法成功的主要原因如下。

原因1：集群中有其他的mdns软件运行，这会导致GI的mdnsd服务无法正常工作。

原因2：gpnp profile文件中的信息出现错误，这会导致集群的bootstrap过程无法完成。

[grid@ebsdb1 peer]$ gpnptool get

或

[grid@ebsdb1 peer]$ cat $GRID_HOME/gpnp/<hostname>/profiles/peer/profile.xml

原因3：节点之间的网络通信存在问题，这会导致gpnp profile无法正常传输。

原因4：gpnp的一些线程被挂起，这会导致gpnpd守护进程无法成功完成启动任务。

原因5：集群的私网网卡出现问题，这会导致gipcd无法和其他节点的gipcd进行通信或者集群没有可用的私网进行通信。

原因6：gipcd存在问题，这会导致它错误地认为集群私网网卡存在问题。

原因7：以上守护进程的套接字文件丢失。

对应的解决方法如下。

方法1：停止并禁用其他的mdns软件。

方法2：如果gpnp profile只是在集群的某一个节点上出现了错误，可以从集群的其他节点将其复制过来。如果集群所有几点的gpnp pfile都出现了问题，那么就需要使用gpnp工具来进行修正。

下面的例子演示了如何使用gpnp tool修改gpnp profile中集群的私网信息。

1）  检查当前的gpnp profile，确认gpnpd能够通过mdns找到集群的其他节点。

[grid@ebsdb1 peer]$ gpnptool get

[grid@ebsdb1 peer]$ gpnptool find

2）  创建一个工作路径以用于编辑gpnp profile

mkdir /home/grid/gpnp

export GPNPDIR=/home/grid/gpnp

$GRID_HOME/bing/gpnptool get -o=$GPNPDIR/profile.original

3）  创建一个用于修改的gpnp profile副本

cp $GPNPDIR/profile.original $GPNPDIR/p.xml

4）  查看gpnp profile的序列号和私网信息

$gpnptool getpval -p=$GPNPDIR/p.xml -prf_sq -o-

$gpnptool getpval -p=$GPNPDIR/p.xml -net -o-

5）  修改集群私网的网卡信息

gpnptool edit -p=$GPNPDIR/p.xml -o=$GPNPDIR/p.xml -ovr -prf_sq=<当前序列号+1> -net<私网编号>:net_ada=<私网网卡名>

例如：

gpnptool edit -p=$GPNPDIR/p.xml -o=$GPNPDIR/p.xml -ovr -prf_sq=9 -net2:net_ada=eth1

6）  确认之前的修改

gpnptool sign -p=$GPNPDIR/p.xml -o=$GPNPDIR/p.xml -ovr -w=cw-fs:peer

7）  将修改后的gpnp profile应用到gpnpd守护进程中。

gpnptool put -p=$GPNPDIR/p.xml

8）  将改变后的gpnp profile推送到集群的其他节点

gpnptool find -c=<集群名>

gpnptool rget -c=<集群名>

方法3：确认件私网通信正常（例如：使用ping、traceroute等命令确认集群私网的连通性）

方法4：在操作系统层面重新启动gpnp守护进程，例如：kill -9 <gpnp进程ID>

当gpnpd守护进程被总之之后，对应的ohasd代理进程oraagent会及时发现这一情况，并启动新的gpnpd守护进程。

方法5：确认集群私网通信正常（例如：使用ping、traceroute等命令确认集群私网的连通性）

方法6：在操作系统层面重新启动gipcd守护进程，例如：kill -9 <gipcd进程ID>

当gipcd守护进程被总之之后，对应的ohasd代理进程oraagent会及时发现这一情况，并启动新的gipcd守护进程。

方法7：重新启动GI，以便重建套接字文件。

crsctl stop crs

crsctl start crs

<wiz_tmp_tag id="wiz-table-range-border" contenteditable="false" style="display: none;">