Re: Failover pres JDBC na Oracle SE

[Richard Holly]

Dobry den,




http://www.oracle.com/database/product_editions.html


RAC (real application cluster ) - Computer (server) Failure
ASM (automatic storage management) -  Storage Failure
Flashback - Human Errors
RMAN, Oracle HARD - Corruption
Data Guard - Site Failure


Pre 10G mozete mat


Pre 11G

viac info.
http://download.oracle.com/docs/cd/B28359_01/server.111/b28294/whatsnew.htm#sthref8





Prichadzame teda k tomu co mozeme urobit na strane klientskej aplikacie.


TAF (transparent application failover)
http://download.oracle.com/docs/cd/B28359_01/network.111/b28316/advcfg.htm#i476388
resp.

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. 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 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: 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. 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 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. 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 :) http://download.oracle.com/docs/cd/B28359_01/network.111/b28316/advcfg.htm#i480772 (Example: TAF Pre-Establishing a Connection)

sales_alias =
(DESCRIPTION=
 (ADDRESS=







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


Toto sa da eliminovat pomocou Fast Connection Failover.
http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/fstconfo.htm#CIHJBFFC


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):

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: (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. 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). 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.

Zdravim konferenci,







Diky za rady

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.

smime.p7s
Description: S/MIME Cryptographic Signature