저번에도 비슷한 문제가 있었다.

이번에는 정전으로 인해서 NFS 연결이 비정상적으로 끊겨 mysqld 서버를 시작하지 못했다.
개발서버 용으로 사용하고 있는데,

실서버 --> rsync 로 데이터 백업(백업서버,NFS서버)  --> NFS 로 mysql 데이터 연결(개발서버)

개발서버로 직접 mysql 데이터를 백업받아서 하면 별 문제 없겠지만,
백업서버에 일괄적으로 백업받기 위해 NFS 로 연결해서 사용하고 있다.

이번의 에러메세지는 지난번과 비슷한데

InnoDB: Unable to lock ./ibdata1, error: 11

대신에

InnoDB: Unable to lock ./ibdata1, error: 13

으로 차이가 있었다.

관련 검색을 해보니,
 - http://bugs.mysql.com/bug.php?id=14281
 - http://bugs.mysql.com/bug.php?id=22667
의 글을 찾을 수 있었다. 

위 글의 요지는 mysql 데이터를 NFS 로 연결해서 사용하는 것은 '좋은 생각이 아니다'  라는 것.

이번에 원인을 해결하기 위해 이리저리 설정을 바꿔보고 하던중.
InnoDB 에 대해서 그런 문제가 발생하는 듯 싶다.(MyISAM 은 괜찮은 듯)

그리고, NFS 서버가  nfs-kernel-server 와 nfs-user-server  가 있다.
여기에서 nfs-user-server 로 하면 실행이 되지 않았다.
그런데, nfs-kernel-server 로는 실행의 문제점은 없었다.(우분투 기준)

원래 nfs-kernel-server 였는데 바꿔본다고 nfs-user-server 로 바꾼후 위와 같은 에러가 발생한듯 하다.
바꾼이유가 NFS 서버가 마운트는 되는데, 데이터를 열지 못하는 문제가 있었다.
그 문제는 어이없게도 정전이 되면서 허브에 문제가 발생했던것(허브 restart 로 해결. 허브를 좋은 것으로 바꿔야 겠다.)

즉, mysql 데이터를 NFS 로 연결시 InnoDB 를 쓴다면, nfs-kernel-server 로 NFS 서버를 구동한다.
(nfs-user-server 로 안되는 것을 확인했지만, 좀더 살펴볼 예정)

mysql 의 데이터를 NFS 로 연결해서 쓰는 분들이 있을 것이다.

구성은 이렇게

mysql 서버  --> NFS 서버(mysql 데이터)

이렇게 쓰는 경우는 별로 없으려나? 아무튼 나의 개발환경은 저렇게 구성되어 있다.
테이블 형식은 InnoDB 를 쓰고 있다.(MyISAM 형식도 같은 문제가 발생하는지는 확인하지 않았다.)

개발서버가 실수로 인해 꺼져버렸다.(Ctrl-Alt-BS ㅜㅜ , DontZap 옵션을 잊었다)

혹시나 해서 DontZap 옵션은 이렇게

그냥 대수롭지 않게 다시 켰다.
그런데, mysql 서버가 정상실행이 되지 않았다.
로그메시지를 보니(/var/log/syslog) 잔뜩 에러메시지가 기록되어 있었다.

NFS 서버가 연결된 방식이 아니라도 마찬가지인지 확인을 해보지는 않았다.

syslog 에 기록된 메세지는 이렇다.

 mysqld[6607]: InnoDB: Check that you do not already have another mysqld process
 mysqld[6607]: InnoDB: using the same InnoDB data or log files.
 mysqld[6607]: InnoDB: Unable to lock ./ibdata1, error: 11
 mysqld[6607]: InnoDB: Check that you do not already have another mysqld process
 mysqld[6607]: InnoDB: using the same InnoDB data or log files.
 mysqld[6607]: InnoDB: Unable to lock ./ibdata1, error: 11
 mysqld[6607]: InnoDB: Check that you do not already have another mysqld process
 mysqld[6607]: InnoDB: using the same InnoDB data or log files.
 mysqld[6607]: 071121 17:12:51  InnoDB: Unable to open the first data file
 mysqld[6607]: InnoDB: Error in opening ./ibdata1
 mysqld[6607]: 071121 17:12:51  InnoDB: Operating system error number 11 in a file operation.
 mysqld[6607]: InnoDB: Error number 11 means 'Resource temporarily unavailable'.
 mysqld[6607]: InnoDB: Some operating system error numbers are described at
 mysqld[6607]: InnoDB: http://dev.mysql.com/doc/mysql/en/Operating_System_error_codes.html
 mysqld[6607]: InnoDB: Could not open or create data files.
 mysqld[6607]: InnoDB: If you tried to add new data files, and it failed here,
 mysqld[6607]: InnoDB: you should now edit innodb_data_file_path in my.cnf back
 mysqld[6607]: InnoDB: to what it was, and remove the new ibdata files InnoDB created
 mysqld[6607]: InnoDB: in this failed attempt. InnoDB only wrote those files full of
 mysqld[6607]: InnoDB: zeros, but did not yet use them in any way. But be careful: do not
 mysqld[6607]: InnoDB: remove old data files which contain your precious data!
 mysqld[6607]: 071121 17:12:51 [ERROR] Can't init databases
 mysqld[6607]: 071121 17:12:51 [ERROR] Aborting

핵심은 바로 이 메시지

 mysqld[6607]: InnoDB: Unable to lock ./ibdata1, error: 11
 mysqld[6607]: InnoDB: Check that you do not already have another mysqld process
 mysqld[6607]: InnoDB: using the same InnoDB data or log files.

이상하다. mysqld 가 떠 있지는 않는데.
NFS 의 버그인지, 그냥 정상적인 것인지는 모르겠다.
그렇게 mysql 서버가 crash 된 후에 다시 켜면, NFS 서버쪽의 파일이 lock 된 상태로 있는 것이었다.

NFS 서버를 다시 재 실행 해주니 정상적으로 mysqld 가 실행되었다.

syslog 를 보면 다음처럼 복구한다는 메시지도 볼 수 있다.

 mysqld[7030]: 071121 17:42:10  InnoDB: Database was not shut down normally!
 mysqld[7030]: InnoDB: Starting crash recovery.
 mysqld[7030]: InnoDB: Reading tablespace information from the .ibd files...
 mysqld[7030]: InnoDB: Restoring possible half-written data pages from the doublewrite
 mysqld[7030]: InnoDB: buffer...
 mysqld[7030]: 071121 17:42:15  InnoDB: Starting log scan based on checkpoint at
 mysqld[7030]: InnoDB: log sequence number 0 123193550.
 mysqld[7030]: InnoDB: Doing recovery: scanned up to log sequence number 0 123193550
 mysqld[7030]: InnoDB: Last MySQL binlog file position 0 79, file name /var/log/mysql/mysql-bin.001118
 mysqld[7030]: 071121 17:42:15  InnoDB: Flushing modified pages from the buffer pool...
 mysqld[7030]: 071121 17:42:16  InnoDB: Started; log sequence number 0 123193550
 mysqld[7030]: /usr/sbin/mysqld: ........ Source distribution
 /etc/mysql/debian-start[7063]: Checking for crashed MySQL tables.

실제 데이터도 이상이 없는지도 확인해봐야 겠다.(mysql 쪽에서 복구를 잘 해주려나?)


ps. 처음에는 안되서, 처음부터 초기세팅하고 받아놓은 dump 로 복구할까도 생각했다.
 비교적 간단하게 해결했다(데이터에 이상이 있는지는 확인이 필요하다)
 DB 에서 신뢰하는 것은 오직 dump 뿐.

RWAPM - 윈도우용 APM 시스템을 구축하기 쉽게 해주는 패키지.
http://kldp.net/projects/rwapm

그런데, RWAPM 의 기본 mysql 설정이 innodb 를 사용하지 않도록 되어 있음.

skip-innodb

사용하기 위해서는 skip-innodb 를 삭제하거나   #skip-innodb  주석처리를 합니다.

그런데, 기본설정으로는 유독 innodb 성능이 좋게 나오지 않았습니다.
그래서 몇가지 옵션을 조정하였습니다.

저는 아래처럼 조정했음.(주석처리 # 는 미적용 - 필요시 적용)

#skip-innodb

# 추가한 옵션들
#innodb_data_file_path = ibdata1:100M;ibdata2:100M;ibdata3:100M;ibdata4:100M:autoextend

# if memory.
innodb_buffer_pool_size = 256M
innodb_additional_mem_pool_size = 20M

# buffer
#innodb_log_file_size = 64M
#innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 0
innodb_lock_wait_timeout = 10

성능 저하원인이 각 옵션별로 테스트를 해보지 않아 확실하지 않지만,
innodb_flush_log_at_trx_commit 또는 innodb_buffer_pool_size 의 옵션이 영향을 주었을 듯 함.
(추후 세부 옵션 확인이 되면 추가로 작성)

윈도우용 RWAPM 이 실제 서비스에 사용하지는 않고, 테스트겸 사용하고 있는데 무척 훌륭합니다.
성능도 아주 잘 나오구요. (실제 서비스에 사용해도 좋을 정도로 좋습니다.)

RWAPM , XAMPP 등 윈도우용 APM 패키지들이 여러가지가 있는데, 그중에서 제일 나은 듯 합니다.
XAMPP 도 현재 테스트 중 (두개의 패키지가 거의 비슷한 느낌)