にわかサーバー屋さんの覚書

サーバー系を担当しているけど、設計などは日々勉強中のプログラマの覚書

AWSから、テーブル多いからinnodb_file_per_tableを0にしろと怒られた

AWS様からAlertメールが来た。

内容は以下の感じ。

DB Instance dev-DB-XXXX has a large number of tables and has the

parameter innodb_file_per_table set to 1, which can increase database recovery

time significantly. Consider setting this parameter to 0 in the parameter group

associated with this DB instance to minimize database downtime during reboots

and failovers.

 なんとか頑張って読むと、どうやら、

DBにテーブルありすぎて、もしクラッシュ&リカバリーって自体になったときには、

スゲー時間がかかるぞ。いいのか!?という警告メッセージのようでした。

 

で、もう、AWS様が言うならということで、

innodb_file_per_tableを0に設定(my.conf)しましました。

 

で、innodb_file_per_tableって何なのさ。ってところですが、

innodb_file_per_table 

テーブル毎にバイナリファイルを作ってくれる

というオプションらしいです。

そちらの方が、ディスクI/Oが減るんで良いみたいってことで、

Amazon RDSではデフォルトで、指定されているようです。

※mySQL5.6ではデフォルトでONとのこと

 

ただ、今回怒られたように、テーブルが多いと

リカバリの際に、多数のファイルがあるとその分、

リカバリが遅くなるよってことのようです。

 

で、0にすると、ファイル分割しなくなっちゃうので、

何かする度に全部ロックされちゃったりと、それはまたやっかいなことになりそう。

まぁ、途中でやると、それ以降のテーブル作成が同じバイナリで構成されるようです。

 

以下のサイトで、検証もしてくれております。判りやすいー

 

【AWS】RDS for MySQLで共有テーブルスペースに構成変更する際の所要時間を実測してみた

http://dev.classmethod.jp/server-side/db/rds-mysql-innodb_file_per_table/