Rootifera

MsSQL Server 2008 – Transactional Replication

by on Şub.22, 2013, under Veritabani

Merhaba,

Bu makalede Msql Replikasyon konusuna değineceğim. Tabi belirtmek isterimki, benzer makaleler internette bulunabilmekte önemli olan en doğru ve en kolay biçimde konuyu aktarabilmeye çalışmak.
Makaledeki replikasyon işlemi tek yönlü olarak yapılmaktadır. Yani bir SQL Sunucuya gönderilen verilerin başka bir SQL Sunucuda bir kopyasının anlık oluşturulması diyebiliriz. Başka bir örnekse,  Merkez ve uzak şube tipi  işletme yapılarında, şubelerin veritabanına yani merkez sisteme bağlanmaları bazen hem bir risk hemde performans sorunudur. Düşünün ki Merkez veritabanınızın bir kopyasıda şubenizde faaliyet göstermekte ve ERP yazılımınız çalışmak için şube veritabanını kullanıyor . İşte bu durum performans problemi,  veri kaybı  ve çakışma gibi problemlerin önüne geçecektir. Replikasyon mimarisi işletmenin ihtiyacı doğrultusunda şekilleneceği için örnekler çoğaltılabilir.  Sırasıyla başlayalım…

Kullanılacak Terimler :

Publisher : Veritabanını barındıran ve replike edilecek datayı belirleyen datayi(article(s)) oluşturup yayıncıya ileten sunucudur.

Distributor : Publisher ile Subscriber arasında veri iletişimini sağlayan sunucu rolüdür, dağıtıcı mekanizmadır.

Subscriber : Dagitimlari alip kullanan hedef sunuculardir.

 

Genel Yapılandırma :

-Bölüm (1) : Publisher Üzerinde Distributor  Ayarlarları;

Biz bu örnekte iki rolü(Yayıncı-Dağıtıcı) bir SQL Server üzerinde yapacağız. Öncelikle yapmamız gereken yayıncı(Publisher) veritabanının dağıtıcı(Distributor) özelliğini aktif etmek bunun için “Replication” tabında sağ tıklıyoruz ve Configure Distribution seçeneğini tıklıyoruz. Daha sonra karşımıza bir wizard geliyor ilk ekranı hemen geçerek Distributor sekmesine ulaşıyoruz.

1- Distributor :   Bu kısım dağıtım işini kimin üstleneceğini belirttiğimiz alandır. Üzerinde işlem yaptığımız sunucu dağıtıcı olacaksa default olarak bırakıyoruz yok eğer uzak sunucuyu bir dağıtıcı olarak belirleyeceksek hemen altındaki seçeneği seçerek Add düğmesini seçerek diğer sunucuyu seçiyoruz. Biz default olarak devam ediyoruz.

 

rp6

 

2- Snapshot Folder :  Bu alan anlık replikasyon verilerinin yazıldığı (snapshot) yolu göstereceğiniz alandır.  Ağdan erişecek sunucular için bu dosyayı bir paylaşım klasörüne taşımak veya mevcut klasörünü paylaştırmak gereklidir. Tabiki paylaşım verildikten sonra  ”Snapshot Folder”  dosya yolunu değiştirmeliyiz (örn: \\MSSQLServer\repldata)

rp4

 

3- Distribution Database :  Dağıtıcı veritabanın yolunu belirlediğimiz alandır. Bu dosya yolunu sonradan oluşlabilecek büyümeleri de düşünerek bir dosya yolu belirlememiz menfaatimize olacaktır.  İlk yol veritabanı diğeri log dosyasının yoludur. (Kısaca Distributed Database; Genel olarak bu veritabanı kavramı aslında tek bir veritabanı gibi çalışan altında birden fazla veritabanını farklı sunuculardan barındıran bir sistem olarak düşnebiliriz. )

 

rp7

 

4- Publishers :  Eğer aynı zamanda bu dağıtıcı  bir  yayıncı olmak isterse (ki bizde bu şekilde kullanacağız) o zaman bu seçeneği işaretleyerek devam edebilirsiniz. Farklı bir yayıncı (Publisher) seçmek isterseniz aşağıdan Add.. diyerek farklı bir yayıncı tanımlayabilirsiniz. (Organizasyonun mimamirisine göre değişiklik gösteren veritabanı mimarisini biz öğrenmek amaçlı en yalın şekliyle örnekliyoruz.)

 

rp8

 

5- Wizard Action :  Evet… “Dağıtıcı Konfigurasyonu ” işlemini sonlandırmak için Finish dememiz yeterli olacaktır.  Eğer isterseniz  ”Generate a script …” checkbox ını işaretleyip , tüm bu yaptığımız ayarların bir sql dosyasını alabilirsiniz. Finish diyoruz ve işlemin başırlı bir şekilde tamamlandığını görüyoruz.

 

rp9

 

-Bölüm (2) Replikasyon Tipi ve Replikasyon Database;

 

Yapacağımız işlemde yeni bir paylaşım oluşturacağız. Publisher rolünü aktif hale getireceğiz. Böylece Distributor’ e Publisherın kim olduğunu,  Subscriber a hangi verileri (articles) ileteceğini belirlemiş olacağız.

 

-Replication sekmesinde “Local Publications”  ismine sağ tıklayarak New Publications diyerek İleri diyoruz.

1-  Distributor :  Dağıtıcının seçildiği (Distributor) ekran karşımıza gelmektedir. Seçeneklerin ilki gördüğünüz gibi Master veritabanımızın ismi diğeri ise uzak dağıtıcıyı belirleyeceğimiz alandır. Biz ilk seçenek ile ilerliyoruz.

 

rp2

 

2- Snapshot Folder :  Bu alan anlık replikasyon verilerinin yazıldığı (snapshot) yolu göstereceğiniz alandır.  Ağdan erişecek sunucular için bu dosyayı bir paylaşım klasörüne taşımak veya mevcut klasörünü paylaştırmak gereklidir. Tabiki paylaşım verildikten sonra  ”Snapshot Folder”  dosya yolunu değiştirmeliyiz (örn: \\MSSQLServer\repldata)

 

rp4

 

 

3- Publication Database : Replikasyonunu yapacağımız veritabanımızı seçtiğimiz alandır. Sadece bir adet veritabanı seçebiliyoruz.

 

rp5

 

4- Publication Type :  Replikasyon tipini belirlediğimiz önemli bir alandayız. Biz “Transactional Publication” tipinde replikasyon yapacağız ama yinede bütün replikasyon tipleri hakkında hatırlamak açısından bilgi verelim;

 

- Snapshot Replication : Zamanlanmış aralıklarla topluca insert işlemi yapılarak güncellenen bir replikasyon işlemi

 - Transactional Replication : Bu tipte ise log dosyası dinlenerek yapılan değişikliklerin bir karşı tarafa replike olur. (makalemizde kullandığımız yöntem)

- Transactional Publication With Updatable Subscriptions : Adında anlaşılabileceği gibi güncellenebilir üyelikler(Subscripton) söz konusudur. Publisher – Subscriber arasında kullanılan verilerde Subscriber güncelleme yapabilme yeteneğine sahiptir.

- Merge Publication : İki yönlü veri girişine müsade eden bir yöntemdir. Yani örneğin bir uygulamanız var. Master veritabanına ahmet adında bir veri insert edip, slave veritabanınada mehmet diye bir veri insert ettiğimizde sonuç olarak iki veritabanında da bu iki kaydın alt alta olduğunu görmüş oluruz. Bu kaba tabirle anlatabildiğimi düşünüyorum. Ayrıca HTTPS üzerinden replikasyona izin vermektedir. Avantajı nedir diye düşündüğümüzde; ilki  mobile veri iletişimi senkronizasyonu diyebiliriz.

Özet bilgiyi verdikten sonra Transactional Replication seçeneği ile Next diyoruz.

rp10

5- Article :  Bu alanda yayınlayacağımız tablo/tabloları seçiyoruz. Unutmamız gereken nokta, seçtiğimiz tablo içerisinde mutlaka Primary Key olmasıdır. Olmadığı taktirde replikasyon işlemini tamamlayamıyoruz.

rp11

6- Filter Table Rows :  Replikasyona dahil etmek istemediğiniz tablo/sütun ları filtreleyebilirsiniz.

rp12

7- Snapshot Agent : Replikasyon tiplerinden biri seçildiğinde ilk Snapshot ı oluşturan servistir. Snapshot replication tipinde ise bu görev belirli aralıklarla sürekli olarak yapılmaktadır. Alt seçenekte ise bu replikasyon işleminin hangi zaman aralıklarında yapılmasını istediğimizi belirtiyoruz.

rp13

8- Agent Security :  Distributor ve Publication arasındaki data senkronizasyonun, bağlantı ve devamlılığı için iki sunucunun da hesap bilgilerinin girilmesi gereklidir. İlk Snapshot’ ın oluşturulması ve replikasyonun başlaması için önemli adımdır diyebiliriz. Eğer bütün bu adımları tamamladınız buna rağmen ilgili Snapshot “\\MSSQL\repldata”  klasörü içerisinde oluşturulmamışsa, datalar iletilmiyorsa ilk bakmanız ve kontrol etmeniz gereken yer burası diyebiliriz.

rp14rp17

9- Wizard Action :  Belirtmek istediğim bir husus var o da eğer microsoft sunucu ürünleri kullanıyorsanız rol kavramına aşinasınızdır. MSSQL Server ürününde de bu rollere değinmiştik. Makalede bahsi geçen bu rolleri (Publisher ve Distributor) dağıtmamızda mümkün pek tabii ki bu konu orgranizasyondaki database mimarisiyle eşgüdümlü ele alınmaktadır. Biz konunun yalın haliyle üzerinden geçiyoruz. Devam,  Wizard Actions ‘ a geldik. Publication rolümüzü  ”Create the publication” diyerek tamamlıyoruz.

rp15

10 - Complete the Wizard : Son ekranımıza ulaştık. Oluşturmuş olduğumuz Publication a bir isim verip,  replikasyon uygulamamızı tamamlıyoruz. İşlem sonunda süreçlerin Success olarak tamamlandığına emin olunuz.

rp16

-Bölüm (3)  Subscriber (Abone) Ayarları : 

Buraya kadar  Publisher ve Distributor ayarlarımızı tamamladık, şimdi bir Subscriber yani bu veritabanını replike edeceğimiz sunucuyu tanımlıyacağız  (Birden fazla subscriber tanımlayabiliriz.). Subscriberları Publisher sunucu üzerinde tanımlayacağız. Bunun için Replication altında, Local Publications altında oluşturduğumuz Publication a sağ tıklayarak New Subscriber diyoruz.

Sırasıyla;

1- Publication : Replication sekmesinin altında oluşturduğumuz TransactionRep publication ına sağ tıklayarak “New Subscription” diyoruz. İlk Wizard ekranını Next diyerek geçiyoruz. Daha önce oluşturduğumuz Publication ı listeden seçiyoruz.

rp18

2- Distribution Agent Location : Distribution Agent Location alaninda iki seçenek vardir. İlki  ”Run all agents at the Distributor, MSSQL\SECONDSQL(Push subscription) ” ‘dir.  Bu özelliği seçtiğinizde replikasyondaki süreçler Distributor’ e atanır. Distributor replikasyon işlemlerini tetikleyecektir yani Distributor tarafında değişiklik olduğunda Subscriberlara güncelleyecektir.  Diğer özellik olan “Run Each agent at its Subscriber ( Pull subscribtion)” seçildiğinde ise replikasyon sürecindeki güncellemeleri subscriber lar talep eder ve sırasıyla başlar. Biz örneğimizde default seçenek ile devam ediyoruz.

rp19

3- Subscribers :  Publisher a bağlanan abone sunucuyu(Subscriber) tanımladığımız alandır. Subscriber olarak SQL Server haricinde Oracle(OLE DB) ve IBM DB2  sunucularınıda Subscriber olarak tanımlamamız mümkündür.  ”Add SQL Server Subscriber” seçeneğini seçerek karşımıza çıkan kullanıcı doğrulama ekranına  Subscriber sunucumuzun kullanıcı bilgilerini girip Connect diyorum.  Tanımladıktan sonra Next diyerek sonraki ekrana geçiyoruz.

rp22

4- Distribution Agent Security : Distributor ve Subscribtion arasındaki data senkronizasyonunu, bağlantı ve devamlılığı için iki sunucunun da hesap bilgilerinin girilmesi gereklidir.

 

rp21

 

5-  Synchronization Schedule :  Sekronizasyonun hangi aralıklarla olacağını ayarladığımız alandır.  Default gelen  Run Continuously (Sürekli)  ve Run on Demand Only (İsteğe Bağlı) çalışma şeklinin yanında  Define Schedule  seçeneği ile de kendiniz çalışma zamanını belirleyebilirsiniz ( her gün x saatte, her ayın y günü v.b) .

rp23

 

 

6 - Initialize Subscribtion :  Subscribtion ın Replikasyona ne zaman başlayacağını belirlediğimiz alandır. Subscribtion ayarlarımızı bitirdiğimiz an başlasın dersek  Immediately , ilk senskronizasyon ile beraber başlasın dersek  At first synchronization  seçeneğini seçiyorsunuz.

 

rp24

 

 

7- Wizard Action :   Son ekranımıza geldik, Finish diyerek Subscribtion ımızı oluşturuyoruz. İşlem tamamlanma esnasında resimdeki  gibi her satırda Success mesajını teyid edelim.

 

rp25

 

-Bölüm (4)  Replikasyon Analiz :

Şuan çalışan bir Transactional Replication sistemimiz oldu, peki sağlıklı çalışıyor mu, her şey yolunda mı? Öğrenmek için Replication sekmesinde sağ tıklıyoruz ve Launch Replication Monitor  çalıştırıyoruz.

 

rp26

 

1 - Publication :  Publication ların durum, tip ve  performanslarını izlediğimin paneldir.

2- Subscribtion Watch List :  Replikasyon tipine göre filtrelediğimiz yine, performans durumu, gecikme süresi ve aktiflik durumuna göre izlediğimiz panel.

3- Agents :  Replikasyon sırasında çalışan Agent ların durumunu izlediğimiz bölümdür. Önemli bir bölümdür.

Önemli :  Replikasyon a tıkladığınızda  Tracer Tokens diye bir alan açıldığını göreceğiz. Bu alan eğer Publisher Sunucumuz ve Distributor Sunucumuz ayrı sunucularda veya ayrı lokasyonlarda ise birbirleri arasındaki iletişimi Insert Tracer diyerek  görebiliyoruz.  Her trace aldığımızda bir önceki iletişim performansını görmemizde güzel bir özellik.

 

 

 

 

Leave a Comment more...

Mysql Master/Slave Replikasyonu

by on Kas.27, 2012, under Veritabani

Merhaba,

Bu yazımızda Centos üzerinde Mysql Replikasyonu konusuna değineceğiniz. Bildiğimiz gibi sürekli eğişebilirlik(High Availability)  işlerin büyük kısmını web/desktop uygulamaları üzerinden yürüten şirketler için kaçınılmaz bir özellik olmaktadır. Sırasıyla bakıldığında Database kavramıda en önemli ayağını oluşturmaktadır. Fazla uzatmadan bir veri tabanının ikincil sürekliliğini Master/Slave kavramları açısından inceleyelim.

Özetle : Master/Slave şeklindeki replikasyon tek yönlüdür.Yani Master Veritabanında yapılan girişler Slave(ikincil) veritabanına bir kopyası şeklinde veri aktarımı yapılır ve Master ın bir kopyası oluşturulmuş olur. Master/Master veritabanı kavramını bir sonraki yazıda inceleyeceğiz ama kısa değinmek gerekirse, Master/Master Replikasyonda  yapılan insert ve update işlemlerinin hangi veri tabanında yapıldığı önemli değildir, bu işlemler hangisinde yapılırsa yapılsın birbirini eşitleyecektir.

 

Teknik Detaylar;

OS: CentOS release 6.3 (cat /etc/redhat-release)

DB: MySQL 5.1.66 (mysql> STATUS;)

Master OS:  master.local

Slave OS: slave.local

 

Master Yapılandırılması:

1- İlk olarak Master Mysql  üzerinde bir kullanıcı açarak Slave Mysql ‘ e erişim hakkı veriyoruz.

mysql>GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'slave_db'@'%' IDENTIFIED BY 'slave_pass'; FLUSH PRIVILEGES;

2-Mysql yapılandırma dosyamızı aşağıdaki gibi düzenliyoruz.

#nano /etc/my.cnf içerisinde [mysqld]  başlığının altın aşağıdaki satır eklenir.

log-bin = mysql-bin
server-id = 1   //master ve slave olarak sunucu rolünü belirleyen bir unique bir ifadedir.örn:(slave server-id=2)
2-Mysql' i yeniden başlatıyoruz.
#service mysql restart

Slave Yapılandırılması,

1-Mysql yapılandırma dosyasını değiştiriyoruz.(Burada yapacağınız farklı opsiyonlarda mevcuttur.)

#nano /etc/my.cnf içerisinde [mysqld]  başlığının altın aşağıdaki satır eklenir.

log-bin = mysql-bin
server-id = 2   
relay-log = mysql-relay-bin //Replikasyon süreçleri hakkında bilgiler tutan alandır.
log-slave-updates = 1
read-only = 1

2-Mysql’ i yeniden başlatıyoruz.

#service mysql restart

Buraya kadar olan kısımlarda Master/Slave veritabanlarının temel konfigurasyonları yapıldı.Bundan sonnra yapmamız gerken Master veritabanın bir (dump) kopyasını alıp Slave sunucuya göndermek olacaktır.

1-Master Veritabanı sunucusu üzerinde aşağıdaki komut satırıyla tüm veritabanının bir yedeğini alıyoruz.

#mysqldump -u root -p --all-databases --master-data=2 > dbdump.db
2-Alınan bu yedeği slave sunucuya gönderiyoruz.
#scp /home/master/dbdump.db slave@192.168.2.25:/home/slave/

3-Slave veritabanında bu dosyayı restore edelim.Böylece Master daki verileri Slave Veritabanına eşleştirmiş olduk.Replikasyon başlamadan Master Veritabanı üzerinde bir update, insert işlemi yapmamayı tavsiye ediyorum.

#mysql -u root -p < dbdump.db

4-Slave Mysql konsola geçilerek öncelikle Slave işlemi durdurulur (mysql>SLAVE STOP)  ve aşağıdaki Master Veritabanı bilgileri  Slave Veritabanına girilir.

mysql>CHANGE MASTER TO 
->MASTER_HOST='192.168.2.24 ',  
->MASTER_USER='slave_db',  
->MASTER_PASSWORD='slave_pass',  
->MASTER_LOG_FILE='mysql-in.000006',      //  Log_file ve log_pos bilgisini öğrenmek için master veritabanında  mysql> SHOW MASTER STATUS;  şeklinde öğrenebilirsiniz veya dump içeriğinden görmek mümkündür.
->MASTER_LOG_POS=906;

5- Bu işlemlerden sonra  mysql>start slave;   komutunu işleterek replikasyonu başlatıyoruz.

Bu noktada Replikasyon sürecini başlatmış olduk.Eğer veritabanın kayıt gönderen bir uygulamanız varsa web üzirinden veya direkt olarak Master veritabanında bir tablo açıp slave de de güncellenip güncellenmediğini kontrol edebilirsiniz.

 

Leave a Comment more...

Mysql Duplicate(Tekrarlanan) Verilerin Temizlenmesi

by on Eki.01, 2012, under Uncategorized

Merhaba,

Konu tekrarlanan veri olunca en temel kısımdan işi kotarmak doğru olacaktır.Öncelikle herhangi bir konsol dan Mysql’imize bağlanıyoruz.

 

1.Adım

İçerisinde hiç bir veri olmayan bir tablo oluşturuyoruz.

mysql>CREATE TABLE recipes(alan1 VARCHAR(32), alan2 VARCHAR(32);

 

2.Adım

Bir Query oluşturarak Insert metodu kullanıyoruz.Bu Query “eski_tablo” diye tabir ettiğimiz içerisinde aynı satırlar bulunduran verileri 1.Adımda oluşturduğumuz tablonun içerisinde kopyalamak için kullanıyoruz.Fakat burdaki tek farklılık “DISTINCT” ifadesini kullanarak aynı satırları almayı yani tekrarlanan verileri almamış oluyoruz.

mysql>INSERT INTO `gecici_yeni_tablo` SELECT DISTINCT * FROM `eski_tablomuz

 

3.Adım

INSERT işlemimiz bittikten sonra eski tablomuzu(“eski_tablomuz”) DROP ifadesiyle kaldırıyoruz.

 

mysql>DROP DATABASE `eski_tablomuz`;

4.Adım

Bu adımda “gecici_yeni_tablo” ismiyle oluşturduğumuz tablonun adını değiştirerek eski tablomuzun adını veriyoruz.

RENAME TABLE temp_table TO foo;

 

5.Adım

Veirlerin tekrarlanıp tekrarlanmadığını yani sağlamasını yapıyoruz.

SELECT `alan1`, `alan2`, COUNT(*)  FROM `eski_tablomuz` GROUP BY `alan1`, `alan2` HAVING COUNT(*) > 1;

 

Not: Aşağıda pratik bir methodu da vardır.

 

ALTER IGNORE TABLE `tablom` ADD UNIQUE INDEX(`kontrol_edilecek_sutunum`)

 

Leave a Comment more...

FreeBSD Nic Bonding(Nic Failover)

by on Tem.09, 2012, under BSD, Genel

Merhaba,

Bu yazımızda FreeBSD sistemimizde bir veya birden fazla ethernet kartını tek bir ethernet gibi kullanarak olası link down durumlarının önüne geçmektir.Yüksek Erişebilirlik (High Availability) konularının içinde sadece bir detay olara değerlendirebileceğimiz bu yazımızda belkide giriş olarak kabul edebiliriz.Veya şöyle düşünelim link yoksa çalışan sistemin hiç bir önemi yok :) Bu maksatla kullanacağımız iki ethernetten birinin arızalanması ya da problem yaşanması durumunda diğerini kullanarak görevine devam etmesi konusunu ele alacağız.Burdan bir balancing yöntemi oluşturduğumuzu düşmemeliyiz.Sırasıyla çalışmaya başlayalım.

Önemli: Ethernet Kartlarımızın Marka modellerinin aynısı olması daha önceden edindiğim tecrübeler doğrultusunda tavsiye edeceğim bir noktadır.Fakat bu yazıdaki ethernetler birbirinden farklıolması  hali hazırdaki sistemden kaynaklıdır.

Bu yazıda adı geçen kullandığım birincil ethernet kart Intel Pro/1000T’dir.Interface name “em0″ ‘dır.ikincil olarak bize backup göveri yapacak olan ethernet kartımızıda Gigabit Ethernet(onboard)’dir.Interface name “bge0″‘dır.Aşağıdaki örnek yapılandırmayı uygularken bu isimlere dikkat ediniz.

Öncelikle,

Bonding işlemi için bir driver yüklememiz gerekir. /boot/loader.conf dosyasını bir editör ile açıyoruz ve alttaki satırı aynı şekilde düzenliyoruz.

if_lagg_load=”YES”

/etc/rc.conf  dosyasını  açıp aşağıdaki gibi düzenliyoruz.

ifconfig_em0=”up”
ifconfig_bge0=”up”
cloned_interfaces=”lagg0″
ifconfig_lagg0=”laggproto failover laggport em0 laggport bge0″
ifconfig_lagg0_alias0=”inet 10.0.0.1 netmask 255.0.0.0″

Bu ayarlamalardan sonra konsol üzerinde ifconfig çıktısı aşağıdaki gibiyse birincil ve ikincil ethernet kartlarının istediğimiz şekilde gözüküyor demektir.

bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
lagg: laggdev lagg0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
lagg: laggdev lagg0
lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
inet 10.0.0.1 netmask 0xff000000 broadcast 10.0.0.255
media: Ethernet autoselect
status: active
laggproto failover
laggport: bge0 flags=0<>
laggport: em0 flags=5<MASTER,ACTIVE>

Çalışırlığını kontrol etmek içinse em0 (birincil ethernet) kablosunu çıkarıp diğer ethernetin yani bge0 ‘ın geçiş işlemi esnasında az bir kayıpla çalışmaya devam ettiğini yani sistemin görevi diğer ethernet kartına yönlendirdiğini ve bu işlemi otomatik olarak yaptığını görebiliyoruz.

Çok yakında FreeBSD Cluster uygulamaları yazımla bu tür konuları(redundant, failover v.b)  tekrar işleyeceğiz.

Leave a Comment more...


Amfphp Error

by on Haz.29, 2012, under Genel

Merhaba,

Eğer bir gün  Xamp ile beraber Amfphp’ye ihtiyaç duyduysanız  ve aşağıdaki gibi bir hata ile karşılaşırsanız çözümü şöyledir,

Hata Çıktısı: 

“Error retrieving service info:

Function eregi_replace() is deprecated”

Çözüm:

Öncelikle MethodTable.php yi (/amfphp/core/shared/util/MethodTable.php) NotePlus++ veya benzeri bir editörle açalım.Aşağıdaki satırları bulalım.

Orjinal Hali
---------------------------------------------------------------

  $comment = eregi_replace("\n[ \t]+", "\n", trim($comment));
  $comment = str_replace("\n", "\\n", trim($comment));
  $comment = eregi_replace("[\t ]+", " ", trim($comment));

---------------------------------------------------------------

 

Değiştireceğimiz Hali

---------------------------------------------------------------

  $comment = preg_replace("#\n[ \t]+#U", "\n", trim($comment));
  $comment = str_replace("\n", "\\n", trim($comment));
  $comment = preg_replace("#[\t ]+#U", " ", trim($comment));

---------------------------------------------------------------

 

Tekrar çalıştırdığınızda düzelmiş olacaktır.

Not: Örnek PHP dosyalarınızı “services” klasörüne atmayı unutmayınız.
Problem Açıklaması : Bunun sebebi Xamp içerisindeki Php versiyonunun farklı olmasıdır.

Leave a Comment more...

PostgreSQL Yedekleme ve Geri Yukleme

by on Haz.29, 2012, under Veritabani

Herkese Merhaba,

İlk makalemde sizlere FreeBSD üzerinde PostgreSQL Backup ve Restore işleminden bahsedeceğim.İlk makale olmasından dolayı yaşanacak cümle düşüklükleri ve anlatım problemlerininde zamanla aşılacağını düşünüyorum.

Yedekleme

Öncelikle konsol üzerinden PostgreSQL’e bağlanıyoruz.

# su – pgsql

Akabinde tüm veritabanlarının yedeğini almak için,

$  pg_dumpall

Belirli bir veritabanın yedeğini almak isterseniz,

pg_dump veritabani1 > veritabani1.sql

Yedek alma işleminin tamamlandığını bir çok şekilde görmek mümkündür(örn: pg_stat_activity v.b), fakat biz bu işlemi gözlemlediğimizi ve işlemin tamamlandığı farzederek.Klasöre gözatıyoruz.

 

# ls –l ~pgsql/backups/ 
total 1
-rw-r--r--  1 pgsql  pgsql  3790 Nis 02 01:22 pgdump_all_2010-01-
19T02:01:08

Geri Yukleme

Şimdi ise aldığımız tüm yedeklemeyi geri alacağız.Tahmin edeceğiniz  gibi bu işlemler basit yedekleme ve geri alma işlemlerini kapsamaktadır.Yedekleme(Backup) mantalitesi çok kapsamlı ve planlama gerektiren kompleks sistemler için detaylıdır.Bu konuyuda iyi bilmek menfaatimize olacaktır.

Devam edecek olursak,

Tüm veritabanlarını geri almak için,

# psql –f all.sql

Belirli bir veritabanının yedeğini geri almak için,

# psql –d deneme –f deneme.sql

 

Bu işlemden sonra veritabanımızı geri yüklemiş(restore) olduk.Unutmadan yedekleme ve geri yükleme işlemlerini yaparken tüm postgresql işlemlerini(process) durdurmanız faydalı olacaktır.

Bu yazıdaki operatörler,

-f   : Yaptığımız işlemin çıktısını göndereceğimiz yolu belirtir.

-d : Bu operatörden sonra bir veritabanı adının geleceğini ifade eder. (-d = dbname)

-l :  Listeleme.Bir dizinin içeriğini görmek için kullanılır.

Leave a Comment more...

MySQL Yedekleme ve Geri Yukleme

by on Haz.27, 2012, under Cozumler, Veritabani

Merhaba,

Cogu MySQL kullanicisi siklikla veritabanlarini yedeklemek ve geri yuklemek zorunda kalir. Bazen kendi veritabaninizin yedegini almak istersiniz ya da elinizde olan bir SQL dosyasini MySQL’e aktarmak gerekebilir. Bu islemlerin tumunu oldukca hizli ve kolay bir sekilde Linux terminalinde yapabiliriz.

Konuyu mumkun oldugunca detayli olarak yeni baslayanlar icin anlatmaya calistim.

Baslamadan once sistemimizde mysql-client paketinin kurulu olup olmadigina bakalim.

 

Debian/Ubuntu:

# dpkg --get-selections | grep mysql-client

RedHat/Centos:

# rpm -qa | grep mysql-client

Seklinde paketlerimizi kontrol edebiliriz.

Veritabani yedekleme islemi icin sozdizimi su sekildedir

# mysqldump -u kullanici -pSifre --databases veritabani1 veritabani2 > yedek.sql

mysqldump veritabanlarini disa aktarmak icin kullandigimiz komuttur. “-u” (user) kullanici adi, “-p” (password) sifre, “–databases” birden fazla veritabani yedegini almak icin kullaniliyor ve ” > yedek.sql ” ise mysqldump komutudan gelen ciktiyi “>” isareti ile yedek.sql dosyasina yazmamizi sagliyor.

Ornek olarak;

# mysqldump -u root -p123456 stokdb > stokdb_27062012.sql

Ornekte stokdb veritabanini stokdb_27062012.sql adi altinda yedekledik. Veritabani kullanicisi olarak root, kullanici sifresi olarak da 123456 kullandik. Burada dikkat etmeniz gereken nokta “-p” ve 123456 arasinda bosluk olmamasidir. Benim kisisel tercihim sifreyi “-p123456″ yerine sadece “-p” olarak kullanip komut gonderildikten sonra gelen “Enter Password” kisminda sifreyi girmektir ve bence bu acik acik kullanici sifresi yazmaktan daha guvenli. Ayrica veritabaninizin buyuklugune bagli olarak yedekleme suresi uzayacaktir. 2GB buyuklugunde bir veritabani I5 islemcili bir masaustu bilgisayarda ortalama 10 dakika icinde yedekleniyor. Yedekleme islemi suresince terminalde bir cikti olmayacak, yedekleme bitince bir alt satira gececektir.

Ayrica birden fazla veritabanini tek seferde yedekleme ornegi yapalim, bu sefer kullanicimiz “depocu” sifre de “QH6w8fYQ” olsun.

# mysqldump -u depocu -p --databases stokdb tedarikcidb satislardb > tumstoklar_27062012.sql
# Enter password: (<--- sifremizi yaziyoruz "QH6w8fYQ")

Bu ornekte de stokdb, tedarikcidb ve satislardb veritabanlari tek bir sql dosyasi icinde yedeklenecektir. Mutlaka aklinizda bulunsun, coklu veritabani yedeklemesini geri yuklemeniz gerektiginde tum veritabanlari geri yuklenir. Veri kayiplarini onlemek icin coklu veritabani yedegi kullanirken dikkatli olun.

Yedekleme konusuyla ilgili yazacaklarim bu kadar. Simdi de geriyukleme isine bakalim.

Veritabani geriyukleme isi hemen hemen ayni mantikta calisiyor.

# mysql -u kullanici -pSifre veritabani < yedek.sql

Burada ilk olarak goze carpan, veritabani geri yukleme icin mysqldump kullanmiyoruz. Mysqldump sadece veritabanlarini yedeklerken kullaniliyor. Bir diger degisiklik de “<” isareti. Bu sefer veritabanini yedek.sql dosyasina atmak yerine, yedek.sql dosyasini veritabanina gonderiyoruz.

Ornek olarak;

# mysql -u root -p123456 stokdb < stokdb_27062012.sql

Burada 27.06.2012 tarihli stokdb yedegi stokdb veritabanimiza geri yuklenecektir. Yukarida bahsi gecen coklu veritabani yedeklerini geri yukleme konusu bu noktada biraz kafa karistirabilir. Komutta hangi veritabani ismini yazmamiz gerekcek? Aslinda hicbirini. Buna da bir ornek verelim.

# mysql -u depocu -p < tumstoklar_27062012.sql
# Enter password: (<--- sifremizi yaziyoruz "QH6w8fYQ")

Eger tumstoklar_27062012.sql dosyasini herhangi bir metin editoruyle acip bakarsaniz icinde CREATE DATABASE ve USE komutlarinin oldugunu gorursunuz. Geri yuklemeyi baslattiginizda mysql sizin yedek dosyanizdan hangi veritabaninda islem yapmak istediginizi okuyacak ve islem yapacaktir.

Son olarak bazen MySQL sunucuya uzaktan baglanip islem yapmanizi gerektirecek durumlar olabilir. Hemen buna da bakalim.

# mysqldump -u root -p123456 -h 192.168.1.100 stokdb > yedek.sql

Ornekte 192.168.1.100 IP adresli bilgisayarda calisan MySQL sunucuya baglanip stokdb veritabanini yedek.sql olarak yedekliyoruz. Ancak bu komutun calismasi icin MySQL sunucunuzun disaridan gelen isteklere cevap veriyor olmasi gerekir. Ayni sekilde mysql kullaniciniz da disaridan istek yapabilme yetkisine sahip olmalidir. Tamamen farkli bir konu oldugu icin ayarlarin nasil yapildigini bu konuda anlatmayacagim.

MySQL yedekleme ve geriyukleme islemleri temel olarak boyle. Umarim yardimci olabilmisimdir. Eger soru ve onerileriniz olursa mutlaka asagi yorum olarak yazin.

Tesekkurler.

Leave a Comment more...

Ne Aramıştınız?

Aradığınız şeyi bulmanıza yardım edebilirim:

Eğer aradığınız şeyi bulamazsanız mutlaka bize bildirin.Size yardım etmekten memnuniyet duyarız.

Blogroll

Tavsiyede bulanacağımız bazı web siteleri...

Arşiv

Kronolojik tüm kayıtlar...