Bu hata slave sunucularda var olan bilgilerin tekrar yazılmak istemesi üzerine oluşur. İki yöntem ile bu sorunu aşabilirsiniz. Birincisi mysql’in belirttiğiniz hataları yok sayanmasını sağlayan slave-skip-errors komutunu kullanabilirsiniz.

Fakat sorunları es geçmektense sorunları düzelten bir yöntem daha var. Percona tarafından geliştirilen Maatkit duplicate entry sorunlarını çözüyor.  Maatkit kurulumu oldukça basit bir araç.

Maatkit’i sorun olan slave sunucularına kurduktan sonra şu komutu çalıştırıp arkanıza yaslanmanız yeterli:

mk-slave-restart --verbose

Verbose parametresi ile ekrana duplicate olan kayıtlar listelenecek. İşlem tamamlandıktan sonra replication sisteminizi eskisi gibi kullanmaya devam edebilirsiniz.

ps aux | grep mysql

komutu ile sistemde çalışan bir mysql süreci olup olmadığını kontrol edebilir, ve eğer versa süreç numarasını kullanarak şu komutla süreci öldürebilirsiniz:

kill -9 <Süreç Id'si>

Tabi top/htop gibi uygulamaları kullanarak süreçlere bakabilirsin.

Lazım olabilecekler için script indirebilir.

Daha iyi bir yöntem biliyor iseniz dürtmekten çekinmeyiniz…

İlgimi çeken yazı ise SQL ile yapılmış olan ve yazımın başlığını oluşturan pie chart. Sanırım bir süre boyunca boş vakitlerimde bu kodu anlamaya çalışarak geçireceğim. Buyrun ilgili link:

http://code.openark.org/blog/mysql/sql-pie-chart

Genel olarak uzun bir süredir php üzerinde çalışıyorum. Artık yavaş yavaş bilgilerimi paylaşmanın vakti geldi sanırım. İlk olarak Php ile uğraşırken genel olarak bilmemiz gereken tanımlardan bahsedeceğim.

Php sunucu taraflı (server side) diye tabir ettiğimiz bir betik dilidir. Sunucu taraflı tanımını biraz açmak gerekirsek, php ile yazdığımız kodlar bir sunucuda yorumlanır ve bu yorumlama sonucu oluşan HTML çıktılar bir tarayıcı aracılığı ile gösterilir. Kısaca php kodlarımız sunucu tarafında işlenir ve kullanıcı bilgisayarında sadece HTML çıktıları görür.

Bu yorumlama işlemi yapılırken iki adet bileşen kullanırılır. Bir tanesi PHP yorumlayıcısı, diğeri ise internet sunucusudur. Apache, IIS, Lighttpd gibi uygulamalar internet sunucularından bir kaçıdır. Ben genelde az bellek tükettiği için Lighttpd tercih ediyorum. İleriki konularda Linux ve Windows üzerinde php ve bir web sunucusu kurulumunun nasıl yapıldığını anlatacağım.

Bu çalışma mantığını biraz daha açalım. Php ile yazdığınız kodlar önce sunucuya(apache,iis vb..) gönderilir, sunucu php kodu olarak algıladığı kodları (<?php ?> arasında yer alan kodlar) php yorumlayıcısına göndererek yorumlamasını ister. Php yorumlayıcısının yorumlayıp HTML olarka ürettiği çıktı tekrar sunucu aracılığı ile tarayıcıya iletilir. Aşağıda bu durmun resimli gösterimini görebilirsiniz.

Php çalışma Prensibi

Sunucu taraflı dillerin hepsi bu yapıya benzer bir prensip dahilinde çalışırlar. Buda aslında çalıştırılan her kodun sunucu bilgisayar üzerinde sistem kaynağı tüketmesine sebep olur. Bu yüzden yapacağımız uygulamaların bazı kısımlarında JavaScript gibi tarayıcı tarafından yorumlana bilen betikler kullanılır. Örneğin bir üyelik formunda ki alanları kontrol ettirirken php kullanmak sunucuyu çok yoracağından bu işlem ufak bir JavaScript kodu ile kullanıcı bilgisayarına yaptırılabilir.

Php bir çok özelliğe sahip bir dildir. Genel olarak php ile ilgili ayarlar php.ini dosyasında bulunmaktadır. Php.ini ile ilgili ayrıntıları ilgili konular geldiğinde parça parça anlatacağım.

Gelelim veri tabanı konusuna. Aslında veri tabanı konusu çok karmaşık değil. Şuan sadece yukarıda bahsettiğimiz sistem içerisine bir de veri tabanı sunucusu ekleyeceğiz. Bu cümleden çıkartılabileceği üzere veri tabanı bir sunucu olarak çalışır. Fakat bunun yanında, SQlite gibi bir dosya üzerinden sunucu olmadan çalışabilen veri tabanı sistemleri de mevcuttur.

Veri tabanlarını projelerimizde ürettiğimiz verileri tutmak için kullanırız. Veri tabanlarının yaptığı iş basit olarak veri kaydetmek, kaydedilmiş verileri istediğimiz kriterlere göre geri çağırmaktan ibarettir (tabi ki gelişmiş özellikleri de vardır). Veri tabanlarının kendilerine özgü sorgu dilleri mevcuttur ve en yaygın olarak kullanılan sorgu dili SQL dilidir. MySQL, MsSQL, SQLite gibi sistemler SQL dilini kullanırlar.

Genel olarak tüm programlama dilleri, veri tabanı sunucuları ile aynı mantıkta iletişim kurarlar. Php yorumlayıcısı sorguyu veri tabanı sunucusuna gönderir, veri tabanı sunucusu sorgu sonucununda döndürdüğü bilgiyi php yorumlayıcısına gönderir. Php yorumlayıcısı veri tabanı sunucusundan bilgiyi aldıktan sonra bu bilgiyi yine HTML çıktı olarak sunucuya gönderir ve tarayıcıda görüntülenmesi sağlanır. Bu noktada küçük bir bilgi vermek istiyorum. Php dilini komut satırı arayüzü (CLI-Command Line Interface-) arcılığı ile kullanabilirsiniz. CLI ortamında yazdığınız kodlar için bir web sunucusuna ihtiyaç duymayız. Fakat php genel olarak web programlama alanında kullanıldığı için ben de web programlamayı temel alarak anlatmaya çalışacağım.

Yukarıda bulunan grafiğe bir veri tabanı-php ilişkisi eklenmiş hali. Grafik ile çok daha net anlaşılacağını düşünüyorum.

Php - Veri Tabanı İlişkisi

Gelecek yazılar:
Php 2: Linux sistemler altında Php, Apache, MySQL ve PhpMyAdmin kurulumu
Php 3: Windows Xp sistemine Php, Apache, MySQL ve PhpMyAdmin kurulumu

Kullanıcı dosyaları ile ilgili bu kısım herkes tarafından bilinen ve kolayca yapılan işlem. Fakat benim esas sıkıntıyı önbellekte tuttuğum pisi paketleri ve mysql veri tabanlarım ile yaşıyordum. İlgili ayar dosyaları değişiklikleri ile bu sıkıntımıda çözdüm. Artık mysql veri tabanlarım ile pisi paketlerim “/home/” altında ki kullanıcı klasörlerimin içerisinde depolanıyor.

Önce pisi paketleri için gerekli ayarları yapmakla başladım.

“/etc/pisi” altında bulunan pisi.conf dosyasında ilgili ayarlar bulunmakta. Aşağıda bu dosyanın ilgili bölümü yer almakta açıklamalarla birlikte.

[directories]
archives_dir = /home/ARTe/sistem/pisi/archives => Arşiv dizini
cached_packages_dir = /home/ARTe/sistem/pisi/packages => Önbellek dizini
compiled_packages_dir = /home/ARTe/sistem/pisi/packages => Derlenmiş paket dizini
debug_packages_dir = /home/ARTe/sistem/pisi/packages => Debug paketleri dizini
history_dir = /home/ARTe/sistem/pisi/lib/history => Geçmiş bilgilerinin tutulduğu dizin
index_dir = /home/ARTe/sistem/pisi/lib/index => Depo indexleri bilgilerinin tutulduğu dizin
info_dir = /home/ARTe/sistem/pisi/lib/info => Depolara ait bilgilerin tutulduğu dizin
kde_dir = /usr/kde/3.5
lib_dir = /var/lib/pisi
lock_dir = /var/lock/subsys
log_dir = /var/log
packages_dir = /var/lib/pisi/package
qt_dir = /usr/qt/3
tmp_dir = /home/ARTe/sistem/pisi => Temp dizini

Yukarıda değişiklik yaptığım alanlar ile ilgili açıklamaları yazdım. Siz de ilgili alanları kendinize göre düzenlemeniz halinde pisi paketleri ve depo bilgileri istediğiniz dizinde saklanmış olacaktır.

Bu noktada bir uyarı yapmakta yarar var eğer depo bilgilerinide ayrı bir yerde tutacaksanız “/var/lib/pisi” adresi altındaki tüm dosyaları ilgili dizine kopyalamanız gerekiyor. Böylece ekli olan depolar otomatik olarak yeni klasörde gözükecektir.

Gelelim MySQL veri tabanlarının istediğimiz dizinde saklanması olayına. Aslında bu olay pisi paketlerinden çok daha basit bir işlem yaparak gerçekleştiriliyor.

“etc/mysql/” klasörü altında bulunan “my.cnf” dosyasında ki

datadir                     = /home/ARTe/sistem/mysql

satırında gerekli değişikliği yapıp, “/var/lib/mysql” içindeki tüm dosyaları yeni dizinimize kopyalıyoruz. Bu işlemlerin ardından mysql sunucusunu yeniden başlatmak gerekiriyor.

Artık mysql  veritabanlarımız ve pisinin önbellekte tuttuğu paketler istediğimiz klasörlerde depolanıyor…

Böylece artık yeni kurulum yapmam gerektiğinde tüm bu bilgilerimi tekrar tekrar yedeklemek zorunda kalmayacağım..

/etc/mysql/my.cnf dosyasının içinde  skip-networking satırının başına # koyulması gerekiyor.
Bu işlemi yaptığınızda sorununuz çözülmüş oluyor.

Sayın Kutay Demirtas‘ın blogunda Mysql tablolarını ve girdilerini Postgresql e aktarmak başlığı ile yapmış olduğu girdiye ulaştım. Oldukça yararlı oldu. Gerçi blog yazısında tablolarında aktarıldığını belirtmiş Kutay bey, fakat yapmış olduğum denemede sadece verileri çıkarttığını gördüm. Kutay beyin blogunda anlattığı komutu değiştirmeden çalıştırdım fakat tablolar çıkmadı. Neyse tablo yapılarını elle hazırlamak zor değildi. Önemli olan yüzlerce girdiyi aktarabilmekti bunuda başardım.

Ekip projesi, basit anlamda bir stok takip sistemi olarak görünebilir. Fakat stok takipten çok daha fazlasını gerektiren bir çalışma. Temel olarak çeştili iletişim santrallerinde kullanılan kartlara ilişkin işlem bilgilerini tutan bir uygulama. Karşılıklı kart borçları, laboratuvar durumları, yurt dışı arıza durmları gibi bir çok işlemi gerçekleştirdiğiniz uygulama büyük bir iş yükünü ortadan kaldırmayı amaçlıyor. Åžuan için genel anlamda gereken herşeyi yapıyor fakat tabiki eksiklikler ve olması gereken bir çok şey var.

Sürüm 1.5 ile çeşitli çıktıların renklendirilmesi, yapının daha modüler bir hal alması, depolara daha fazla işlevsellik katılması gibi ufak eklenti ve değişiklikler olacak. Bir nevi sürüm 2 için ön hazırlıkta diyebiliriz. Tabi buda şu anlama geliyor 1.5 yakın zamanda çalışmaya başlayacak.

Sürüm 2 ile birlikte bir çok yenilik olacak. Öncelikle mevcut ara yüz tamamı ile yeniden tasarlanacak. Ekranın daha etkin kullanımı sağlanacak. Son yapılan denemelerde bilgi girildikçe uzayan sayfalar oldukça can sıkıcı bir görüntüye sahip oluyor. Bunun ardından şuanda ekrana yansımayan istatistikler ana ekranda gözükecek. Åžirket deposunda kaç adet kart var, sahalarda kaç adet kart var gibisinden sayısal bilgi amaçlı ekranlar olacak. Ayrıca şuan tutulmayan, kullanıcı kayıtları tutulacak. Böylece hangi kullanıcının hangi işlemi yaptığı görülebilecek. Raporlar hesap tablosu olarak bilgisayara kaydedilebilecek. Åžuan için sadece tarayıcı aracılığı ile çıktı alınması sağlanıyor. Alarm seviyeleri gibi ince ayarların yapılması mümkün olacak (bu çok gerekli bir işlev değil fakat olmasında yarar var:)). En önemli değişiklikler ise, Yedekleme ve Güncelleme sistemlerinin dahil edilmesi olacak. Åžuan yedeklemeler cron işlemi ile yapılmakta. Güncellemeleri ise her dosyanın md5 toplamlarının karşılaştırılması ile gerçekleşecek(şuan için üzerinde çalıştığım düşünce bu). Åžuan ki sistemde aşırı derecede include edilmiş sayfalar çalışmakta. Zaman içerisinde bunların ne kadar can sıkıcı olduğunu gördüm. Sürüm 2 de ise sık kullanılan işlevler fonksiyon olarak bir dosyada tanımlanacak ve sadece o dosya include edilip fonksiyonların çağrılması sağlanacak. Bu şekilde daha modüler bir yapı oluşturabileceğimi düşünüyorum. Genel olarak sürüm 2 için planlarım bunlar.

Bunların dışında sürüm 2 çalışmaya başladıktan sonra ufak tefek güncellemeler yapmayı planlıyorum. İlk etapta raporların hem hesap tablosu hem de PDF olarak alınmasını sağlamaya çalışacağım. Ayrıca bu raporların sunucu tarafında tutulmasını isteğe bağlı olarak yapacak ve böylece eski raporlara erişimin sağlanmasını kolaylaştıracağım. Tabi birde yardım sayfalarını artık hazırlamam gerekecek sanırım:). Åžuan yarı otomatik olarak çalışan borç sistemini tam anlamıyla otomatikleştirmek için çabalayacağım, umarım başarılı olabilirim. Ve bunun gibi bir çok iyileştirme çalışmaları yapılacak. Bu süre zarfında çalışan Ekip uygulamasınında eksikliklerini görüp o eksikliklere uygun güncellemelerde olacaktır tabi.

Ama esas beni heyecanlandıran sürüm 3 olacak. Çünkü sürüm 3 ile birlikte artık PHP yerine Python kullanmayı, bir kurucu tasarlamayı ve django çatısı kullanmayı planlıyorum. Tabi tek değişiklik programlama dilinde olmayacak. Veri tabanı desteği arasına PostgreSQL’i de eklemeyi düşünüyorum. Tabi sürüm 3ün Python ile hazırlayacağım kurucu vasıtasıyla kurulması söz konusu olacak. Kurulum esnasında kullanıcıya kullanmak istediği veri tabanı sunucusu tercihi yapılacak. Birde kullanmak istediği alt yapı. Yani kurulum ile birlikte, kullanıcı PHP, Python veya her ikisiyle birlikte çalışabilecek şekilde kurulum yapabilecek.

Tabi bunların hepsini Pardus kullanarak yapacağım. Özgür yazılım felsefesine uygun bir geliştirme yapmaya çalışacağım. Sanırım Ekip uygulamasını daha elle tutulur bir hale getirinde bir özgür yazılım olma yolunda en büyük adımı atmış olacak.

Åžimdi bu kadar yazdım da hayaller ne kadar güzel diye bir düşünce belirdi kafamda. Gelecek ile ilgili planlarımın biraz zorlayıcı ve yorucu olduğunun farkındayım. Fakat ter akıtmadan başarı olur mu? Orası ayrı bir soru işareti. Çalışarak ve sabrederek herşeyin olabileceğine inanarak yazımı bitirmek istiyorum. Bu kadar uzun bir yazıyı sabredip okuyan herkese teşekkür ederim:)

Göçün zor olacağı zaten belliydi. Dosya yüklemeleri vb. zor değildi de, veri tabanlarında yaşanması muhtemel olan Türkçe karakter problemlerinin ne derecede çözüme kavuşturulabileceği merak konusuydu bende. Neyse internette yaptığımız araştırmalar sonucu işimize yarar bir şeyler bulamadık. Abimin “babadan kalma yöntemlerle yapalım boşuna arama” sözlerine istemeyerek de olsa katılmak zorunda kaldım ve işe giriştik. Önce veri tabanlarını tek tek sql olarak indirip içlerindeki bozuk karakterleri kate ile değiştirmeye başladık… Gerçekten zor ve usandırıcı bir iş. Neyse işin en kötü tarafı bir farklı farklı kodlar çıkması bizi iyice zorlamış ve yormaya başlamıştı. Neyse ki sunucularımızda Joomla 1.5 kullanan az kullanıcı vardı da bir tek onlarda sorun yaşadık.

Buraya kadar yazdıklarım normal sayılabilir. Fakat öyle bir şey yaşadık ki bunun açıklamasını hala yapabilmiş değilim. Bloğumu yüklediğimde ilk olarak Türkçe karakterler bozuk gelmişti. Abimin bilgisayarında da, başka bir arkadaşın bilgisayarında da. Neyse bunu en sona bırakıp diğerlerini halledeyim dedim. On dakika geçti tekrar girdim bloğuma ve bingo. Tüm karakterler düzgün çıkıyordu hem benim hem abimin hem de arkadaşımın bilgisayarında. Gerçekten ilginç geldi. Bu işin mantıklı açıklamasını gerçekten merak ediyorum.