ERROR 1010 (HY000): Error dropping database (can’t rmdir ‘.\\’, errno: 17) hatası
mySQL üstünde bir veritabanını silmek istediğinizde bu hatayı alabilirsiniz.
Birkaç sebebi olabilir.
1. Veritabanının data dosyalarının olduğu dizinde gizli bir dosya olabilir.
2. Veritabanının data dosyalarının olduğu dizinde mySQL’in data dosyaları dışında başka dosyalar olabilir.
3. Veritabanının data dosyalarının olduğu dizinin hakları ile ilgili sorun olabilir.
vs. vs.
mysql> drop database test; ERROR 1010 (HY000): Error dropping database (can't rmdir '.\test\', errno: 17)
Yukardaki durumlardan birisi varsa onu çözüp sonra
mysql> drop database test; Query OK, 0 rows affected (0.01 sec)
silebilirsiniz.
Posted in Genel, Linux, MySQL on February 29th, 2012 by Kürşad DARA | | 0 Comments
“kernel: udev: renamed network interface eth0 to eth1” hatası
Vmware üstünde bir makine klonlayıp eth0’dan IP adresini değiştirdiğimde makine açıldığında eth0 ı aktif etmediğini yerine eth1 olarak aktif ettiğini görürseniz benim gibi, IP değiştirirken MAC adresini değiştirmemişsinizdir ve aşağıdaki gibi bir hata almışsınızdır.
Feb 24 00:38:41 mongodbs2 kernel: udev: renamed network interface eth0 to eth1
ve
[root@mongodbs2 ~]# ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:55 errors:0 dropped:0 overruns:0 frame:0
TX packets:55 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:5340 (5.2 KiB) TX bytes:5340 (5.2 KiB)
eth0 ın aktif olmadığını göreceksiniz.
[root@mongodbs2 ~]# ifconfig eth0 up
yazdığınızda ise
Device eth0 does not seem to be present, delaying initialization.
şeklinde bir hata alacaksınız.
[root@mongodbs2 ~]# ifconfig eth1 up
yazıp yolunuza devam edebilirsiniz. Ama kafaya takıp illa eth0 istiyorum derseniz bir ufak değişiklik yapmanız gerekecek.
[root@mongodbs2 ~]# cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# PCI device 0x8086:0x100f (e1000) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:aa:00:be", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
Burada diğer makinenin MAC adresi tanımlı kaldığı için sistem otomatik olarak eth1 e yeni MAC adresini verecek ve eth1 i aktif edecektir.
Buradan eth0 için MAC adresini doğru MAC adresi ile değiştirirseniz makineyi kapatıp açtığınızda ya da
[root@mongodbs2 ~]# ifconfig eth0 up
komutunu verdiğinizde sisteminiz eth0 üstünden çalışacaktır.
Tavsiyem makineyi kapatıp açmanız.
Posted in Linux on February 24th, 2012 by Kürşad DARA | | 0 Comments
mongoDB data dosyalarının purge edilmesi
mongoDB data dizinine baktığınızda
-rw------- 1 root root 64M 2012-02-21 12:04 xxx.0 -rw------- 1 root root 128M 2012-02-21 12:02 xxx.1 -rw------- 1 root root 256M 2012-02-21 12:02 xxx.2 -rw------- 1 root root 512M 2012-02-21 12:04 xxx.3 -rw------- 1 root root 1.0G 2012-02-21 12:03 xxx.4 -rw------- 1 root root 2.0G 2012-02-21 12:04 xxx.5 -rw------- 1 root root 2.0G 2012-02-21 12:03 xxx.6
şeklinde uzayıp giden dosyalar göreceksiniz.
Bu dosyalar belli zaman sonra artacaktır.
Bunun nedeni şu:
mongoDB belirli büyüklükte (Örn 2GB) data dosyaları tutuyor. Bu alanı kullansanızda kullanmasanız da bu alanı ayırıyor. Siz veritabanı üstünde delete ve insertler yaptığınızda mongoDB’ni bu alanlardaki dataları delete etse bile hala bu alanı ayırmaya devam ediyor.
Bu yüzden belirli aralıklarla bu alanları free etmeniz gerekiyor.
Bunun içinde db.repairDatabase() komutunu çalıştırıp bu alanları free edebilirsiniz.
Komutu;
PRIMARY> use xxx
switched to db xxx
PRIMARY> db.repairDatabase();
{ "ok" : 1 }
şeklinde çalıştırabilirsiniz.
Not : Burada xxx fazlasıyla yer kaplayan veritabanının ismi.
Bu işlem sırasında bu veritabanınızı lock edeceği için production makinesinde yapacaksınız kullanılmadığı bir zamanda yapmanız mantıklı olur.
Yoksa;
Tue Feb 14 15:00:54 [conn78277] warning: ClientCursor::yield can't unlock b/c of recursive lock ns: xxx.xxx top: { opid: 212476020, active: true, lockType: "write", waitingForLock: false, secs_running: 1, op: "query", ns: "xxx", query: { repair
Database: 1.0 }, client: "xxx.xxx.xxx.xxx:38186", desc: "conn", threadId: "0x7f736eacc700", connectionId: 78277, msg: "index: (3/3) btree-middle", numYields: 0 }
şeklinde bir hata göreceksiniz log dosyasında.
Bu işlemler başarılı bir şekilde bittikten sonra gözle görülür şekilde disk kullanımından tasarruf etmiş olacaksınız.
Posted in Linux, MongoDB on February 21st, 2012 by Kürşad DARA | | 0 Comments
Anlık mongodb istatistikleri
Anlık olarak mongodb nin istatistiklerini görmek isterseniz:
root@mongodbs1:~# mongostat -h xxx.xxx.xxx.xxx
connected to: xxx.xxx.xxx.xxx
insert query update delete getmore command flushes mapped vsize res faults locked % idx miss % qr|qw ar|aw netIn netOut conn set repl time
0 0 0 0 1 2 0 14.2g 29.2g 2.86g 0 0 0 0|0 1|0 239b 1k 5 myset M 12:14:35
0 0 0 0 0 2 0 14.2g 29.2g 2.86g 0 0 0 0|0 1|0 192b 1k 5 myset M 12:14:36
0 0 0 0 1 2 0 14.2g 29.2g 2.86g 0 0 0 0|0 1|0 239b 1k 5 myset M 12:14:37
0 0 0 0 0 2 0 14.2g 29.2g 2.86g 0 0 0 0|0 1|0 192b 1k 5 myset M 12:14:38
0 0 0 0 1 2 0 14.2g 29.2g 2.86g 0 0 0 0|0 1|0 239b 1k 5 myset M 12:14:39
0 0 0 0 0 2 0 14.2g 29.2g 2.86g 0 0 0 0|0 1|0 192b 1k 5 myset M 12:14:40
0 0 0 0 1 2 0 14.2g 29.2g 2.86g 0 0 0 0|0 1|0 239b 1k 5 myset M 12:14:41
0 0 0 0 0 2 0 14.2g 29.2g 2.86g 0 0 0 0|0 1|0 192b 1k 5 myset M 12:14:42
0 0 0 0 0 2 0 14.2g 29.2g 2.86g 0 0 0 0|0 1|0 192b 1k 5 myset M 12:14:43
0 0 0 0 1 2 1 14.2g 29.2g 2.86g 0 0 0 0|0 1|0 239b 1k 5 myset M 12:14:44
Posted in Linux, MongoDB on February 17th, 2012 by Kürşad DARA | | 0 Comments
ERROR 126 (HY000): Incorrect key file for table ‘/mnt/mysql-tmp/#sql_1a76_2.MYI’; try to repair it hatası
mySQL de bir query çalıştırdığınızda;
ERROR 126 (HY000): Incorrect key file for table '/mnt/mysql-tmp/#sql_1a76_2.MYI'; try to repair it
hatasını alıyorsanız bunun birkaç sebebi olabilir.
1. mySQL’in temp tabloları oluşturduğu dizini RAM üzerinde oluşturacak şekilde ayırdıysanız ve örneğin 2GB alan verdiyseniz ve gönderdiğiniz querynin oluşturduğu temp tablosu 2GB’tan büyük ise bu hatayı alırsınız. Bunun çözümü ya RAM’de temp tablo için ayırdığınız alanı artıracaksınız ya da querynizi optimize edeceksiniz.
/dev/ram1 2.0G 0 2.0G 0% /mnt/mysql-tmp
kursad:/mnt/mysql-tmp # ls -la /mnt/mysql-tmp/ total 2.0G drwxrwxrwt 2 root root 80 Feb 16 11:01 . drwxr-xr-x 9 root root 4.0K Feb 15 14:16 .. -rw-rw---- 1 mysql mysql 2.0G Feb 16 11:01 #sql_1a76_0.MYD -rw-rw---- 1 mysql mysql 1.0K Feb 16 11:01 #sql_1a76_0.MYI
2. İlgili tablo bozuk olabilir. Repair edip sorunu çözebilirsiniz.
Posted in Linux, MySQL on February 16th, 2012 by Kürşad DARA | | 0 Comments
InnoDB: Unable to lock ./xxxxxx/xxxxx.ibd, error: 11 hatası.
InnoDB bir veritabanında sunucuyu resetledikten sonra aşağıdaki hatayı aldık.
120209 05:12:29 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/data/ 120209 5:12:29 [Note] Plugin 'FEDERATED' is disabled. InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib_logfiles! 120209 5:12:29 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... InnoDB: Unable to lock ./xxxxxx/xxxxx.ibd, error: 11 InnoDB: Check that you do not already have another mysqld process InnoDB: using the same InnoDB data or log files. 120209 5:12:29 InnoDB: Assertion failure in thread 47546054463296 in file fil/fil0fil.c line 635 InnoDB: Failing assertion: ret InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html InnoDB: about forcing recovery. 120209 5:12:29 - mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=104857600 read_buffer_size=52428800 max_used_connections=0 max_threads=512 threads_connected=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 52536408 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd: 0x0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = (nil) thread_stack 0x40000 /usr/local/mysql/bin/mysqld(my_print_stacktrace+0x2e)[0x8ad46e] /usr/local/mysql/bin/mysqld(handle_segfault+0x322)[0x5e05c2] /lib64/libpthread.so.0[0x39a0a0e4c0] /lib64/libc.so.6(gsignal+0x35)[0x39a0230215] /lib64/libc.so.6(abort+0x110)[0x39a0231cc0] /usr/local/mysql/bin/mysqld[0x7acc5c] /usr/local/mysql/bin/mysqld[0x7acdf9] /usr/local/mysql/bin/mysqld(fil_space_get_size+0xde)[0x7b407e] /usr/local/mysql/bin/mysqld(fil_check_adress_in_tablespace+0x9)[0x7b4159] /usr/local/mysql/bin/mysqld(trx_sys_doublewrite_init_or_restore_pages+0x2d5)[0x82b6d5] /usr/local/mysql/bin/mysqld(recv_recovery_from_checkpoint_start+0x175b)[0x7dbe0b] /usr/local/mysql/bin/mysqld(innobase_start_or_create_for_mysql+0x115f)[0x81b8cf] /usr/local/mysql/bin/mysqld[0x777d64] /usr/local/mysql/bin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x31)[0x6cf411] /usr/local/mysql/bin/mysqld[0x75513a] /usr/local/mysql/bin/mysqld(_Z11plugin_initPiPPci+0x875)[0x757c95] /usr/local/mysql/bin/mysqld[0x5e0d95] /usr/local/mysql/bin/mysqld(main+0x1c1)[0x5e50b1] /lib64/libc.so.6(__libc_start_main+0xf4)[0x39a021d974] /usr/local/mysql/bin/mysqld(fmod+0x62)[0x513c0a] The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. 120209 05:12:29 mysqld_safe mysqld from pid file /usr/local/mysql/data//xxxxxx.pid ended
Çözüm olarak mysql i durdurup *.ibd dosyalarını taşıyıp tekrar cp -a ile kopyaladık ve mysql i çalıştırdık sorunumuz düzeldi.
Basit shell script şöyle :
#!/bin/bash for i in `ls -a *.ibd` do mv $i $i.bak cp -a $i.bak $i done
Posted in Linux, MySQL on February 9th, 2012 by Kürşad DARA | | 0 Comments
stdin: is not a tty hatası
ssh ile remote olarak bir komut çalıştırmak istediğimde “stdin: is not a tty” hatası aldım.
Çözümü şöyle :
/etc/bashrc içindeki mesg y satırının başına # koyup iptal ettim.
Sonrada
source /etc/bashrc
komutunu çalıştırdım.
Sorun çözüldü.
Posted in Linux on February 2nd, 2012 by Kürşad DARA | | 0 Comments
