Subscribe

RSS Feed (xml)

Powered By

Skin Design:
Free Blogger Skins

Powered by Blogger

Jumat, 10 Juni 2011

MySQL lama waktu "stop slave"

Perusahaan membuka beberapa cabang baru. Maka diperlukan server baru untuk cabang beru tersebut. Seperti biasa install Adempeire server dan JasperServer termasuk replikasi mysqlnya. Namun ternyata salah satu cabang bermasalah dengan replikasi mysql. Waktu mau jalankan preintah stop slave, prosesnya terasa hang. Sangat lama tidak ada respon. Awalnya saya pikir hang, tapi diakhir-akhir waktu ternyata tidak hang, hanya sangat lama prosesnya. Memakan waktu 41 menit. Selain itu, proses stop service mySql pun memakan waktu yang lama.

Lama saya memikirkan apa yang terjadi di server itu? Padahal di server lain tidak masalah. Beberapa kali pun saya install ulang jasperserver beserta mysql nya. Tetapi tetap saja. Dugaan saya waktu itu adalah masalah koneksi. Saya coba ping dari dua arah (master dan slave) ternyata ok. (Dan ternyata ping tidak mewakili apakah master-slave bisa komunikasi). Saya coba melakukan trial & error untuk mencari penyebab masalah ini. Pertama saya istall ulang sekali lagi jaspernya. Saya coba lakukan start-stop server, ternyata tetap tidak mau stop. Logikanya dengan installan baru maka settingannya baru juga, yang lama adalah my.cnf nya. Maka saya buang my.cnf editan saya. Dan ternyata, start-stop sukses. Jadi penyebab ada di my.cnf. Sekarang saya trial error settingan di my.cnf. Dari banyak line di my.cnf saya sisakan line berikut:

# The following options will be passed to all MySQL clients
[client]
#password       = your_password
port            = 3306
socket          = /home/jasperserver-2.1/mysql/tmp/mysql.sock

# Here follows entries for some specific programs

# The MySQL server
[mysqld]
port            = 3306
socket          = /home/jasperserver-2.1/mysql/tmp/mysql.sock
#socket          =
skip-locking
key_buffer = 256M
max_allowed_packet = 1M
table_cache = 256
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size= 16M
# Try number of CPU's*2 for thread_concurrency
#thread_concurrency = 8
lower_case_table_names = 1

saya coba start-stop mysql, ternyata ok. Lalu saya tambah my.cnf dengan line:
server-id       = 16

Hasilnya: proses start-stop gagal! Ternyata line ini penyebabnya. Tapi masih tidak mengerti kenapa dengan menambah line itu langsung proses stop mysql server gagal? Line tersebut adalah proses pemberian id terhadap server mysql jika akan dijalankan proses replikasi. Jadi ketika server-id diset, maka server akan melakukan koneksi ke master. Soalnya ketika saya saya buka status slavenya:

mysql> show slave status \G;
*************************** 1. row ***************************
             Slave_IO_State: Connecting to master
                Master_Host: XXXXX
                Master_User: XXXXX
                Master_Port: 0000
              Connect_Retry: 60
            Master_Log_File: mysql-bin.000000
        Read_Master_Log_Pos: 4
             Relay_Log_File: xxxxxxxxxxxxxx
              Relay_Log_Pos: 98
      Relay_Master_Log_File: mysql-bin.000000
           Slave_IO_Running: No
          Slave_SQL_Running: Yes

dan memang ketika di buka di masternya, ada percobaan koneksi dari slave ke master. Namun dalam beberapa detik langsung putus. Berarti masalahnya sebenarnya adalah koneksinya. Seperti tertolak.
Selain itu, pada settingan my.cnf masih blm ada tulisan bahwa masternya menuju ke mana. Kenapa mysql slave sudah memiliki data masternya? Ternyata mysql membaca dari  file  master.info and relay-log.info yang ada di direktory mysql/data. Jadi kalau mau ganti master, sebaiknya hapus terlebih dahulu master.info dan relay-log.info. 

[nnnn@xxxxxxx data]# ls *.info
master.info  relay-log.info

Nah sekarang kembali ke masalahnya, kenapa tidak mau konek ke master? Akhirnya saya wadhul ke rekan saya, pak Wahyu Pratama. Dia juga bingung, kenapa koq ga mau konek. Kemudian menyarankan cek apakah dari slave ke master bisa buka koneksi di port yang digunakan untuk replikasi. 

[nnnnn@xxxxx bin]# telnet xxx.xxx.xxx.xxx nnnn
Trying xxx.xxx.xxx.xxx...

Ternyata tidak mau konek setelah lama menunggu. Dicoba melakukan telnet pada server lain yang jelas-jelas bisa dilakukan telnet, dan bisa. Kesimpulannya bukan seperti dugaan awal, bahwa pihak penyedia line antar cabang yang melakukan penutupan port, karena melakukan koneksi ke cabang lain bisa. Berarti kemungkinan masalah koneksi dari slave-master itu sendiri. Tetapi dicoba ping bisa!! Pak Wahyu  bilang, ping itu pake ICMP, sarannya coba di SSH dari slave ke master. Ternyata tidak bisa!! Akhirnya saya coba cek di master...dan ternyata memang belum ada setting routing di master menuju slave. Setelah ditambah setting routing, ternyata semua beres 
Jadi semua gara PING