在rac+dataguard的环境中,为了减少应用宕机时间及改动,提高业务的可用性,要求jdbc客户端配置failover。同时为了很好地做应用分割,又不能load balance。
即在第一个实例不行时,去偿试第二个实例,两个实例都不行时,去偿试data guard。这样的目的看起来简单,其实有些细小的地方值的注意。
下面是一个配置的例子:
jdbc:oracle:thin:@(description=
(ADDRESS_LIST =
(LOAD_BALANCE=OFF)(FAILOVER=ON)
(ADDRESS = (PROTOCOL = TCP)(HOST = x)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = y)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = z)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = aaaa)
(failover_mode=(type=select)(method=basic))
)
)
其中host x和host y是rac的两个instance的service ip
z是data guard的ip地址。
这种配置在,应用在第一个实例连不上的情况下(包括主机宕掉;监听宕掉;实例宕掉但监听不宕掉三种情况)会去偿试第二个实例,第二个实例也连不上的情况下会去偿试第三个。
这里有几点需要注意:
1。为了达到实例宕掉,但监听不宕的情况下也行,监听需要全部是动态注册的,不允许静态配置的service name。这个理由很明显。因为动态注册的话,当instance宕掉后,其service name就会从监听中消失,此时应用才会去偿试第二个IP地址。如果有静态配置的话,则由于监听是可以接受客户端的请求,将不会去偿试第二个IP地址,而是报出oracle not available的错误。
2.data guard的监听配置两个,平时启着1526端口,用于归档日志的传输,当需要切到data guard时,才将1521端口起来。这样会防止某些情况下,应用连接到data guard上面来。
3.不能设置remote_listener参数,否则会发生监听层面的load balance。同时在配置中需要将load_balance设为no或false,以防止发生client 层面的load balance。
ref:
http://logzgh.itpub.net/post/3185/291989
[@more@]来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/350519/viewspace-1051468/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/350519/viewspace-1051468/