背景
dockerでmysqlを使っていたのですがどうもPCの調子が悪いのか強制再起動を１日に３度も食らったりしていたら... mysqlが起動しなくなりました!!!!
socketのエラーとかかと思ったら、明らか初体験だったのでメモ。
2018-11-20 14:41:59 7fa44606e700 InnoDB: Error: page 3 log sequence number 52788630
InnoDB: is in the future! Current system log sequence number 52782638.
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.6/en/forcing-innodb-recovery.html
InnoDB: for more information.
2018-11-20 14:41:59 7fa44606e700 InnoDB: Assertion failure in thread 140343526221568 in file trx0purge.cc line 705
InnoDB: Failing assertion: purge_sys->iter.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.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
05:41:59 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.
key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68108 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 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 = 0 thread_stack 0x40000
mysqld(my_print_stacktrace+0x2c)[0x55eca997305c]
mysqld(handle_fatal_signal+0x4b1)[0x55eca9710b51]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x7fa47259b0c0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x7fa471137fff]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fa47113942a]
mysqld(+0x7b35b7)[0x55eca9a645b7]
mysqld(+0x7b4707)[0x55eca9a65707]
mysqld(+0x7b55ab)[0x55eca9a665ab]
mysqld(+0x7a8d6e)[0x55eca9a59d6e]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7494)[0x7fa472591494]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7fa4711edacf]
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.
構成
某プロジェクトでdocker-composeを使っているのですが、こんな構成にしています。
階層
docker
├── mysql
│ ├── Dockerfile
│ ├── my.cnf
│ ├── password.yml
│ ├── password.yml.sample
│ └── volumes
│ ├── auto.cnf
│ ├── ib_logfile0
│ ├── ib_logfile1
│ ├── ibdata1
│ ├── mysql
│ ├── performance_schema
│ ├── my_development
│ ├── my_test
├── nginx
│ ├── Dockerfile
│ ├── nginx.conf
│ └── nginx.conf.sample
├── rails
│ └── Dockerfile
│
└── docker-compose.yml
docker-compose.yml
version: '2'
services:
app:
build:
context: .
dockerfile: ./docker/rails/Dockerfile
args:
GITHUB_USERNAME:
GITHUB_TOKEN:
command: sh -c "rm -rf tmp/pids/server.pid; bundle exec rails s -p 5000 -b 0.0.0.0"
ports:
- "5000:5000"
- "8088:8088"
volumes:
- .:/myapp
- public-data:/myapp/public
- tmp-data:/myapp/tmp
- log-data:/myapp/log
- gem-data:/usr/local/bundle
- npm-data:/myapp/node_modules
tty: true
stdin_open: true
environment:
RAILS_ENV: development
TZ: "Asia/Tokyo"
MAINTENANCE_MODE: "false"
MAINTENANCE_MESSAGE: "※2018年10月16日 午後19時 〜 2018年10月16日 午前5時"
ALLOWED_IPS: "172.28.0.1" #"172.28.0.1,172.28.0.2"
extends:
file: ./docker/mysql/password.yml
service: password
depends_on:
- db
db:
build: ./docker/mysql/
ports:
- "3333:3306"
volumes:
- ./docker/mysql/volumes:/var/lib/mysql
extends:
file: ./docker/mysql/password.yml
service: password
environment:
TZ: "Asia/Tokyo"
nginx:
build:
context: docker/nginx
volumes:
- .:/myapp
- public-data:/myapp/public
- tmp-data:/myapp/tmp
ports:
- 81:80
depends_on:
- app
environment:
TZ: "Asia/Tokyo"
volumes:
public-data:
tmp-data:
log-data:
gem-data:
npm-data:
db-data:
driver: "local"
原因
mysqlが予期せぬ事態（PCの強制終了）でログファイルがクラッシュしていました。
├── mysql
│ ├── Dockerfile
│ ├── my.cnf
│ ├──
│ └── volumes
│ ├── auto.cnf
│ ├── ib_logfile0 ← この辺が怪しい
│ ├── ib_logfile1 ← この辺が怪しい
│ ├── ibdata1 ← この辺が怪しい
│ ├── mysql
│ ├── performance_schema
│ ├── my_development
│ ├── my_test
解決策1
volumesで永続化しているib_logfile0,ib_logfile1を削除してmysqlコンテナを再起動してみました。
起動するようになりましたが、何度かDBにアクセスするとまたクラッシュしてしまうループに陥りました。
├── mysql
│ └── volumes
│ ├── auto.cnf
│ ├── ib_logfile0 ...これを削除
│ ├── ib_logfile1 ...これを削除
これだけでは解決されず...(T_T)
解決策2
my.cnfにinnodb_force_recovery=3を追記
[mysqld]
innodb_force_recovery=3
再ビルド
$ docker-compose build --no-cache
これで一時的にDBにアクセスできるようにはなりますがクエリを実行するとエラーがでます。
これはあくまでデータベースに入ることを可能にし、バックアップ用にデータベースをエクスポートするための一時的な手段です。なので一旦DBをエクスポートをしておきましょう！
永続化フォルダを削除する
docker/mysql/volumesフォルダを削除する
└ ※ 永続化ファイルを置いてある箇所なので自身で異なります
docker
├── mysql
│ ├── Dockerfile
│ ├── my.cnf
│ ├── password.yml
│ ├── password.yml.sample
│ └── volumes ← 先程SQLでバックアップを取ったので、このフォルダ(DB永続化用のデータフォルダ）を削除します
│ ├── auto.cnf
│ ├── ib_logfile0
│ ├── ib_logfile1
│ ├── ibdata1
削除したら再ビルド
$ docker-compose build --no-cache
解決した！！！！
まとめ
つまり、永続化しているフォルダを削除して（バックアップをとった上で）、再度ビルドすれば治るということでした。
永続化しているファイルがPCの強制終了でいずれかのファイルがクラッシュしてしまったということだろう。
どのファイルがクラッシュしていたのかもはや調べるのがダルメシアンだったので、
今回は僕の解決策が参考になればと共有しました。