innoDBの最初の挙動

データベース

バックアップに関わる実験の１つ。
現在僕のPCには、MySQL6が入っている。恥ずかしながらほとんど使われていないので、innoDBのibdataファイルの初期化とib_logfile0とib_logfile1がどうなるかを知ろうと思った。
ibdataにはinnoDBテーブルのデータとインデックスデータが、全てのデータベースから入れられている。これはテーブルスペースとして一定量確保されている。容量が足りなくなると、さらに一定量追加される仕組みのようだ。データの消去をしても残るらしいので、ファイルサイズは自然に小さくなることはない。このファイルサイズの大きさを適正にしたい場合は、mysqldumpをして、必要ファイルを削除してから、リストアしないといけない。
まずはmysqldumpをする。が、僕のデータベースにはテスト用だけなのでバックアップをとらなかった。mysql用のデータを保存してあるテーブルはMyISAMで動いているので問題ない。
innoDBのテーブルを削除する。これで、それぞれのデータベースディレクトリのテーブル名.frmという構造ファイルが消去されるはず。次にmysqlを停止させてから、indata, ib_logfile0, ib_logfile1を手動でファイル削除する。
その後、mysqlを起動させる。そうすると、innoDBのテーブルを作っていないのにも関わらず、ibdata, ib_logfile0, in_logfile1が作成された。my.cnfでskip innoDBのコメントアウトをはずしてあるので、つまりinnoDBを使用する宣言をしてあるので、innoDB用のテーブルスペースが確保されたみたいだ。ちなみに、ファイルサイズは３つとも、10,240キロバイト。初期値は１０メガということか。


このテーブルスペースがむやみに大きくならないように、次のものをmy.cnfに追加する。

[mysqld]
innodb_file_per_table

これにより、ibdataファイルが必要以上に大きくならず、それぞれのデータベースディレクトリに、テーブル名.ibdというファイルが作成されるようになり、それぞれのデータがテーブルごとに分散する。
これにより管理やデフラグメント化が容易になる。
ただ、ibdataファイルを大きくしたくないだけならば、

innodb_data_file_path=ibdata1:10M:autoextend:max:250G

これをmy.cnfに書くことによって、最大２５０ギガバイトまでと決めることもできる。２５０ギガバイトを越えようとするとエラーがでるようになる。

ドラッグオンドラグーン２

ゲーム

第１１章３節、４節、フリーミッション古の墓標：上空、フリーミッション古の墓標内部：上空クリア。


第１１章３節。敵はアークドラゴンだけ。封印騎士団の飛空挺が倒されないように戦う必要があるのだけど、ほとんど無視していてもまず落ちない。こっちが死なないようにだけ戦えばいい。
第１１章４節。マナ戦。連続攻撃はほとんどしないほうがいい。１撃か２撃当ててマナをふっとんだら攻撃をやめる。または兜割りを当てていくだけでもいい。とりあえず本体がどれかだけちゃんと見極めて攻撃していけばいい。連続攻撃をしているとマナの分身に攻撃されるだけ。しかもダメージも高い。もちろん本物のマナの攻撃が１番強い。
フリーミッション古の墓標：上空。肉塊の魔物が１０体くらい。普通に倒す。特殊な攻撃音がしたら回避。つぎはスピリット１０体くらいと死神２体。スピリットを先に倒してから死神を倒す。次は緑の吊り下げられた魔物。吊り下げられているうちに攻撃。近づきすぎると動き出すので、動き出さない距離で倒してしまうほうがいい。
フリーミッション古の墓標内部：上空。道に迷いやすい。始まったら真下の穴に向かう。位置見失った場合は地図の中心部分に穴はある。道沿いにすすんで球体と４つの輪の部屋。輪を止めて扉に進み、ターゲットの方向に進み水晶を攻撃。扉が開くので敵がい方につっこむ。敵は無視して進んでいい。部屋では上下２つの水晶を攻撃。部屋の下側の道が開く。そこから進むとゴールの古の墓標の外が見える。外にでればクリアなのだけど、外が見える部屋を左の道に進み、縦長の部屋の上の道を進み、別の部屋にでて敵は無視して水晶を攻撃。縦長の部屋に戻り、下の道を進む。その部屋では砲台を８つ倒す。そうするとレグナが杖を見つける。それから元来た道を戻り、外を目指してクリアする。時間制限もあり、道にも迷いやすい。
斉天の赤杖の入手。

debian（Linux）でのデータファイル群の場所

データベース Linux

結論を先にいうと、/var/lib/mysqlということです。


自分のPC内ではすぐに見つかったテーブルごとのファイルや、ibdataなどだったのだけど、仕事用のサーバでは見つからない。僕のPCは、windowsだから分かりやすい位置にあったのだろうか。普通にmysqlディレクトリのdataディレクトリの中にibdataやib_logfileはあり、そこにデータベースごとのディレクトリがあってその中に、MyISAMのテーブル構造（.frm）やデータ（.MYD）やインデックス(.MYI)やinnDBのテーブル構造（.frm）があった。


しかし、Linuxでは、/etc/mysqlの中にdataディレクトリがない。これはWinSCPで見たので権限とかの問題で隠されているのかと、Puttyでつないで、慣れないLinuxコマンドを怯えながら使って/etc/mysqlの中を見たのだけど、それらしいものは発見できなかった。ちなみに今回使ったのは、ls -l(ディレクトリ内を見るコマンド　-aオプションは.ではじまる隠しファイルも見れる)とcd（ディレクトリ移動コマンド）でした。

cd /etc/mysql

のような感じでした。これら２つのコマンドは、書き変えたりするわけでもないのだけど、やっぱりLinuxはこわい。と言いつつも慣れていかないといけない。


話がずれてしまったのだけど、ちょうどLinuxのcdコマンドを見ていたときに、Linuxのディレクトリのおおまかな説明があって、etcはシステム設定ファイルのあるところとあり、それならここにデータがあるわけはないと感じた。その表を見ていると、varにログファイルやスプールがあると書いてあるので、そこを確認しにいく。他のページも参考にすると,ファイル郡は/var/data/mysql/data/***/とあるので、とりあえずWinSCPで探っていく。var内にdataディレクトリがない。あとは勘でmysqlのディレクトリがないかを見ながら探していくと、/var/libの中にmysqlを発見。そして、さらにmysqlの中を見るとibdata, ib_logfileなどを目的のものを発見した。長い旅だった。前回ないと思って探して１時間、今回１時間の旅でした。
そしてもって、設定ファイルmy.cnfをみると

[mysqld]
datadir = var/lib/mysql

という感じにちゃんとどこにデータベースディレクトリがあるか書いてあるわけです。ちゃんと確認しておきなさいということなんだろうけど、知らないことばかりで全てはあとで気づく。


/var/lib/mysqlに、ibdata, ib_logfile0, ib_logfile1がある。それ以降のデータベースディレクトリに.frmが存在する。現在運用しているサーバでのデータ容量は、ibdataは96M、 ib_logfileは両方とも5Mだった。