윈디하나의 블로그

글쓴시간 2022/04/23 14:42

MySQL 크래시 - 백업된 데이터로 복구

블로그를 백업본으로 복구했다. 갑자기 아래와 같은 로그를 내면서 MySQL 이 죽어서 그렇다.

2022-04-20T09:00:24.015047Z 0 [Note] [MY-011953] [InnoDB] Page cleaner took 4554ms to flush 164 and evict 0 pages
17:00:26 UTC - mysqld got signal 11 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0x2b42e148
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 = 7fffbf04df10 thread_stack 0x46000
/usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z19my_print_stacktracePKhm+0x2e [0x385a3ee]
/usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'handle_fatal_signal+0x2f7 [0x26a6cb7]
/lib/amd64/libc.so.1'__sighndlr+0x6 [0x7fffbe14ebe6]
/lib/amd64/libc.so.1'call_user_handler+0x2f1 [0x7fffbe1406b1]
/usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z27free_blob_buffers_and_resetP5TABLEj+0x77 [0x2658077]
/usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z18close_thread_tableP3THDPP5TABLE+0xdc [0x24b192c]
/usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z19close_thread_tablesP3THD+0x28b [0x24b1c1b]
/usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_ZN18Prepared_statement7prepareEPKcmPP10Item_param+0x881 [0x25807f1]
/usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z19mysqld_stmt_prepareP3THDPKcjP18Prepared_statement+0xb6 [0x2581016]
/usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0x2097 [0x2556917]
/usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z10do_commandP3THD+0x174 [0x2557344]
/usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'handle_connection+0x278 [0x2698468]
/usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'pfs_spawn_thread+0x161 [0x3d8e4b1]
/lib/amd64/libc.so.1'_thrp_setup+0xa4 [0x7fffbe14e7e4]
/lib/amd64/libc.so.1'_lwp_start+0x0 [0x7fffbe14eac0]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (2b436af0): SHOW TABLES LIKE 'piwik_archive_numeric%'
Connection ID (thread ID): 1903317
Status: NOT_KILLED

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.

-이후 재시작하면

2022-04-21T00:10:10.515295Z 1 [Note] [MY-011089] [Server] Data dictionary restarting version '80023'.
2022-04-21T00:10:10.869298Z 1 [Note] [MY-012357] [InnoDB] Reading DD tablespace files
2022-04-21T00:10:10.914548Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
2022-04-21T00:10:10.915345Z 0 [ERROR] [MY-010119] [Server] Aborting
2022-04-21T00:10:10.916445Z 0 [Note] [MY-010120] [Server] Binlog end
2022-04-21T00:10:10.916763Z 0 [Note] [MY-010733] [Server] Shutting down plugin 'MyISAM'
2022-04-21T00:10:10.916890Z 0 [Note] [MY-010733] [Server] Shutting down plugin 'InnoDB'
2022-04-21T00:10:10.917046Z 0 [Note] [MY-013072] [InnoDB] Starting shutdown...

바로 종료됨.

- 구글링도 해봤지만 흔한 에러는 아닌듯 하다. 메시지만 보면 Data Dictionary 를 초기화하다가 오류. 그렇다면 mysql.ibd 파일에 문제가 있다는 거긴 하지만, MySQL 지원을 받을 수 있는건 아니라 포기. 만약 업체였다면 비용 들여서라도 지원받으면 되지 않을까 하는 생각이다. 예전에 5.x 버전에서 8 로 업그레이드가 제대로 안된것 같기도 하다.

- 처음에 난 덤프도 DataDictionary 를 조회하다가 오류난 것이기도 하다. 결국은 복구 불가로 판정했고 바로 백업본을 리스토어 했다. 이래서 백업은 중요하다. 매우 중요하다.

- 어쨌든 복구하느라고 MySQL 8을 재설치하고 백업본을 복구한거기 때문에, 서버가 꽤 빨라졌다. my.cnf 파일도 처음부터 재작성했다. 어쨌든 괜찮아진 느낌.

----

2022.04.26 추가

MySQL 8을 작년에 설치한것도 MySQL 5.x 에서 업그레이드한거였는데, 지금 생각해보면 뭔가 업그레이드가 잘못되었을 거 같다. my.cnf 에 문제가 있었는데도 작동했기 때문. MySQL 8 설치하고 첫 실행했을때 기동이 안되었다. my.cnf 를 초기화(내용을 전부 지움)하면 기동이 되었고. 뭔가 설정에 문제가 있긴 했던 느낌.