0
点赞
收藏
分享

微信扫一扫

Oracle高可用就是救命的稻草,上线前一定要测好了!


📢📢📢📣📣📣
作者:IT邦德
中国DBA联盟(ACDU)成员,10余年DBA工作经验,
Oracle、PostgreSQL ACE
博客专家及B站知名UP主,全网粉丝10万+
擅长主流Oracle、MySQL、PG、高斯及Greenplum备份恢复,
安装迁移,性能优化、故障应急处理


文章目录

  • 前言
  • 1. RAC VIP故障转移掉链子
  • 1.1 故障现象
  • 1.2 故障排查
  • 2. RAC SCANIP负载均衡掉链子
  • 2.1 故障现象
  • 2.2 故障排查
  • 3.RAC IP配置注意要点
  • 3.1 scanIP参数的正确配置
  • 3.2 VIP参数的正确配置
  • 4.总结


前言

由于机房异常掉电,造成Oracle集群单节点down机,结果配置的Oracle高可用由于没有配置正确,尽然掉链子,分享一些案例给大家

1. RAC VIP故障转移掉链子

RAC Failover指集群中任何一个节点的故障都不会影响用户的使用,连接到故障节点的用户会被自动转移到健康节点,从用户感受而言, 是感觉不到这种切换。

1.1 故障现象

RAC集群,主节点down机后,
发现配置的VIP故障转移掉链子了?
java.sql.SQLRecoverableException:
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not existLinux-x86_64
Error: 2: No such file or directoryAdditional
information: 5291Additional information: -1213915437

Oracle高可用就是救命的稻草,上线前一定要测好了!_监听器

1.2 故障排查

Oracle RAC 的Failover 可以分为3种:
1.Client-Side Connect time Failover
2.TAF
3.Service-Side TAF

在这里我们用了TAF这种机制,所谓TAF,就是连接建立以后,
应用系统运行过程中,如果某个实例发生故障,
连接到这个实例上的用户会被自动迁移到其他的健康实例上。
对于应用程序而言,这个迁移过程是透明的,不需要用户的介入,
当然,这种透明要是有引导的,因为用户的未提交事务会回滚

以下是正确的配置
RAC =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))
(LOAD_BALANCE=YES)
(FAILOVER=ON)
(
CONNECT_DATA=
(SERVER=DEDICATED)
(SERVICE_NAME=RAC)
(
FAILOVER_MODE=
(TYPE=session)
(METHOD=basic)
(RETRIES=180)
(DELAY=5)
)
)
)
DELAY 和 RETRIES:
这2个参数分别代表重试间隔时间和重试次数。

–jdbc应用端的连接
jdbc:oracle:thin:@(DESCRIPTION =
(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip.luocs.com)
(PORT = 1521))(ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip.luocs.com)
(PORT = 1521))(LOAD_BALANCE = yes)(FAILOVER = on))
(CONNECT_DATA =(SERVER = DEDICATED)(SERVICE_NAME = luocs)))

注意事项:
最后排查发现,由于搭建ADG的时候,配置了静态监听导致
不能在listener.ora 文件中设置GLOBAL_NAME,
因为这个参数会禁用Connect-time Failover
和 Transparent Application Failover(TAF)

Oracle高可用就是救命的稻草,上线前一定要测好了!_DNS_02

2. RAC SCANIP负载均衡掉链子

2.1 故障现象

现象:通过scanIP连接数据库报错
ORA-12514: ORA-12514:
TNS:listener does not currently know
of service requested in connect descriptor

–以下是配置信息
RACSCAN =
(DESCRIPTION =
(ADDRESS_LIST =
(LOAD_BALANCE=on)
(FAILOVER=on)
(ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = testdb)
)
)

2.2 故障排查

之前也是记得oracle官方有说明使用/etc/hosts只能解析一个scan ip地址
《Grid Infrastructure Single Client Access Name (SCAN) Explained (Doc ID 887522.1) 》截图如下:

Oracle高可用就是救命的稻草,上线前一定要测好了!_SQL_03

Oracle高可用就是救命的稻草,上线前一定要测好了!_SQL_04

在没有配置DNS的情况下,
客户端连接RAC配置负载均衡就会掉链子
其实,SCAN VIP数量和节点数是没有任何关系的,
SCAN VIP会落到哪个节点上都是随机的

这里重点说一下DNS解析SCAN方式
使用DNS解析SCAN的时候,DNS服务器会采用rr(round-robin)
的方式循环解析为它准备的多个IP地址

所以记住,千万别在/etc/hosts配置多个SCANIP
一定要配置dns来解析多个SCANIP地址
这是不规范的部署方式

首先由DNS服务器解析SCAN名称,DNS服务器返回SCAN对应的3个IP地址的列表,客户端会选择使用其中一个SCAN VIP地址作为连接地址,将命名方法解析后的连接信息发送到SCAN VIP对应的SCAN Listener上,SCAN Listener通过负载均衡机制再把请求转发给比较空闲的服务器上的本地监听器,由本地监听器完成实例与客户端之间的连接。

Oracle高可用就是救命的稻草,上线前一定要测好了!_SQL_05

3.RAC IP配置注意要点

3.1 scanIP参数的正确配置

通过scanIP连接数据库报错ORA-12514:
ORA-12514: TNS:listener does not
currently know of service requested in connect descriptor

–解决办法
查看scan listener状态,发现服务没有注册成功导致:
配置remote_listener参数为空,配置即可
SQL> alter system set
remote_listener = ‘rac-scan:1521’;
SQL> alter system register;

REMOTE_LISTENER :

同LOCAL_LISTENER是Oracle的参数,

通过这个设置,任何实例都会向SCAN监听器注册,

所以SCAN监听器能够负载均衡地分发连接请求到节点本地监听器上,

也就是连接到其本地节点上实例上。

Oracle高可用就是救命的稻草,上线前一定要测好了!_监听器_06

3.2 VIP参数的正确配置

–连接RAC VIP报错
receives a connection refused error
(ORA-12541) instead of waiting for long TCP connect timeout messages.
This error causes the client to quickly move on to the next address

--如果你的RAC VIP不能连接,解决办法
SQL> show parameter local

NAME                    TYPE        VALUE
------- ----------- -------------------
local_listener         string      
parallel_force_local   boolean     FALSE

注意:RAC的local_listener处为VIP的连接

SQL> alter system set
local_listener = ‘rac-vip1:1521’ SCOPE=MEMORY SID=‘RAC1’;
SQL> alter system set
local_listener = ‘rac-vip2:1521’ SCOPE=MEMORY SID=‘RAC2’;
SQL> alter system register;
LOCAL_LISTENER设置为向本地VIP地址进行注册,由于本地监听器是在本地的PUBLIC IP和VIP上监听,所以向VIP监听注册就能保证成功向本地监听器注册。

4.总结

高可用是故障发生的第一个救命的稻草,系统上线前一定要测试好,才能确保数据库的高可用


举报

相关推荐

0 条评论