Failover pres JDBC na Oracle SE

Čtvrtek Březen 19 01:10:51 CET 2009

Dobry den,
kedze to co chcete riesit zahrna komplexnejsiu sadu Oracle technologii  
trochu sa rozpisem :) a uvediem toho viac.
Neuviedol ste o ktoru verziu Oracle DB by sa malo jednat, preto uvediem 
informacie aj pre 10GR2 a takisto aj pre 11gR1.

Uvodom vas hned trochu sklamem pretoze ak chcete vyuzivat technologiu 
Oracle Data Guard resp. Active Data Guard vo verzii 11gR1 jedna sa o 
plateny option Enterprise Edicie, co teda inymi slovami znamena ze okrem 
toho ze musite mat zakupenu licenciu enterprise ( a teda aj viac licenci 
pre multi site deployment) tak musite mat tiez zakupeny aj tento option.
http://www.oracle.com/database/product_editions.html

Ak sa teda prenesieme cez tento "detail" a aj napriek tomu sa rozhodnete 
pokracovat v navrhu takehoto riesenia, tak je vhodne pouvazovat co 
skutocne od takehoto riesenia ocakavate, kedze ulohou Data Guard je 
primarne ochranit pred "site failure".   Len pre vysvetlenie, Oracle ma 
viacero technologii pre hi-availability na urovni DB pricom kazda riesi 
nieco ine
RAC (real application cluster ) - Computer (server) Failure
ASM (automatic storage management) -  Storage Failure
Flashback - Human Errors
RMAN, Oracle HARD - Corruption
Data Guard - Site Failure

Ak teda chceme riesit site failure resp. je pre nas lakava moznost 
replikacie DB a pokracujeme dalej, tak je dobre vediet akym sposobom 
planujete vykonavat replikaciu kedze:
Pre 10G mozete mat
Physical standby -  funguje na baze blok-blok replikovania recovey dat 
(vytusil som ze zrejme mate umysel pouzivat tento typ replikacie) 
nevyhodou physical stanby vo tejto verzii DB je ze standby DB je "len" v 
mount rezime, a bez switch overu, resp. failoveru nad nou nedokazete s 
vynimkou recovery resp. read only otvorenia robit nic.
Logical standby - tato replikacia funguje na baze "prehravania" sql dat, 
ktore ziskava logminer z recovery dat, jej havnou nevyhodou je ze 
nedokazete replikovat vsetky datove objekty ale na druhej strane standby 
db je v read only mode, takze uz minimalne reportovanie je mozne robit 
aj na strane standby.

Pre 11G
je physical stanby uz aj na strane standby DB otvorena v read only mode 
takze situacia je lepsia. Predpokladam teda ze by ste sa rozhodol pre 
11gR1 physical standby
viac info.
http://download.oracle.com/docs/cd/B28359_01/server.111/b28294/whatsnew.htm#sthref8

Uvediem este dalsie riziko, ktore moze mat nasledky pri "automatickom 
prepnuti" na strane klienta,  skor nez prejdeme ku klientskej konfiguracii.
Prvou vecou je aky sposob " Data Protecion mode" by ste chcel aby Data 
Guard zabezpecoval, pretoze moze byt
maximum protection - jedna sa o synchronny zapis redo dat  na primarnej 
a aspon na jednej sekundarnej standby DB, v pripade ze sa tak nestane 
tak primarna DB ide dole.  Inymi slovami transakcia moze byt commitnuta 
az vtedy ked su redo data zapisane na oboch stranach (a teda ak mate na 
strane klienta nastaveny "popularny" AUTOCOMMIT=true, nebudete sa stacit 
cudovat co sa (ne)bude diat).
maximum availability - jedna sa o synchronny zapis redo dat  na 
primarnej a aspon na jednej sekundarnej standby DB , V pripade ze 
nedojde k zapisu redo dat vsak DB nezleti dole.
maximum performance - asynchronny zapis, transakcia moze byt commitnuta 
tak skoro ako su data zapisane v lokalnom redo logu. Tu uz vsak ideme do 
rizika ze replikacia sa sprava asynchronne s urcitymi oneskoreniami, 
resp. ak dosledne riesime site failure, tak ideme do rizika ze prideme o 
urcite data.

Podtrhnute a zhrnute, logicky by ste sa teda asi rozhodol kvoli 
performance pre rezim maximum performance, ale pokial by fakt doslo k 
vypadku site, tak sa moze stat ze nebudete mat 100% replikovany stav a v 
tomto pripade failover  ( a nasledne automticke prepnutie middleware) 
nebude transparente. Ale pokial to co s tym planujte robit zrovna nie je 
napr. bankovy system, tak je to mozno pre vas akceptovatelne riziko, na 
druhej strane pri investovani nemalych prostriedkov do vystavby takehoto 
riesenia mi pride fakt ze stratim nejake data, ako nieco co by mi aj 
vadilo bez ohladu co na tom pobezi.

Prichadzame teda k tomu co mozeme urobit na strane klientskej aplikacie.
Riesenie je zastresene viacerymi oracle technologiami, ktore sa daju 
navyse skombinovat, uvediem ich nazvy plus odkazy do dokumentacie a tak 
trochu to tu priblizim (ked uz tu robim take male pr pre Oracle :)

TAF (transparent application failover)
http://download.oracle.com/docs/cd/B28359_01/network.111/b28316/advcfg.htm#i476388
resp.
http://download.oracle.com/docs/cd/B28359_01/network.111/b28316/advcfg.htm#i480772   
(Example: TAF Pre-Establishing a Connection)

tento sposob sa da nakofigurovat ako pre oci tak pre thin jdbc driver.  
Pri oci je vsak zaznam v tnsnames.ora a v jdbc url pouzivame len alias.
Pre vas zamer by potom napr. s vyuzitim oci drivera mal tns zaznam 
vyzerat nasledovne:

sales_alias =
 (DESCRIPTION=
  (ADDRESS=
       (PROTOCOL=tcp)  
       (HOST=sales1-server)  
       (PORT=1521)) 
  (CONNECT_DATA=
     (SERVICE_NAME=sales.us.example.com) 
     (INSTANCE_ROLE=primary) 
     (FAILOVER_MODE=
       (BACKUP=sales2.example.com) 
       (TYPE=select) 
       (METHOD=preconnect))))

Dalsou moznostou nevyuzivajucou primo TAF je tiez nasledovna 
konfiguracia, ktora vsak moze priniest problemy ak primany site je dole 
nie kvoli switchoveru.

sales_alias =
 (DESCRIPTION=
  (ADDRESS_LIST=
    (|SOURCE_ROUTE=on)|
    (LOAD_BALANCE=off)
    (ADDRESS=(PROTOCOL=tcp)(HOST=primary-server)(PORT=1521))
    (ADDRESS=(PROTOCOL=tcp)(HOST=secondary-server)(PORT=1521)))
  (CONNECT_DATA=
    (SERVICE_NAME=sales.us.example.com)))

tie dve options znamenaju podla dokumentacie nasledovne
Use each address in order until destination reached -  SOURCE_ROUTE=on
Use only the first address -  LOAD_BALANCE=off

Vyssie uvedene metody vsak mozu prinest problemy pre middleware v 
priapde pouzivania connection poolov, pretoze po switchoveri zostanu v 
nom nevalidne connecty o ktorych sa dozvieme az ked ich aplikacia 
pouzije (a uvidime spustu exceptions v logoch).
Toto sa da eliminovat pomocou Fast Connection Failover.
http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/fstconfo.htm#CIHJBFFC
Primarne urcenie je hlavne pre RAC ale nevidim technicky problem v tom 
ze by sa to nedalo nasetupovat aj pre Data Guard.
Tu sa vyuziva ONS (oracle notification service), ktory propaguje event 
smerom na jvm kde mame pool spojeni, ktore su nasledne revalidovane.
Mne osobne sa vsak tento sposob zda uz trochu pracny pretoze ons musi 
byt nakonfiguravny a bezat aj na strane middleware, a pokial zrovna 
nepouzivame Oracle IAS (kde to uz je by default aspon nainstalovane) tak 
je to nie je az take easy.

Ak ste nestratili trpezlivost a docitali ste sa az sem,
tak dufam ze som vam aspon trochu pomohol.
Riso.

Lukas Zapletal  wrote / napísal(a):
> Zdravim konferenci,
>
> zajimalo by me, jestli JDBC ovladac pro Oracle (a pokud ano tak ktery) 
> umi fail over na STANDARD EDITION databazi, ktera je replikovana pres 
> redo logy na standby backup instanci.
>
> Tzn. jestli lze do URL napsat neco jako server1;server2 a v pripade ze 
> se server2 stane "master" (administrator to prehodi), tak se JDBC 
> automaticky prepne na novy server.
>
> Samozrejme s nejakym tim vypadkem (stavajici connections spadnou a 
> provede se reconnect), neocekavam od toho, ze by to fungovalo jako 
> RAC. Jde mi o "levne" reseni postavene na standard edicich. Jestli to 
> zkratka lze nejak pomoci JDBC vyresit, nebo to je treba resit v aplikaci.
>
> Diky za rady
>

------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://amaio.cz/pipermail/konference/attachments/20090319/db472e26/attachment.htm>
------------- další část ---------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4902 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://amaio.cz/pipermail/konference/attachments/20090319/db472e26/attachment.bin>