- 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;
