ÇözümPark'a hoş geldiniz. Oturum Aç | Üye Ol
 
Ana Sayfa Makale Video Forum Resimler Dosyalar Etkinlik Hizmetlerimiz Biz Kimiz

Oracle

Oracle 11.2 Veritabanında Maksimum Erişilebilirlik Mimarisinin Yapılandırması

 

Bu yazıda Oracle 11.2 Dataguard ve RAC kombinasyonunda maksimum erişilebilirlik mimarisinin nasıl yapılandırılacağını inceleyeceğiz. İlk önce Fast-Start-Failover işlemi ile Dataguard mimarisinde kesintisiz veri iletişiminin nasıl sağlanacağını açıklayacağım, ardından iki farklı servis kullanarak primary RAC kümesine yazma(INSERT/UPDATE/DELETE) işlemi yapacak bir servisin, fiziksel standby RAC kümesine ise salt okuma işlemi yapacak olan diğer bir servisin yapılandırmasını bir örnekle adım adım açıklayacağım. Son bölümde ise Oracle 11.2 Dataguard RAC kümesine veri transferi yapan middle-tier uygulama sunucularının kullandığı JDBC bağlantılarında maksimum erişilebilirliği sağlayacak olan yapılandırmayı adım adım bir örnekle açıklayacağım.

 

Yazıya başkarken Oracle 11.2 mimarisinde kullanılan Fast-Start-Failover özelliğinin ne anlama geldiğini inceleyelim. Fast-Start-Failover özelliği, primary veritabanına bağlantı kaybolduğu durumlarda daha önceden seçilen fiziksel standby veritabanına Data Guard Broker prosesinin otomatik olarak bağlantı kurmasıdır.  Fast-Start Failover özelliği sadece Data Guard Broker yapılandırması içinde kullanılır ve DGMRL komut satırı veya Enterprise Manager konsolu üzerinden etkinleştirilir.

 

Fast-Start-Failover hizmeti hem maksimum erişilebilirlik, hemde maksimum performans modunda çalışabilmektedir.Maksimum erişilebilirlik modu seçili olduğunda sıfır veri kaybı garanti edilmektedirMaksimum performans modu seçili olduğu durumda ise FastStartFailoverLagLimit konfigürasyon parametresi ile belirlenen saniye içerisindeki veriden daha fazlasının kaybı önlenmiş olmaktadır.

 

Herhangi bir failover durumunda broker’ın kesintisiz çalışmasını sağlamak için, gözlemciyi(observer) primary ve standby veritabanları dışında bir makineye kurmak faydalı olacaktır. Hem Dataguard Broker, hemde standby veritabanı primary veritabanı ile bağlantıyı FastStartFailoverThreshold parametresinde belirlenen süreden daha uzun sürede kaybettiği zaman, broker standby veritabanına doğru fast-start failover işlemini tetikler. Buna ilaveten, eğer FastStartFailoverPmyShutdown parametresi TRUE olarak ayarlanmışsa, FastStartFailoverThreshold parametresindeki süreden daha uzun süreli kesinti durumunda primary veritabanı kapatılır.



Bunun sebebi, redo taşıması ile standby ile primary arasında muhtemel oluşabilecek redo boşluklarının önüne geçmektir. Çünkü oluşabilecek muhtemel redo boşluklarında fast-start failover işlemi en iyimser durumda uzayacak, en kötü durumda işlem başarısız olacak ve standby sunucunu bütünlüğünü kaybederek yeniden oluşturulma ihtiyacı duyacaktır. FastStartFailoverAutoReinstate parametresi TRUE olarak ayarlandığında ise, failover işlemi tamamlandığında eski primary veritabanına bağlantı tekrar sağlandığında eski primary veritabanı standby veritabanı durumuna getirilmiş olacaktır.

 

 

image001

 

 

Uygun koruma modunun belirlenmesi

 

Eğer maksimum erişilebilirlik özelliğinin etkin olması isteniyorsa bu durumda standby veritabanının LogXptMode parametresinin SYNC değerini işaret etmesi gerekmektedir. Maksimum performans modunun etkin olması için ise durumda standby veritabanının LogXptMode parametresinin ASYNC değerini işaret etmesi gerekmektedir.

 

DGMGRL> EDIT DATABASE ’orclprm’ SET PROPERTY LogXptMode=SYNC;

DGMGRL> EDIT DATABASE ’orclstd’ SET PROPERTY LogXptMode=SYNC;

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxAvailability;

 

Eğer minimal veri kaybından ziyade performans düşünmekteyseniz o zaman maksimum performans modunu etkinleştirmek yeterli gelecektir. Ancak, bu mod etkinleştirmeden önce ne kadar süre içerisindeki veri kaybı kabul edilir miktardır, bunu belirlemeniz gerekmektedir. İşte bu süreyi FastStartFailoverLagLimit parametresi ile düzenleyebilirsiniz.Bu özellik, saniye değeri olarak, primary veritabanından etki eden redo miktarından ne kadar geride gecikme olacaktır, onu belirtmektedir. Bu parametre sadece maksimum performans modunda, yani standby veritabanında ASYNC aktif iken kullanılabilir, varsayılan değer 30 saniyedir. En fazla 10 saniye’ye düşürülebilir.

 

DGMGRL> EDIT DATABASE ’orclprm’ SET PROPERTY LogXptMode=ASYNC;

DGMGRL> EDIT DATABASE ’orclstd’ SET PROPERTY LogXptMode=ASYNC;

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxPerformance;

DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverLagLimit=15;

 

Fast-start failover işlemi, hem gözlemci(broker) hemde fiziksel standby sunucu primary sunucuya bağlantısını yitirdiğinde meydana gelir demiştik. İşte, ne kadarlık zaman sonra fast-start failover işlemi devreye girecek onu belirlemek için FastStartFailoverThreshold parametresini saniye değeri olarak ayarlanmalıdır. Bu parametrenin varsayılan değeri 30 saniyedir, en fazla 6 saniye’ye düşürülebilir. Eğer birden fazla düğümlü Oracle RAC veritabanı kullanıyorsanız bu değeri 40 saniyenin üstünde tutmanız tavsiye edilir, çünküOracle RAC instancelerından birisi bir anlık erişilemez olursa, istemedende olsa fast-start failover işlemi hemen devreye girecek ve standby RAC veritabanına failover meydana gelecektir.

 

DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = 45;

 

Fast-start failover işlemini etkinleştirmek için gözlemci makinede aşağıdaki komut çalıştırılır.

 

DGMGRL> ENABLE FAST_START FAILOVER;

Enabled.

 

DGMGRL> SHOW FAST_START FAILOVER;

Fast-Start Failover: ENABLED
  Threshold:           30 seconds
  Target:                 orclstd

  Observer:            (none)
  Lag Limit:           30 seconds
  Shutdown Primary:    TRUE
  Auto-reinstate:           TRUE

Configurable Failover Conditions
  Health Conditions:
    Corrupted Controlfile          YES
    Corrupted Dictionary           YES
    Inaccessible Logfile              NO
    Stuck Archiver                      NO
    Datafile Offline                    YES

 

Oracle Error Conditions:

(none)

 

Bunun yanında sağlık şartları olarak log dosyalarının erişilemez olması veya arşiv dosyalarının primary sunucuda sıkışması sorunlarında otomatik olarak fast-start failover meydana gelmez. Eğer bu özellikleride etkinleştirmek ve fast-start failover işlem alanına dahil etmek için ENABLE FAST_START FAILOVER CONDITION komutu kullanılır.

 

Bozulmuş kontrol dosyası tespit edildiğinde fast-start failover işleminin otomatik  devreye girmesini etkinleştirmek için;

 

DGMGRL> ENABLE FAST_START FAILOVER CONDITION "Corrupted Controlfile";

 

ORA-27102  olayı meydana geldiğinde fast-start failover işleminin otomatik  devreye girmesini etkinleştirmek için;

 

DGMGRL> ENABLE FAST_START FAILOVER CONDITION 27102;

 

Eğer gözlemci makine kullanılıyorsa aşağıdaki komutla observer servisi bu makined başlatılmalıdır.

 

DGMGRL> START OBSERVER;

 

Primary ve Fiziksel Standby veritabanlarında servisler ile kusursuz erişilebilirliğin sağlanması

 

Oracle 11.2 sürümü ile gelen SCAN(Single Class Access Name) hizmeti, küme içindeki her bir düğümün istemciler tarafından teker teker bilinmesine gerek duyulmadan, en optimal yükünün otomatik olarak DBA'ye ihtiyaç duymadan hesaplanması ve bu istemcinin en uygun düğüme yönlendirilmesini sağlayan prosesdir. Bu sayede istemci tarafındaki yük dengelemesi yönetimi DBA ler için ızdırap olmaktan çıkıp, clusterware tarafından otomatik olarak yönetilmektedir. Sunucu tarafındaki yük dengelemesi ise, talep edilen servis için en az yüklü instance bulmak amacıyla SCAN tarafından kontrol edilir ve bu düğümün lokal listenerına bu talep yönlendirilir.

 

Rol bazlı veritabanı servisleri, Oracle Clusterware veya Oracle Restart içerisinden yapılandırılır. Oracle Dataguard,  Oracle Clusterware veya Oracle Restart ile etkileşime geçerek primary-standby rol değiş tokuşu sonunda gerekli servislerin aktif olmasını sağlar, böylece sistemi başlatma olayı için herhangi bir trigger yazılmasınada gerek kalmaz.

 

Aşağıdaki örnekte 2 düğümlü RAC adlı primary veritabanında “HR_APP” adlı servis primary rolde aktiftir. 2 düğümlü RACSTD adlı standby veritabanında da “HR_REPORT” adlı servis ise raporlama hizmetleri yapmak üzere fiziksel standby rolünde aktiftir.

 

 

[oracle@linux1_rac] $ srvctl add service -d RAC -s HR_APP -l PRIMARY -q TRUE -e SELECT –m BASIC -w 10 -z 150

 

[oracle@linux1_rac] $ srvctl add service -d RAC -s HR_REPORT -l PHYSICAL_STANDBY -q TRUE –e SELECT -m BASIC -w 10 -z 150

 

 

Herhangi bir switchover/failover durumunda HR_APP servisinin primary olarak hizmet vermeye devam etmesi için RACSTD adlı standby veritabanındada aşağıdaki gibi servisler eklenmiştir.

 

[oracle@linux1_racstand] $ srvctl add service -d RACSTD -s HR_APP -l PRIMARY -q TRUE -e SELECT –m BASIC -w 10 -z 150

 

[oracle@linux1_racstand] $ srvctl add service -d RACSTD -s HR_REPORT -l PHYSICAL_STANDBY -q TRUE –e SELECT -m BASIC -w 10 -z 150

 

 

Fiziksel standby sunucuya redo taşıması yoluyla taşındığından emin olmak için “HR_REPORT” adlı servisin primary veritabanında SRVTL START SERVICE ile başlatılması ve ardından SRVCTL STOP SERVICE ilede durudurulması gerekmektedir.

 

 

[oracle@linux1_rac] $ srvctl start service -d RACSTD -s HR_APP

[oracle@linux1_rac] $ srvctl stop service -d RACSTD -s HR_APP

 

 

Herhangi bir Dataguard Failover işlemini takiben, Oracle Data Guard Broker hatalı primary veritabanına bağlantıları temizlemesi için otomatik olarak FAN(Fast Application Failover) olayı yayınlar. Olayın alımını takiben FAN alım aboneleri yeni primary veritabanında başlayan servise otomatik olarak yeniden bağlanırlar.

 

Kusursuz uygulama(application) failover işlemi disk arızası, data bozulması, donanımsal arıza, programın askıda kalması gibi oldukça sık maydana gelebilecek lokal arızalar durumunda oldukça elverişlidir. Kusursuz uygulama failover işleminde 3 ana parça vardır.

 

  • Yeni primary sitede/sunucuda servislerin yeniden başlatılması
  • Uygulamaları mevcut bağlantılarını sonlandırması için bilgilendirme
  • En elverişli şekilde uygulamaların yeniden bağlantı açmasını sağlama

 

Kusursuz uygulama failover işlemi için cluster ortamında Oracle Clusterware, tekil instance ortamında Oracle Restart olmalı ve her iki durumdada DataGuard Broker aktiveli Oracle DataGuard yapılandırmasına ihtiyaç duyulmaktadır.

 

JDBC uygulamalarında kusursuz application failover yapılandırması

 

 

Oracle veritabanına yapılan JDBC bağlantılarında kusursuz application failover işlemi için oluşturulacak olan servis hem primary hemde fiziksel standby sitede oluşturulmalıdırServislerin gerek normal çalışma durumunda primary sitede primary rolde işlem yapması, gerekse herhangi bir switchover/failover durumunda yeni primary rolüne geçen clusterdada primary rolde başlaması için primary ve standby cluster içinde ilgili servisleri oluşturuyoruz. Burda önemli olan nokta; sadece JDBC bağlantılarında kullanılacak olan servisleri oluştururken, TAF ve OCI HA olaylarını devredışı bırakmamız gerekmektedir (alttaki örneklerdeki kırmızı kısımlar).

 

 

Primary cluster içinde;

 

[oracle@linux1_rac] $ srvctl add service -d RAC -s HR_APP -r linux1_rac, linux2_rac -l PRIMARY -q FALSE -e NONE -m NONE -w 0 -z 0

 

[oracle@linux1_rac] $ srvctl add service -d RAC -s HR_REPORT -r linux1_rac, linux2_rac -l PHYSICAL_STANDBY -q FALSE -e NONE -m NONE -w 0 -z 0

 

 

Standby cluster içinde:

 

[oracle@linux1_racstand] $ srvctl add service -d RAC -s HR_APP -r linux1_racstand, linux2_racstand -l PRIMARY -q FALSE -e NONE -m NONE -w 0 -z 0

 

[oracle@linux1_racstand] $ srvctl add service -d RAC -s HR_REPORT -r linux1_racstand, linux2_racstand -l PHYSICAL_STANDBY -q FALSE -e NONE -m NONE -w 0 -z 0

 

JDBC bağlantısında maksimum erişilebilirliği sağlamak için kullanılacak olan servisleri oluşturduktan sonra HR_REPORT servisinin primaryden standby siteye redo taşımasını başlatması için primary sitede SRVCTL START SERVICE ile başlatılmalıdır.

 

[oracle@linux1_rac] $ srvctl start service -d RACSTD -s HR_APP

 

 

  • Oracle JDBC sürücüsü yüklenmelidir. Her bir site için SCAN adresi içerecek adres listesini taşıyacak olan bağlantı tanımlayıcısının kullanılması gerekmektedir. Aşağıdaki örnek HR_APP uygulaması içindir. Eğer raporlama içinde jdbc bağlantısı kullanılacaksa bu durumda HR_REPORT servisi içinde aşağıdaki gibi giriş oluşturulmalı ve yüklenmelidir.

 

 

"jdbc:oracle:thin:@" + "(DESCRIPTION_LIST=" +

"(LOAD_BALANCE=off)" + "(FAILOVER=on)" + "(DESCRIPTION=" + "(ADDRESS_LIST=" + "(LOAD_BALANCE=on)" + "(ADDRESS=(PROTOCOL=TCP)(HOST=rac-scan)(PORT=1521)))" + "(CONNECT_DATA=(SERVICE_NAME=hr­_app)))" + "(DESCRIPTION=" + "(ADDRESS_LIST=" + "(LOAD_BALANCE=on)" + "(ADDRESS=(PROTOCOL=TCP)(HOST=racstd-scan)(PORT=1521)))" + "(CONNECT_DATA=(SERVICE_NAME=hr_app))))";

 

 

JDBC URL üzerinden yapılan bağlantı sonrasında Oracle NET servisi DNS ile iletişime geçerek RAC primary sitesinin SCAN adresini toplam 3 IP adresine çözümler. Rastgele bir tanesini seçerek bağlantı sağlar.Eğer primary üzerine bağlantı başarısız olursa bu durumda RACSTD  standby sitesindeki SCAN üzerinden rastgele bir tanesi üzerinden bağlantı sağlar.

 

 

Eğer TCP_CONNTIMEOUT_STR özelliği ayarlanırsa, JDBC istemcisi çok kolay bir şekilde adres listesine taşınır.

 

 

Properties prop = new Properties();

prop.put(oracle.net.ns.SQLnetDef.TCP_CONNTIMEOU T_STR, ""+5000);  // 5000ms

pds.setConnectionProperties(prop);

 

Fast Connection Failover işlemini aşağıdaki adımlarda anlatıldığı şekilde aktive ediyoruz.

 

 

  • Bu işlem için ONS(Oracle Notification Services) tüm düğümlerde aktif olmalıdır. Tüm düğümlere ONSCTL PING komutuyla ping çekiyoruz ve ONS nin aktif olup olmadığını kontrol ediyoruz. ONSCTL PING komutunun cevap vermediği düğümlerde sırasıyla komutlarını çalıştırırak ONS servisini kuruyoruz.

 

 

 

$  srvctl add ons

$  srvctl enable ons

$  srvctl start ons

 

 

  • Eğer application tier ONS üzerinde çalışıyorsa cluster düğümlerini application ONS ye duyarlı hale getiriyoruz. ORA_CRS_HOME/bin/racgons dizini altından aşağıdaki komutu primary ve standby sitelerde yeni bir terminal penceresinde root hesabı ile oturum açarak çalıştırıyoruz.

 

 

 

# racgons.bin add_config linux1_rac:6200 linux2_rac:6200 linux1_racstand:6200 linux2_racstand:6200

 

 

  • Veri kaynağı üzerinde setFastConnectionFailoverEnabled(true) parametresi ile Fast Connection Failover işlemini ayarlayarak uygulamanın hem primary hemde standby sitedeki ONS bekletici programlarına(daemons) bağlanma işlemini tamamlıyoruz.

 

 

 

ods.setConnectionCachingEnabled(True);

Properties prop = new Properties();

prop.setProperty("MinLimit", "5");

prop.setProperty("MaxLimit", "40");

prop.setProperty("InitialLimit", "10");

ods.setConnectionCacheProperties(prop);

ods.setFastConnectionFailoverEnabled(True);

ods.setConnectionCacheName(MyCache”);

ods.setConnectionCacheProperties(cp);

ods.setONSConfiguration("nodes= linux1_rac:6200,linux2_rac:6200, linux1_racstand:6200,linux2_racstand:6200");

 

 

Umarım faydalı bir makale olmuştur.

Yorumlar

 

Ufuk TATLIDİL

Elinize saglık.

Nisan 3, 2011 16:04
 

Hakan UZUNER

Eline sağlık Uğur hocam

Nisan 5, 2011 19:06
Kimliksiz yorumlar seçilemez kılınmış durumdadır.

Yazar: Ugur INAL

http://uguroracle.blogspot.com

Bu Kategori

Hızlı aktarma