Saturday, June 30, 2012

mysql master-slave replication problemlerinde

Buyuk boyutlarda dataniz varsa ve master-slave replication yapinizda slave makinenizde guncellenmeme sorununuz mevcutsa kontrol etmeniz gerkenler sirasiyla soyle olmali

- Master sunucuda "SHOW MASTER STATUS\G" komutu. Goreceginiz bilgiyi not edin.

File: mysql-bin.001085
Position: 23152940
Binlog_Do_DB: xxxx
Binlog_Ignore_DB: information_schema,mysql
1 row in set (0.00 sec)

- Problemli slave sunucuda "show slave status\G" komutunu mysql client uzerinden calistirin.

Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.200.70
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.001085
          Read_Master_Log_Pos: 26419968
               Relay_Log_File: mysqld-relay-bin.001329
                Relay_Log_Pos: 16690624
        Relay_Master_Log_File: mysql-bin.001033
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: xxxxx
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 16690479
              Relay_Log_Space: 5437822179
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 80737
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error: 

Bu asamada kontrol etmeniz gerekenler Last_SQL_Error, Last_IO_Error ve Seconds_Behind_Master.
Eger Last_SQL_Error  icin bir hata aciklamasi veya kodu mevcutsa buyuk ihtimalle master uzerinden gelen bozuk ve yarida kesilmis bir sorgudandir. Aciklama olarak bir sorgu verilmisse once bu sorguyu db uzerinde calistirin. Calismamasi gerken bir sorgu ise siraya yapmaniz gerekenler

STOP SLAVE; -- master'dan sorgu gelisini durudur. slave'i durdurur. mysql servisini degil.
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE; 

Tekrar "SHOW SLAVE STATUS\G" ile hata var mi diye kontrol edin. Eger Seconds_Behind_Master azaliyorsa veya zaten 0 ise replication sorunu yok denebilir. Ayni zamanda master uzerinde attiginiz SHOW MASTER STATUS ciktisindaki POSITION ile slave uzerinde gordugunuz position bilgileri en azindan yakin olmali.


Ayrica tam sirada slave uzerinde SHOW PROCESSLIST; ile LOCKED durumunda olan uzun suren sorgular var mi diye de kontrol ediniz. Uzun sure devam eden ve tablolarinizdan bir kacini kilitleyen sorgulariniz da replication durumunun geri kalmasina neden olabilecektir.


Artik hicbir hata kalmamis, uzun suren veya tablolari kilitleyen bor sorgu da yok ve replication ayarlarinizdan da eminseniz ve hala replication geri kaliyorsa su iki durumu da kontrol edin :

1. Makine uzerinden asiri bir yuk mu var. vmstat veya htop gibi araclarla kontrol ediniz.
2. Replication ayarlarinizi bir dokumantasyon yardimiyla kontrol edin http://www.howtoforge.com/mysql_master_master_replication
3. (Bu en onemli madde. Gozden kaçar genelde) Slave uzerinde surekli "freeing items" konumunda duran bir islem var mi?


Ucuncu maddede bahsedilen bir durum varsa genellikle "freeing items" konumunda olan bu islemin Query aciklamasinda "NULL" yazar ama bu replication surecini tikar. Genelde master'da yapilan bulk UPDATE/DELETE islemleri slave'de buna neden olabilir. Buyuk veritabaniniz varsa tum riski size ait olmak uzere su sorgulari calistirisaniz sorununuz cozulecek ve repliaction tekrar guncelligini korumaya baslayacaktir.


(Sunucunuze bu islem sirasinda hicbir sorgu gelmemeli!)

KILL xxxxx; -- xxx = "freeing items" konumunda sıkışan işlemin ID degeri
STOP SLAVE;
FLUSH TABLES; -- http://dev.mysql.com/doc/refman/5.0/en/flush.html
-- FLUSH TABLES islemi uzun surebilir. DAta buyuklugunuze gore.
 START SLAVE;

Wednesday, June 20, 2012

Sphinx İçin Türkçe Sorunları

Sphinx ile Türkçe verilerinizde sorunsuz çalışmak için öncelikle tüm tablolarınızın ve alanlarınızın "utf8 " olduğunu kontrol edin. (Mysql kullandığınızı varsayıyıorum.)

Sphinx ayar dosyasında ilgili "index" ayarı için  şu iki satır ekli olmalı :


charset_type            = utf-8

charset_table           = A->a, B->b, C->c, U+C7->U+E7, D..G->d..g, U+011E->U+011F, H->h, U+49->U+131, U+130->i, J..O->j..o, U+D6->U+F6, P->p, R..U->r..u, U+15E->U+15F, U+DC->U+FC, X->x, W->w, V->v, Y->y, Z->z, a, b, c, U+E7, d..g, U+11F, h, U+131, i..o, U+F6, p, r..u, U+15F, U+FC, x, w, v, y, z

Ayar dosyasında "source" ayarı için de bu satır önemli :


sql_query_pre                   = SET NAMES utf8


Ayrıca min_word_len değerini biraz yükseltirseniz de kimseye zarar gelmez.
min_word_len            = 3

Monday, June 11, 2012

Xubuntu çift monitör sorunları

Ubuntu'da Xfce ile çift monitor ayarları tam bir işkence. Eğer ki  monitörlerinizden birisi farklı yönde çevrilmiş durumdaysa sizi çok uğraştıracaktır.  randr ile uğraşması berbat bir durum.
arandr daha görsel ve pratik bir araç. Oldukça küçük kullanışlı.

apt-get install arandr

veya kaynaktan

git clone git://gitorious.org/arandr/arandr.git