Voici une fonctionalité très puissante et souvent mal connue du driver Oracle : son support puissant des URL de connexions.

Classiquement, quand on veut de la haute disponibiltié en Oracle, on utilise deux technologies :

• Oracle RAC (Real Application Clusters) : clustering actif/actif
• Oracle Dataguard : clustering actif/passif avec possibiltié d’avoir le passif en actif read-only

Je ne vais pas expliquer en détail ces technologies, car je ne suis pas spécialiste Oracle ni base de données, mais, en tant que développeur, vous présenter comment configurer votre URL de connexion Oracle pour tirer partie de ces technologies. Je vais me baser sur une installation Dataguard classique en actif/passif.

1. JDBC standard :

Une URL de connexion Oracle standard en JDBC est de la sorte :

jdbc:oracle:thin:username/password@dbhost:dbport:instance

Le problème ici, est que le host et le port de la base de données sont en dur dans l’URL. Ce qui fait qu’en cas de switch actif/passif sur votre Dataguard, il faudra reconfigurer votre application et la redémarrer.

Une solution à ça, est l’utilisation d’un listener centralisé (une base Oracle a un listener pour éctouter les connexions, on peut utiliser un listener unique pour toutes les bases d’une entreprise qui se situe sur un serveur dédié et dont le rôle ne sera que d’écouter les connexions puis de faire le lien vers la base demandé : c’est le listener centralisé) sur lequel la base va s’enregistrer et celà va permettre d’abstraire le nom réel de la machine ainsi que son port.

2. Listener centralisé avec nom de service

jdbc:oracle:thin:username/password@listenerhost:port:@servicename

Ici, on ne connait plus le nom de la machine physique ni celui de l’instance de BDD mais juste un nom de service que le listener va résoudre en tant qu’host:port:instance. Ce sera alors la responsabilité du DBA de switcher la base de données au sein du listener en cas de bascule de Dataguard (ce qui est faisable en automatique).

3. Listener centralisé en loadbalancing

Pour plus de haute dispo, le DBA peut installer deux listener centralisés et faire du loadbalancing/failover entre eux (via un HAProxy ou un F5 par exemple).

Mais que faire quand on a deux datacenter étanche sur lesquels on ne peut pas créer de loadbalancing … et voici la solution, l’utiliation d’une URL spécifique permettant de faire du loadbalancing client !

4. Laodbalancing client, setup multidatacenter

jdbc:oracle:thin:@(description=(address_list=(address=(protocol=tcp)(port=port1)
(host=listenerhost1))(address=(protocol=tcp)(port=port2)(host=listenerhost2)))
(connect_data=(SERVICE_NAME=servicename))(LOAD_BALANCE=ON)(FAILOVER=ON))

Beaucoup de chose dans cette URL :

• On a une liste d’addresse (address_list) pour pouvoir mettre plusieurs listener : ici listenerhost1:port1 et listenerhost2:port2
• On a le service de notre base de données tel que connu par le listener : ici servicename
• On a des options de haute disponibilité : LOAD_BALANCE=ON et FAILOVER=ON  qui permettent de faire du loadbalancing entre les deux listener et de faire du failover (une demande de connexion vers un listener qui ne fonctionne plus sera automatiquement ré-envoyé vers un autre)

On peut imaginer utiliser cette URL pour remplacer un loadbalancer serveur ( de type HAProxy ou F5) ou en complément. Via cette URL on peut donc configurer notre application pour être en haute dispo (multi-datacenter si nécessaire) vers nos base de données (via listener centralisé). En cas de crash, ce sera au DBA de basculer la dataguard et automatiquement notre application se connectera sur le nouveau actif.

Pour plus d’info, la doc du driver Oracle au sujet des URL JDBC : http://docs.oracle.com/cd/B19306_01/java.102/b14355/jdbcthin.htm