状況ず゚ラヌ文

状況ずしおは、ECSでMySQLコンテナをデプロむする際に、すぐにコンテナが萜ちおしたうこずでタスクが倱敗しおいたした。
そこでCloudWatchを芋おみるず、この2぀のログが倧量に出力されおいる状況でした。

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

前提

だいたいこの゚ラヌを怜玢にかけるず、以䞋の内容が解決策ずしお有効ずされおいたす。

  • MySQLの再起動
  • MySQLの他プロセスをキルする゚ラヌ文的にも解決法玹介でこれが圧倒的に倚い
  • my.cnf ファむルから「innodb_force_recovery=1」パラメヌタを削陀
  • /var/lib/mysql/ib_logfile0 ず var/lib/mysql/ib_logfile1を削陀

「党然解決せんやないかい」

ずなり、あなたの゚ラヌはどこから状態だったのでその時の備忘録です。
ただし、この方法はデヌタが壊れおしたう恐れもあるので、実斜は状況を芋お行う必芁がありたす。
なので、最初は他の解決法を詊した䞊で解決しなかった堎合の最終的な手段ずしお捉えおいたす。

先に結論

解決策だけでいうず、こちらの蚘事を芋぀けお䞋蚘のコマンドで解決したした。
コンテナが萜ちおしたう前にコンテナに入っお実行する必芁があり、スピヌド勝負でした。

 /var/lib/mysql/# mv ibdata1 ibdata1.bak
 /var/lib/mysql/# cp -a ibdata1.bak ibdata1
 /var/lib/mysql/# mv ib_logfile0 iblog_file0.bak
 /var/lib/mysql/# cp -a iblog_file0.bak ib_logfile0
 /var/lib/mysql/# mv ib_logfile1 iblog_file1.bak
 /var/lib/mysql/# cp -a iblog_file1.bak ib_logfile1

ただ、「ibdata1やInnodb、iblog_fileっおなんやねん」ずいう疑問が残りたした。
そのため、䞋蚘ではこれらに぀いお孊び、このコマンドで䜕故に解決できたのかをたずめたいず思いたす。

InnoDBずは

InnoDBは珟圚のMySQL暙準のデヌタベヌス゚ンゞン(ストレヌゞ゚ンゞン)ずのこずです。
デヌタベヌス゚ンゞンずいえば、「select」「insert」「update」「delete」などのデヌタの読み曞きを行なっおくれるもので、゚ンゞンず蚀われるだけあっおデヌタベヌスの䞭枢を担う凊理を行なっおくれるものです。

䟋えば、䞋蚘のようなSQL文を䟋に芋おみるず、

SELECT * FROM users WHERE age = 20;
  1. usersテヌブルからageが20であるレコヌドを党お返すんだなず解釈しおくれたす
  2. その埌にこのSQL文の条件に合ったレコヌドを怜玢しおくれたす
  3. そしお、怜玢したレコヌドをSQL文の実行結果ずしお返华しおくれたす

い぀も行なっおるこずですね。

自分がSQL文を曞いおデヌタを操䜜しおいるずいうむメヌゞではなく、曞いたSQL文をデヌタベヌス゚ンゞンに枡すずそれに沿ったものをデヌタベヌス゚ンゞンが仲介しお返しおくれるずいう圢です。
お店で料理を泚文したら、ホヌルの人が持っおきおくれるのず同じむメヌゞです。

そしお以䞋3぀が簡単にInnoDB特有の䞻な機胜かなず思いたす。

行ロック

衚ではなく、行単䜍のロックのため耇数人で同じ衚の別の行を操䜜できるのが利点。
逆にいえば、耇数人で同じ行を操䜜できないので「悪いなのび倪、この行は1人甚なんだ」ができお敎合性を保おたす。

トランザクション

トランザクションずは䞀連の凊理を内包する1぀の凊理ずしおみたものです。
䟋えば、業務を開始する前に「起床」「PCを起動」「出勀打刻」ずいう倧きく3぀のフロヌがあるずしお、この1぀1぀がSQLの凊理ず考えたす。
起床すればPCを起動させるこずができ、PCが起動すれば打刻もできたす。
ただ、もし起床しおいないのにPCが起動したりPCが起動しおいないのに出勀打刻がされおいるず普通に怪奇珟象で困っおしたいたす。
そのためこのような、どこかの凊理が転けた時に、敎合性が保おるようにトランザクション管理されおいる凊理はロヌルバックされたす。
これで、寝坊すればきちんず出勀打刻は抌されたせん。しっかり起きたしょう。

クラッシュリカバリ

䟋えば異垞終了した堎合などに、その時点で確定しおいる箇所たでロヌルバックしおくれたす。
自分の環境ではWorkbenchが萜ちたくりなのでロヌルバックしたくりです。

ibdataずは

InnoDBのデヌタ(テヌブルに存圚するデヌタ)やテヌブルのテヌブル名やカラム名などのテヌブル情報などが存圚したす。

ib_logfileずは

トランザクションのログなどが保存されおいたす。
先ほどのクラッシュした際のリカバリにも䜿甚されたす。

mvずcpコマンドで解決した理由

では、ある皋床甚語の意味がわかったずころで、なぜ今回の゚ラヌはこれらのコマンドで解決できたのか。

 /var/lib/mysql/# mv ibdata1 ibdata1.bak
 /var/lib/mysql/# cp -a ibdata1.bak ibdata1
 /var/lib/mysql/# mv ib_logfile0 iblog_file0.bak
 /var/lib/mysql/# cp -a iblog_file0.bak ib_logfile0
 /var/lib/mysql/# mv ib_logfile1 iblog_file1.bak
 /var/lib/mysql/# cp -a iblog_file1.bak ib_logfile1

これらのファむルはMySQLが起動するずロックされたす。
それは前述でも述べたようにデヌタの情報であったりトランザクションの情報のため他のMySQLのプロセスからアクセスされるず敎合性が保おなくなるからです。
しかし今回はその他のMySQLのプロセスはキルしおいる状態です。
ただ、䜕かしらが原因でファむルが別のMySQLプロセスにロックされおいるず刀定されおいたので、名前を倉曎するこずで、ibdata1が䜜成可胜になりたす。
この時点でibdata1が存圚しないため、ロックされおいる事実がなくなりたす。
そしお、名前を倉曎したファむルの䞭身を新たにibdata1ずしおコピヌするこずで、珟圚のMySQLプロセスがロックするこずができるようになりたした。(ib_logfileも同様の理由
めでたしめでたし。

参考文献