갑자기 또 로그인이 안되어서 확인해보니 얼마전에 정리했던 서버공간이 또 100% 다 쓰고 있다고 나온다.
족히 몇십기가는 쓸 용량이였는데 이상하다 해서 봤더니 /var/log/mysqld.log의 크기가 이틀사이에 몇십기가가 되었다.
그래서 로그를 확인을 해보니 아래와 같은것이 있었다.
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
디비가 날라가면 안되기 때문에 늘 조심을 하는데 근래에 들어서 자주 이런 문제가 있는것으로 봐서는 서버를 바꿔야 하는 시기가 온것인가 하는 생각이 들긴하지만.
아무튼간에 거의 1초보다 안되는 시간에 로그가 계속 쌓여갔다.
이 로그가 엄청나게 하루종일 24시간 쌓이기 때문에 몇십기가가 되어 버렸고 결과적으로 공간을 다 써버린다.
대단한 로그구나 무한루프처럼..
결과적으로 이러한 부분이 있다면 ibdata1이 위치한 곳을 이동을 하자
거기서 mv ibdata1 ibdata1.bak으로 변경을 한뒤에
cp -a ibdata1.bak ibdata1로 복구를 하자.
용량이 꽤 나는 크기 때문에 복사하는데 시간이 꽤 걸렸다.
관련
lsof -i:3306
Then kill it (the process number)
kill -9 PROCESS
e.g. kill -9 13498
find / -name 'mysqld.pid' # find / -name 'mysql.lock'
mysqld dead but subsys locked
하였으나 문제가 발생되서 시작과 바로 죽어버림.
해당 폴더에가서 ib_logfile0, 1을 다른이름으로 .bak으로 하고 재시작
그래도 에러가 발생
190116 18:47:20 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
190116 18:47:20 [Note] /usr/libexec/mysqld (mysqld 5.5.47) starting as process 22429 ...
190116 18:47:20 [Note] Plugin 'FEDERATED' is disabled.
190116 18:47:20 InnoDB: The InnoDB memory heap is disabled
190116 18:47:20 InnoDB: Mutexes and rw_locks use InnoDB's own implementation
190116 18:47:20 InnoDB: Compressed tables use zlib 1.2.3
190116 18:47:20 InnoDB: Using Linux native AIO
190116 18:47:20 InnoDB: Initializing buffer pool, size = 128.0M
190116 18:47:20 InnoDB: Completed initialization of buffer pool
190116 18:47:21 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 61952895721
190116 18:47:21 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: Doing recovery: scanned up to log sequence number 61953129123
190116 18:47:21 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
190116 18:47:21 InnoDB: 5.5.47 started; log sequence number 61953129123
190116 18:47:21 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
190116 18:47:21 [Note] - '0.0.0.0' resolves to '0.0.0.0';
190116 18:47:21 [Note] Server socket created on IP: '0.0.0.0'.
190116 18:47:21 [Note] Event Scheduler: Loaded 0 events
190116 18:47:21 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.47' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server (GPL)
190116 18:47:22 InnoDB: Assertion failure in thread 2776386448 in file trx0purge.c line 840
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
09:47:22 UTC - 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.
그리고 다시 재실행 했더니 아래 메세지가 다량 로그 기록됨.
190116 19:01:10 InnoDB: Error: page 114728 log sequence number 61952919111
InnoDB: is in the future! Current system log sequence number 61952878092.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: for more information.
my.cnf를 열어서 innodb_force_recovery = 4 를 입력후 재실행함 -> 됨.
그러나 뭔가 불안하다. 뭔가 innodb 테이블이 손상된거 같은데..
할 수 있는것은 다해봤다 작은거 하나까지도.
깨진 테이블 확인. 왜 했냐고 하면 drop table을 때리면 로그인이 끊긴다.
check table 테이블이름
analyze table 테이블이름
repair table 테이블이름
아.... 이거 때문에 뜬금없이 할일 아무것도 못하고 몇시간을 보낸건지..... 휴......
일단락 리커버 4번 옵션으로 해서 스타트시키고 다시 지우고 stop 후재시작하면 길던 에러가 나오지 않음.
추가로 테이블 에러가 나서 로그에 보면 is marked as crashed and should be repaired가 막 찍히기 시작하면 뭔가 막 Fixing index 어쩌구 나옴.
myisamchk -r *.MYI 해당 테이블 폴더에 가서 해주면 뭔가
이전은 해야겠다.
서버도 느려진거 같고 불안함이 엄습해오기는 하다.