11G RAC 节点2 主机down(两个节点RAC)

--节点2 数据库日志

Mon Jul 01 06:38:22 2019
SUCCESS: diskgroup SAS_ARCH was dismounted
Mon Jul 01 06:38:22 2019
Shutting down instance (abort)
License high water mark = 1923
USER (ospid: 82381): terminating the instance
Mon Jul 01 06:38:22 2019
opiodr aborting process unknown ospid (12589) as a result of ORA-1092
Mon Jul 01 06:38:22 2019
opiodr aborting process unknown ospid (45276) as a result of ORA-1092
Mon Jul 01 06:38:22 2019
opiodr aborting process unknown ospid (107399) as a result of ORA-1092
Instance terminated by USER, pid = 82381
Mon Jul 01 06:38:24 2019
Instance shutdown complete

 

--主机日志

Jul 1 06:35:01 test2 auditd[16253]: Audit daemon rotating log files
Jul 1 06:38:19 test2 init: oracle-ohasd main process (15639) killed by TERM signal
Jul 1 06:38:19 test2 init: oracle-tfa main process (15638) killed by TERM signal
Jul 1 06:38:19 test2 init: tty (/dev/tty2) main process (16997) killed by TERM signal
Jul 1 06:38:19 test2 init: tty (/dev/tty3) main process (16999) killed by TERM signal
Jul 1 06:38:19 test2 init: tty (/dev/tty4) main process (17004) killed by TERM signal
Jul 1 06:38:19 test2 init: tty (/dev/tty5) main process (17006) killed by TERM signal
Jul 1 06:38:19 test2 init: tty (/dev/tty6) main process (17008) killed by TERM signal
Jul 1 06:38:19 test2 gnome-session[17110]: WARNING: Failed to send buffer
Jul 1 06:38:19 test2 gnome-session[17110]: WARNING: Failed to send buffer
Jul 1 06:38:23 test2 ntpd[90741]: Deleting interface #15 bond0:1, 10.1.11.103#123, interface stats: received=1410, sent=0, dropped=0, active_time=56169415 secs
Jul 1 06:38:39 test2 pulseaudio[17164]: pid.c: Failed to open PID file '/var/lib/gdm/.pulse/45593399e441b14e2757581a00000028-runtime/pid': No such file or directory
Jul 1 06:38:39 test2 pulseaudio[17164]: pid.c: Failed to open PID file '/var/lib/gdm/.pulse/45593399e441b14e2757581a00000028-runtime/pid': No such file or directory
Jul 1 06:38:46 test2 ntpd[90741]: Deleting interface #14 bond1:1, 169.254.7.117#123, interface stats: received=0, sent=0, dropped=0, active_time=56169467 secs
Jul 1 06:38:51 test2 abrtd: Got signal 15, exiting
Jul 1 06:38:51 test2 xinetd[45495]: Exiting...
Jul 1 06:38:51 test2 acpid: exiting
Jul 1 06:38:51 test2 ntpd[90741]: ntpd exiting on signal 15
Jul 1 06:38:53 test2 init: Disconnected from system bus
Jul 1 06:38:53 test2 rtkit-daemon[17166]: Demoting known real-time threads.
Jul 1 06:38:53 test2 rtkit-daemon[17166]: Demoted 0 threads.
Jul 1 06:38:53 test2 auditd[16253]: The audit daemon is exiting.
Jul 1 06:38:53 test2 kernel: type=1305 audit(1561934333.370:37053744): audit_pid=0 old=16253 auid=4294967295 ses=4294967295 res=1
Jul 1 06:38:53 test2 kernel: type=1305 audit(1561934333.475:37053745): audit_enabled=0 old=1 auid=4294967295 ses=4294967295 res=1
Jul 1 06:38:53 test2 kernel: Kernel logging (proc) stopped.
Jul 1 06:38:53 test2 rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="16275" x-info="http://www.rsyslog.com"] exiting on signal 15.

 

---节点2 GRID 日志 /u01/11.2.0/grid/log/test2 下面的alertbapdb2.log
2019-07-01 06:34:49.606:
[client(75150)]CRS-0009:log file "/u01/11.2.0/grid/log/test2/client/olsnodes.log" reopened
2019-07-01 06:34:49.606:
[client(75150)]CRS-0019:file rotation terminated. log file: "/u01/11.2.0/grid/log/test2/client/olsnodes.log"
2019-07-01 06:38:33.151:
[/u01/11.2.0/grid/bin/orarootagent.bin(106660)]CRS-5822:Agent '/u01/11.2.0/grid/bin/orarootagent_root' disconnected from server. Details at (:CRSAGF00117:) {0:5:52057} in /u01/11.2.0/grid/log/test2/agent/crsd/orarootagent_root//orarootagent_root.log.
LFI-01523: rename() failed.

2019-07-01 06:34:49.606:
[client(75150)]CRS-0009:log file "/u01/11.2.0/grid/log/test2/client/olsnodes.log" reopened
2019-07-01 06:34:49.606:
[client(75150)]CRS-0019:file rotation terminated. log file: "/u01/11.2.0/grid/log/test2/client/olsnodes.log"
2019-07-01 06:38:33.151:
[/u01/11.2.0/grid/bin/orarootagent.bin(106660)]CRS-5822:Agent '/u01/11.2.0/grid/bin/orarootagent_root' disconnected from server. Details at (:CRSAGF00117:) {0:5:52057} in /u01/11.2.0/grid/log/test2/agent/crsd/orarootagent_root//orarootagent_root.log.
2019-07-01 06:38:33.887:
[ctssd(104917)]CRS-2405:The Cluster Time Synchronization Service on host test2 is shutdown by user
2019-07-01 06:38:33.892:
[mdnsd(103640)]CRS-5602:mDNS service stopping by request.
2019-07-01 06:38:45.860:
[cssd(103758)]CRS-1603:CSSD on node test2 shutdown by user.
2019-07-01 06:38:45.970:
[ohasd(103446)]CRS-2767:Resource state recovery not attempted for 'ora.cssdmonitor' as its target state is OFFLINE
2019-07-01 06:38:46.064:
[cssd(103758)]CRS-1660:The CSS daemon shutdown has completed
2019-07-01 06:38:49.592:
[gpnpd(103651)]CRS-2329:GPNPD on node test2 shutdown.
2019-07-01 09:28:04.022:
[ohasd(17090)]CRS-2112:The OLR service started on node test2.
2019-07-01 09:28:04.069:
[ohasd(17090)]CRS-1301:Oracle High Availability Service started on node test2.

 

rac是通过几个必要条件进行通信,时间,磁盘心跳,链路心跳,缺一不可。

---节点1 日志

Mon Jul 01 06:38:24 2019
Reconfiguration started (old inc 16, new inc 18)
List of instances:
1 (myinst: 1)
Global Resource Directory frozen
* dead instance detected - domain 0 invalid = TRUE
Communication channels reestablished
Master broadcasted resource hash value bitmaps
Non-local Process blocks cleaned out
Mon Jul 01 06:38:25 2019
LMS 0: 0 GCS shadows cancelled, 0 closed, 0 Xw survived
Mon Jul 01 06:38:25 2019
LMS 3: 2 GCS shadows cancelled, 1 closed, 0 Xw survived
Mon Jul 01 06:38:25 2019
Mon Jul 01 06:38:25 2019
LMS 2: 0 GCS shadows cancelled, 0 closed, 0 Xw survived
LMS 1: 0 GCS shadows cancelled, 0 closed, 0 Xw survived
Mon Jul 01 06:38:36 2019
Set master node info
Submitted all remote-enqueue requests
Dwn-cvts replayed, VALBLKs dubious
All grantable enqueues granted
Post SMON to start 1st pass IR
Mon Jul 01 06:38:36 2019
Instance recovery: looking for dead threads
Beginning instance recovery of 1 threads
Mon Jul 01 06:38:52 2019
parallel recovery started with 32 processes
Started redo scan
Completed redo scan
read 12123 KB redo, 6138 data blocks need recovery
Mon Jul 01 06:38:55 2019
Submitted all GCS remote-cache requests
Post SMON to start 1st pass IR
Fix write in gcs resources
Mon Jul 01 06:39:07 2019
Reconfiguration complete
Mon Jul 01 06:39:32 2019
Started redo application at
Thread 2: logseq 218275, block 1708335

 

---原因:
2019-07-01 06:38:33.887:
[ctssd(104917)]CRS-2405:The Cluster Time Synchronization Service on host test2 is shutdown by user

主机test2上的集群时间同步服务由用户关闭

主机 BIOS 时间不一致;

[oracle@test1 ~]$ su - root
Password:
[root@test1 ~]# hwclock
Mon 01 Jul 2019 11:27:27 AM CST -0.485777 seconds
[root@test1 ~]# date
Mon Jul 1 10:44:03 CST 2019

[root@test2 ~]# hwclock
Mon 01 Jul 2019 10:42:33 AM CST -0.219479 seconds
[root@test2 ~]# date
Mon Jul 1 10:42:36 CST 2019


--同步方式

--节点1 cat /etc/ntp.conf

server pbsntp01.sx.com iburst
server pbsntp02.sx.com iburst


--节点2 修改后 cat /etc/ntp.conf
server 10.0.10.2 iburst
#server pbsntp02.sx.com iburst

 

--解决办法:

hwclock  -w

如果时间不方便可以按照如下定时任务修改

--root 用户
vi hwclock.sh

#! /bin/bash
#Function refresh BIOS time
exec >> /var/log/hwclock`date +%y%m%d%H`.log
date
sleep 3
echo "This is system date"
hwclock
sleep 3
echo "This is show hwclock"
hwclock -w
sleep 3
echo "This is application hwclock to BIOS"
#try agen
hwclock
sleep 3
date

 

[oracle@test1 ~]$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*1.0.10.250 19.19.24.22 3 u 19 256 377 0.436 -3.817 6.576
[oracle@test1 ~]$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*1.0.10.250 19.19.24.22 3 u 32 256 377 0.436 -3.817 6.576


[oracle@test2 ~]$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*1.0.10.250 12.2.15.2 3 u 61 256 377 0.386 2.638 7.938
[oracle@test2 ~]$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*1.0.10.250 12.2.15.2 3 u 62 256 377 0.386 2.638 7.938

 

remote:响应这个请求的NTP服务器的名称。
refid:NTP服务器使用的上一级ntp服务器。
st:remote远程服务器的级别.由于NTP是层型结构,有顶端的服务器,多层的Relay Server再到客户端.所以服务器从高到低级别可以设定为1-16.为了减缓负荷和网络堵塞,原则上应该避免直接连接到级别为1的服务器的.
when:上一次成功请求之后到现在的秒数。
poll:本地机和远程服务器多少时间进行一次同步(单位为秒).在一开始运行NTP的时候这个poll值会比较小,那样和服务器同步的频率也就增加了,可以尽快调整到正确的时间范围,之后poll值会逐渐增大,同步的频率也就会相应减小
reach:这是一个八进制值,用来测试能否和服务器连接.每成功连接一次它的值就会增加
delay:从本地机发送同步要求到ntp服务器的round trip time
offset:主机通过NTP时钟同步与所同步时间源的时间偏移量,单位为毫秒(ms)。offset越接近于0,主机和ntp服务器的时间越接近
jitter:这是一个用来做统计的值.它统计了在特定个连续的连接数里offset的分布情况.简单地说这个数值的绝对值越小,主机的时间就越精确


----重点查询 offset 这个值是否在本机一直在增长, 在100 以内表示没问题

 

---可以添加定时任务

#ntpd
* */1 * * * /bin/sh /home/oracle/shell/ntpq.sh &> /dev/null

vi ntpq.sh

#!/bin/bash
source /home/oracle/.bash_profile
exec >> /home/oracle/shell/ntpq_`date +%y%m%d%H`.log
ntpq -p
sleep 3
ntpq -p

chmod +x ntpq.sh

 

---本次故障实际原因:OS 层面 电源模块故障; 

 

转载于:https://www.cnblogs.com/ss-33/p/11113335.html

<think>我们正在处理一个Oracle 11g RAC环境中清除第一个节点的SCAN IP的问题。用户指定了网络接口为bound0:1。 注意:在Oracle RAC中,SCAN(Single Client Access Name)是一个域名,解析到三个IP地址(在11g R2中)。这些IP地址由集群管理,通常不需要手动清除。但是,如果确实需要清除,可能是因为配置错误或其他原因,我们需要谨慎操作。 重要提示:在RAC环境中修改网络配置可能会影响集群的稳定性,因此建议在维护窗口进行操作,并备份相关配置文件。 步骤: 1. 确认当前SCAN IP的配置情况。 2. 使用适当的集群命令(如srvctl)来停止和修改资源。 3. 修改网络配置文件(如果需要)。 然而,通常我们不会单独清除一个节点的SCAN IP,因为SCAN VIP是由整个集群管理的,并且通常由三个节点共同托管(在标准配置中)。但是,用户指定了节点1和接口bound0:1,可能是指该节点上配置的SCAN VIP。 在Oracle 11g RAC中,SCAN VIP是通过GNS(Grid Naming Service)或手动配置的。如果使用手动配置,那么SCAN VIP是作为资源注册在集群中,并且绑定到每个节点的公共网络接口上(但每个SCAN VIP在某一时刻只在一个节点上活跃)。 清除一个节点上的SCAN IP(实际上可能是停用该节点上的SCAN VIP资源)的步骤: 注意:以下操作需要在节点1上以root用户执行。 步骤1:停止SCAN监听器(如果它正在运行) 步骤2:停止SCAN VIP资源 步骤3:从集群配置中删除SCAP VIP资源(不推荐,因为通常三个SCAN VIP是集群必需的)?实际上,我们可能只需要停用该资源在节点1上的运行,但是SCAN VIP是集群资源,会由集群重新分配到其他节点。 但是,用户要求清除节点1上的SCAN IP,可能是指从节点1的网络接口上解除绑定该IP地址。这可以通过停止该资源来实现,因为当资源停止后,集群会解除IP绑定。 具体步骤: 1. 检查当前SCAN VIP的状态: # srvctl status scan # srvctl status scan_listener 2. 停止SCAN监听器(因为SCAN VIP资源依赖于SCAN监听器?实际上,SCAN监听器依赖于SCAN VIP): # srvctl stop scan_listener -n <node_name> # 但是,通常我们停止整个SCAN监听器,而不是单个节点。注意:SCAN监听器是集群范围的。 实际上,SCAN监听器是作为一个整体管理的,不能单独停止某个节点上的SCAN监听器。所以,我们可能需要停止整个SCAN监听器(如果允许的话)? 3. 停止SCAN VIP资源(同样,SCAN VIP也是集群资源): # srvctl stop scan -i <scan_number> # 例如,scan1, scan2, scan3?但是,用户可能只想清除节点1上的,而SCAN VIP有三个,分别对应三个IP。 但是,我们可能无法单独停止某个节点上的SCAN VIP,因为SCAN VIP资源是集群范围的,并且由集群自动分配到节点上。如果我们想从节点1上移走SCAN VIP,我们可以通过重启节点1的集群服务来触发重新分配(但这不是清除,而是转移)。 另一种思路:用户可能是在安装过程中配置了错误的SCAN IP,现在想要清除。那么,我们可以从集群配置中完全移除SCAN,然后重新配置?但这会影响整个集群。 根据Oracle文档,我们不应该手动删除网络接口上的IP,而应该使用集群命令。 因此,更安全的做法是: 1. 停止整个SCAN(包括所有SCAN VIP和SCAN监听器): # srvctl stop scan_listener # srvctl stop scan 2. 然后,从集群配置中删除SCAN资源(谨慎操作,这会导致客户端无法通过SCAN连接): # srvctl remove scan [-f] 注意:删除SCAN资源需要-f(强制)选项,因为通常不建议删除。 3. 删除后,节点1上的SCAN IP绑定应该会被释放(因为资源被删除)。但是,如果网络配置中还有残留,可能需要手动删除。 4. 手动删除网络配置(如果使用OS级别的绑定): 在节点1上,检查bound0:1对应的IP是否是SCAN IP,如果是,我们可以使用命令(以root用户): # ifconfig bound0:1 down # ifconfig bound0:1 del <scan_ip> # 或者使用ip命令(如果可用) 但是,请注意,bound0是一个绑定接口,通常由集群软件管理。手动删除可能会导致不一致。 因此,我们更推荐使用集群命令来管理。如果已经删除了SCAN资源,那么IP应该已经被释放了。如果没有,重启节点1的集群服务(crsctl stop crs; crsctl start crs)可能会清除。 但是,用户可能只是想在节点1上清除一个错误的配置,而不影响整个集群?这很难,因为SCAN是集群范围的。 另一种可能性:用户可能是指节点VIP(而不是SCAN VIP)?因为节点VIP是每个节点一个,并且绑定在公共网络的接口上(如bound0:1)。节点VIP的命名通常是类似<节点名>-vip。 如果用户实际上是想清除节点1的节点VIP(而不是SCAN VIP),那么步骤不同: 步骤: 1. 停止节点1的节点VIP: # srvctl stop vip -n <node1_name> -f 2. 删除节点1的节点VIP资源(谨慎,这会使该节点无法被客户端访问): # srvctl remove vip -n <node1_name> -f 3. 然后,手动删除网络接口上的绑定(如果集群没有自动删除): # ifconfig bound0:1 down 4. 从网络配置文件中移除(例如,在/etc/sysconfig/network-scripts/ifcfg-bound0:1,具体路径根据操作系统而定),然后重启网络服务或重启节点。 但是,在Oracle RAC中,节点VIP是必需的,所以删除后需要重新添加。 因此,我们需要澄清用户的需求:是清除SCAN IP还是节点VIP? 根据用户的问题描述:“清除第一个节点的SCAN IP”,所以应该是SCAN IP。但是,在RAC中,SCAN IP是共享的,并不属于单个节点。所以,我们只能通过停止和删除整个SCAN资源来清除。 考虑到操作的严重性,我们建议用户重新考虑。如果是因为配置错误需要重新配置SCAN,那么可以按照以下步骤: 1. 停止整个集群(所有节点): # srvctl stop database -d <db_name> # srvctl stop asm -n <node_name> # 逐个节点停止 # srvctl stop nodeapps -n <node_name> # 逐个节点停止 # srvctl stop scan_listener # srvctl stop scan 2. 删除SCAN资源: # srvctl remove scan -f 3. 删除后,检查网络接口bound0:1是否还有SCAN IP绑定,如果有,手动删除(使用ifconfig或ip命令)。 4. 然后,重新配置SCAN(使用srvctl add scan)?但这不是本问题的范围。 由于操作风险高,建议参考Oracle官方文档或寻求Oracle支持。 但是,用户的问题只是清除节点1上的SCAN IP,我们可能不需要停止整个集群,因为SCAN VIP可以迁移。我们可以尝试: 1. 停止SCAN监听器(因为SCAN监听器依赖于SCAN VIP): # srvctl stop scan_listener 2. 停止SCAN VIP资源(注意:有三个SCAN VIP,我们可以一个一个操作): 首先,查看当前SCAN VIP分配在哪些节点: # crs_stat -t | grep scan 假设节点1上运行了其中一个SCAN VIP(例如scan1),那么停止它: # srvctl stop scan -i 1 # 停止scan1 然后,使用ifconfig检查bound0:1是否还存在该IP,如果存在,手动删除: # ifconfig bound0:1 down # ifconfig bound0:1 del <scan_ip> 3. 然后,我们可以将scan1资源从节点1上移除(实际上,停止后集群会尝试在其他节点启动它,所以我们不需要手动移除资源,只需要确保它不在节点1上运行)。但是,如果我们希望永久禁止scan1在节点1上运行,可以通过修改资源依赖关系?这通常不需要,因为集群会自动选择节点。 4. 最后,重新启动scan1(让它运行在其他节点): # srvctl start scan -i 1 但是,这样操作后,节点1上的SCAN IP应该被清除了,并且该SCAN IP会转移到其他节点。 然而,Oracle并不支持手动移动SCAN VIP,而是由集群自动管理。所以,我们可能不应该手动干预。 综上所述,最安全的方法是:不要手动清除,而是使用集群命令停止和启动SCAN资源,让集群自动管理绑定。如果确实需要清除节点1上的绑定,可以重启节点1的集群服务(这会导致所有资源包括SCAN VIP迁移到其他节点),然后手动删除残留的IP绑定(如果有)。 步骤(针对节点1): 1. 以root用户执行: # crsctl stop crs # 停止节点1的集群服务 2. 检查网络接口,如果bound0:1上还有SCAN IP,则: # ifconfig bound0:1 down # ifconfig bound0:1 del <scan_ip> # 或者使用ip addr del命令 3. 然后,启动节点1的集群服务: # crsctl start crs 这样,节点1重新加入集群,但SCAN VIP可能不会绑定到节点1(因为集群会重新分配,可能分配到其他节点)。这样,节点1上的SCAN IP就被清除了。 但是,请注意:这个方法会短暂停止节点1上的所有集群资源,包括数据库实例等。因此,应在维护窗口进行。 最后,我们提供一种更精确的方法:使用srvctl停止特定的SCAN VIP(如果它运行在节点1上)并手动删除IP绑定,然后让集群自动在其他节点启动它。这样不会影响整个节点。 步骤: 1. 确定运行在节点1上的SCAN VIP资源。使用: # crs_stat -t | grep .scan 或者 # crsctl status resource -t 找到类型为ora.scan<number>.vip的资源,并查看它当前运行在哪个节点。假设我们发现scan1运行在节点1上。 2. 停止这个SCAN VIP资源: # srvctl stop scan -i 1 # 停止scan1 注意:停止后,集群会尝试在其他节点启动它(如果配置了多个节点)。如果只有一个节点,则无法启动。 3. 停止后,在节点1上检查IP绑定是否已经解除。如果没有,手动解除: # ifconfig bound0:1 down # ifconfig bound0:1 del <scan_ip> # 具体IP地址根据配置 4. 然后,我们可以重新启动这个SCAN VIP(让它自动分配到其他节点): # srvctl start scan -i 1 5. 检查它是否在其他节点运行。 但是,根据Oracle的文档,srvctl stop scan -i 1会停止该SCAN VIP,并且集群会立即尝试在其他节点启动它(如果集群配置允许)。因此,我们可能没有时间手动删除IP绑定,因为集群会自动在其他节点绑定IP,而在原节点解除绑定。 所以,通常不需要手动删除IP绑定,集群会自动处理。 因此,如果用户发现节点1上仍然有SCAN IP绑定,可能是因为集群没有正确清理(比如异常终止)。那么,我们可以手动删除该IP绑定,然后重启集群服务(如果必要)。 结论: 正常情况下,使用srvctl停止SCAN VIP资源后,节点上的IP绑定会自动解除。如果由于某种原因没有解除,可以手动删除。 因此,步骤为: 1. 停止节点1上运行的SCAN VIP资源(使用srvctl stop scan -i <scan_number>,其中<scan_number>是运行在节点1上的SCAN VIP的序号)。 2. 如果IP绑定没有解除,使用ifconfig手动删除bound0:1上的IP(注意:bound0:1是别名接口,删除后不会影响主接口)。 3. 然后,重新启动该SCAN VIP资源(srvctl start scan -i <scan_number>),让它在其他节点运行。 这样,节点1上的SCAN IP就被清除了。 但是,请注意:在操作前,确保有另一个节点可以托管该SCAN VIP(即集群中有多个节点可用)。 如果用户的环境是两节点,而SCAN VIP有三个(这是不可能的,因为只有两个节点,所以只能托管两个SCAN VIP)?实际上,在11g R2中,SCAN VIP的数量建议为三个,但集群中节点数量可以少于三个。在这种情况下,多个SCAN VIP会运行在同一个节点上(但每个节点最多一个SCAN VIP?)。所以,如果节点1上运行了一个SCAN VIP,停止后,集群会将它迁移到另一个节点(即使另一个节点已经有一个SCAN VIP,因为一个节点可以运行多个VIP,只要IP不同)。 因此,上述操作是可行的。 注意:在操作过程中,客户端连接可能会短暂中断。 最后,我们提供完整的步骤: 步骤1:确定节点1上运行的SCAN VIP # crsctl status resource -t | grep -E "ora\.scan.*\.vip" | grep <node1_name> 或者使用: # srvctl status scan -v # 显示每个SCAN VIP运行的节点 步骤2:假设节点1上运行的是scan1(即第一个SCAN VIP),则停止它: # srvctl stop scan -i 1 步骤3:检查节点1上bound0:1接口是否还绑定着该SCAN IP: # ifconfig bound0:1 # 或者使用ip addr show bound0:1 如果仍然显示该IP,则手动删除: # ifconfig bound0:1 del <scan_ip> 或者使用ip命令: # ip addr del <scan_ip>/<netmask> dev bound0:1 步骤4:重新启动scan1: # srvctl start scan -i 1 步骤5:验证scan1是否在另一个节点运行: # srvctl status scan -i 1 步骤6:验证节点1上bound0:1接口是否不再有该IP。 注意:如果用户的环境中有多个SCAN VIP运行在节点1上,则需要重复步骤2-4。 但是,通常一个节点不会运行多个SCAN VIP(除非集群节点数不足三个)。所以,我们只需要处理运行在节点1上的SCAN VIP。 然而,用户的问题描述中只提到清除节点1的SCAN IP,并没有指定是哪个SCAN IP。所以,我们假设需要清除所有在节点1上的SCAN IP绑定。 因此,我们可能需要对每个运行在节点1上的SCAN VIP执行上述步骤。 最后,我们生成相关问题。</think>### 清除 Oracle 11g RAC 节点1的 SCAN IP(绑定接口 bound0:1) #### 操作步骤 1. **停止 SCAN 监听器**(以 root 用户执行): ```bash srvctl stop scan_listener ``` 这将停止所有 SCAN 监听器服务[^1]。 2. **停止 SCAN VIP 资源**: ```bash srvctl stop scan ``` 该命令会解除所有 SCAN IP 的绑定(包括节点1的 bound0:1 接口)。 3. **手动清除残留 IP**(针对 bound0:1 接口): ```bash ifconfig bound0:1 down # 禁用接口 ifconfig bound0:1 del <SCAN_IP> # 删除指定 SCAN IP ``` 需替换 `<SCAN_IP>` 为实际的 SCAN IP 地址(可通过 `ifconfig -a` 查看)。 4. **重启集群服务**(节点1): ```bash crsctl stop crs # 停止集群服务 crsctl start crs # 重新启动服务 ``` 集群会自动重新分配 SCAN VIP,但 bound0:1 上的残留 IP 已被清除。 5. **验证结果**: ```bash ifconfig bound0:1 # 检查 IP 是否已移除 srvctl status scan # 确认 SCAN VIP 在其他节点正常运行 ``` #### 关键注意事项 1. **维护窗口操作**:此操作会导致短暂的服务中断。 2. **接口名称**:`bound0:1` 是绑定接口的别名,需确保名称与系统配置一致。 3. **备份配置**:操作前备份网络配置文件(如 `/etc/sysconfig/network-scripts/ifcfg-bound0:1`)。 4. **SCAN 特性**:SCAN VIP 由集群自动管理,手动清除后无需重新配置,集群会将其迁移到其他节点[^1]。 > ⚠️ **重要提示**:若 SCAN IP 仍自动绑定,检查集群配置: > ```bash > srvctl config scan # 查看 SCAN 配置 > srvctl modify scan -k # 永久删除无效配置(需 Oracle 支持确认) > ``` --- ### 相关问题 1. **如何预防 SCAN IP 绑定到错误接口?** 2. **Oracle RAC 中 SCAN 和普通 VIP 的区别是什么?** 3. **11g RAC 迁移到 19c 时 SCAN 配置需要哪些调整?** [^1]: Oracle 官方文档指出 SCAN VIP 由集群服务动态管理,手动干预需确保集群状态一致。参考 `srvctl` 命令指南。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值