ソーシャル、スマートフォン、その先の世界へ - KLab
※こちらのページは技術評論社刊「WEB+DB PRESS Vol.34」に掲載された内容になります。
今回は前回に引き続きストレージエンジンのお話です。
前回はFEDERATEDやARCHIVEなど4.1と5.0で新たに追加されたストレージエンジンの紹介を（ちょっといたずらしつつ）しました。
実はMyISAMやInnoDBといった古くからあるストレージエンジンも地味に改良が加えられています。また、InnoDBの後釜を狙うストレージエンジンもいくつか発表されています。
そこで今回は古参、新参のストレージエンジンについて開拓したいと思います。
まずは古参ストレージエンジンの変更点についてざっと見てみましょう。
影響が大きいInnoDBの耐障害性に関係する機能追加については、ここでは軽く紹介するにとどめ、節を改めてじっくり開拓することにします。
用途によってはまだまだ現役の古参ストレージエンジンMyISAMも、変更がいくつかあります。
MyISAM形式のテーブルは、ひとつのテーブルに作ることができるインデックスの数は64個までという制限があります。
この上限を増やすには、MySQLのソースコードを変更する必要があったのですが、5.1.4からconfigureの--with-max-indexes=Nで変更できるようになりました。
とはいえ、ソースコードを直接編集しなくてよくなっただけで、MySQLを再コンパイルしなければならないのには変わりありません。また、増やせる上限は128までとされています。
5.1.4から、mmap(2)というシステムコールを使ってMyISAMテーブルのデータファイルをメモリ上にマッピングする機能が追加されました。my.cnfでmyisam_use_mmap = 1とするとこの機能が有効になります。
MySQLの世界では、MyISAMテーブルのインデックスはキャッシュされますが、データはキャッシュされませんので、mmapすることによりパフォーマンスの向上が期待できます。
ただし、32ビットCPUの環境では、メモリのアドレッシングの関係でmmapできるデータファイルの大きさは2GBまでという制限があります。
じゃ、myisam_use_mmapを有効にすると2GB以上のデータが扱えないのか？というとそうではなく、2GB以上の場合は、自動的にこれまで通りの方法（pread/pwrite）でアクセスされるので心配は要らないようです。
InnoDBにも変更点がいくつかあります。
内部処理がDELETEと同じだったTRUNCATEが5.0.3で改善され、TRUNCATEが一瞬で完了するようになりました。ただし、当該テーブルに参照整合性制約（FOREIGN KEY）がついている場合はこれまで通りDELETE相当の処理が実行されるため時間がかかります。
4.1.1からinnodb_file_per_tableというパラメータが導入され、データとインデックスをMyISAMのようにテーブル毎に個別のファイルに保存できるようになりました。
4.0までは共用のテーブルスペースの中にテーブルデータを保存するしかなかったのですが、テーブル毎のデータファイルが作れるようになったことにより以下のメリットが生まれます。
innodb_file_per_tableのほかにもいくつかのパラメータが追加されました。表1に4.0.27から5.0.22までの間に追加されたパラメータとその初期値を記します。詳細はInnoDBのパラメータのドキュメント（注1）を参照してください
この中でも以下に挙げるパラメータは、信頼性とパフォーマンスに与える影響が大きいので、後ほどじっくりみっちり開拓したいと思います。
新しいストレージエンジンではないのですが、HEAPが4.1からMEMORYに名前が変わりました。また、4.1からHASHのほかにBTREEインデックスも使用可能になりました。
具体的なストレージエンジンの実装ではないのですが、5.1からPluggable Storage Engineと呼ばれる機構が導入されました。これはMySQL本体をビルドし直すことなく、稼働中のMySQLに動的にストレージエンジンを追加、削除できる仕組みです。
ストレージエンジンが複数選べるというのがMySQLの特徴のひとつであるわけですが、Pluggable Storage Engineによってストレージエンジンの実装と導入が容易になれば、もっとユニークなストレージエンジンが出てくることが期待できますね。
では、もったいぶったInnoDBの大きな変更点について解説します。
ひとことでいうと、クラッシュリカバリ時の信頼性向上をもたらす反面、パフォーマンスの低下を招く可能性があります。具体的なところはこの後、徐々に明らかにしていきます…
まずは関係するいくつかのパラメータについて、指定可能な値を表2にまとめます。
続いて各パラメータについてその効能を説明します。
最近追加されたパラメータではなく以前からあるパラメータですが、ここの内容を語る上で深く関係してくるので解説します。
innodb_flush_methodは、MySQLがInnoDBのデータファイルとログファイルをディスクに書き込む処理に影響します。「InnoDBのログファイル」とは、innodb_log_file_sizeでサイズを指定するファイルのことで、レプリケーションや差分バックアップで使われるバイナリログ（binlog）とは違うという点に注意してください。
通常、MySQLに限らずアプリケーションがファイルにデータを書いた場合、すぐにはディスクに書き込まれず、OSが管理するバッファキャッシュという領域に書き込まれます。バッファキャッシュはメモリ上にあり、ディスクに比べて高速に読み書きすることができるので、ファイルへの読み書き性能の向上が期待できるわけです。
しかしいつまでもメモリ上のバッファキャッシュに蓄えているわけにはいきません。ディスクに比べてメモリの大きさははるかに小さいですし、何より再起動したらメモリの内容は失われてしまいます。
そこでOSは定期的にバッファキャッシュの内容をディスクに実際に書き込んでいます。この行為を「ディスクにフラッシュする」といいます。
OSが定期的に行うほかに、ディスクへのフラッシュは明示的に行うこともできます。以下にいくつかその方法を挙げます。
もし、ディスクにフラッシュしていないデータがバッファキャッシュにある状態で、OSがクラッシュしたらどうなるでしょうか。残念ながらそのデータは失われます。ReiserFS、XFS、ext3といったジャーナリングファイルシステムでも同様です。ジャーナリングはクラッシュ時にファイルシステムに不整合が起こらないようにするためのものですので、そもそもディスクに書かれていない（フラッシュされていない）データに関しては無力なのです。
◇ ◇ ◇
さて、話を元に戻してinnodb_flush_methodです。
innodb_flush_methodがfdatasyncの場合（これが初期値です）、データファイルとログファイルをディスクにフラッシュするのにfsync(2)を使います。
O_DSYNCの場合は、データファイルをフラッシュするのにfsync(2)を使うのは変わらないのですが、ログファイルを同期モード（openするときにO_SYNCを指定する）で開きます。同期モードでファイルを開いた場合、そのファイルに何か書いたらディスクにきっちり書き込まれることになっています。
O_DIRECTの場合は、fdatasyncと同じようにデータファイルとログファイルをfsync(2)でフラッシュするのですが、データファイルを開くときにO_DIRECTを指定します。O_DIRECTはLinux固有のフラグで、OSのバッファキャッシュの効果を最小化する効果があります。O_DIRECTを指定すると一般的に読み書き性能は低下するのですが、アプリケーションが独自にキャッシュのメカニズムを持っている場合に、OSとアプリケーションとで二重にキャッシュするのを避けるために使われます。
3つの設定値の違いを見たわけですが、ここでは
という2点をおさえておいてください。
innodb_flush_methodでディスクにフラッシュする方法を変更できるのはわかりました。では、いつだれがディスクにフラッシュしてくれるのでしょうか？
それを指定するのがinnodb_flush_log_at_trx_commitです。
innodb_flush_log_at_trx_commitは、InnoDBのログバッファ（注3）をInnoDBログファイル（注4）に書き込むタイミングと、InnoDBログファイルをディスクにフラッシュするタイミングとを指定するパラメータです。
指定可能な値は0、1、2のいずれかです。指定値とそれによって変わるフラッシュのタイミングを表3にまとめます。
初期値は1です。表3から、1の場合はCOMMITされたデータは確実にディスクに書き込まれる（フラッシュされる）のがわかると思います。
たとえ「パフォーマンス向上のために」という理由があっても、安易に1以外にしてはいけません。よほど特別な理由がない限り1のままにしておくべきです。
なぜこれほどまでに1以外をすすめないのでしょうか？ それはInnoDBのデータファイルがディスクにフラッシュされるタイミングを知れば納得していただけると思います。
メモリ上にあるInnoDBバッファプールがディスク上のInnoDBデータファイルにフラッシュされます。バッファプールは初期化パラメータinnodb_buffer_pool_sizeで大きさを指定するもので、データファイルはinnodb_data_file_pathで指定する最終的にデータが格納されるディスク上のファイルです。
登場人物が多くなってきたので、ここでInnoDBのログバッファ、ログファイル、バッファプール、データファイルの関係を図1にまとめておきます。
図1：InnoDBのバッファとファイル
さて、バッファプールがデータファイルにフラッシュされるタイミングにはいくつかあります。
どちらもトランザクションがCOMMITされたタイミングとは無関係です。いいかえると、OSがクラッシュすると、データファイルにフラッシュされていないバッファプールの内容は失われてしまうということです。
ここで先ほどのログファイルの登場です。
たとえOSがクラッシュしてバッファプールの内容が失われても、表3で見たようCOMMITされたデータは確実にディスク上のログファイルにはフラッシュされているので、ログファイルを元にクラッシュ時のデータを復元できるわけです。
これでinnodb_flush_log_at_trx_commitを1にする重要性が理解いただけたのではないかと思います。
ちなみに、COMMIT時にデータファイルにフラッシュしていないのはなぜでしょうか？ そうすればログファイルが要らなくなるので内部処理が減るはずですよね？ その理由のひとつは性能向上のためです。一例を挙げます。データファイルに対しデータを書き込む場合、そのデータを書くべき場所を調べる必要があります。一方、ログファイルに書き込む場合は、おおざっぱにいうと末尾にどんどん追記すればよいので書くべき場所を探す手間が要らない分、処理が速く完了するというわけです。
さらにちなむと、これはMySQL固有の機能ではなく、PostgreSQLだとWAL（Write Ahead Logging）（注5）と呼ばれているものと同じです。
ここまでの説明で、OSがクラッシュしたとしてもInnoDBのデータの完全性は保たれる、というのがわかりました。ただしこれ、「MySQLを単体で動かしているだけならば」という条件付きなのです。そのあたりの話はこの後すぐに解説します…
5.0.3から導入されたパラメータで、デフォルトで有効になっています。（注6）
innodb_doublewriteが有効になっていると、データファイルに書き込む処理で2箇所に書くようになります。
最初にdoublewrite領域に書き込み、その後で本来データを格納すべき位置に書き込みます。doublewrite領域には連続的に書き込めるので、本来の位置に書き込む処理より速く書き込み完了することができます。
さて、2箇所に書く理由ですが、本来の位置に書いている途中でOSクラッシュした場合の救済のため、速く書ける領域（doublewrite）にまずは書いておく、ということのようです。
しかし、doublewrite領域に書いている途中にOSクラッシュしたらどうなるの？ とか、そもそもそれってログファイルでリカバリできるんじゃないの？ という疑問がわきます。無効にしてもいいのではないかとも思うのですが、計測した限りではパフォーマンスにはあまり影響がないようなので、デフォルトのまま有効にしておいた方がよいでしょう。
5.0.3からXAトランザクション（注7）がサポートされるようになりました。innodb_support_xaはこのXAの有効、無効を制御するパラメータです。
innodb_support_xaを有効にすると2相コミット（two-phase commit, 2PC）が働くようになります。簡単にいうと、2相コミットとは、COMMIT処理に状態を持たせるものです。
複数のデータベースがある分散トランザクション環境では、あるデータベースはCOMMIT処理が完了できたのに、ほかのデータベースは何かしらの理由でROLLBACKしてしまう可能性があり、このとき、データの一貫性が保たれなくなります。
これを解消するために考えられたのが2相コミットです。
2相コミットではまず、COMMITできる状態であるかを各データベースに尋ねます。これが第1フェーズです。各データベースは自分の状態を返します。全てのデータベースが「準備完了」の場合はCOMMIT実施の指示を出し、ひとつでも準備完了できないデータベースがある場合は、全員にROLLBACKの指示を出します。これが第2フェーズです。
このように2つのフェーズに渡ってCOMMITもしくはROLLBACKの実施を決定することを2相コミットといいます。また、各データベースに状態を尋ねたりCOMMITの指示を出したりする役割をトランザクションマネージャ（TM）といい、データを格納しているデータベースをリソースマネージャ（RM）といいます。そして、TMとRMとの間のAPIをXAといいます。
「分散トランザクションなんてしてないから関係ないや」と思うかもしれませんが、どうもレプリケーションの場合にこのパラメータが関連してくるようなのです。
「ようなのです」というのは歯切れが悪くて申し訳ないのですが、MySQL ABのドキュメント読みあさった限りでは明言されていないようなのです。しかし、次に説明するsync_binlogを1にしていたとしても、innodb_support_xaがOFFだと、レプリケーション構成のマスタの電源をブチっと切ると、マスタとスレーブとでデータの不整合が発生してしまいました。具体的には、マスタではROLLBACKされたのにスレーブではCOMMITされたデータが発生してしまったのです。電源ブチっとなを数十回試した限りでは、innodb_support_xaがONのときにはこの不整合は発生しませんでした。
というわけで、あいまいな情報で申し訳ないのですが、レプリケーションしている場合はinnodb_support_xaをONにした方がよさそうです。（注8）
「データ書き込み」が実行されたタイミングで、バイナリログをディスクに（fdatasync(2)を使って）フラッシュすることができるのですが、sync_binlogは何回「データ書き込み」をするごとにフラッシュするかを指定するパラメータです。
0以上の整数を指定可能で、例えば5とした場合は5回「データ書き込み」が発生するごとにディスクにバイナリログをフラッシュし、1とした場合は毎回「データ書き込み」するごとにディスクにフラッシュします。初期値は0なのですが、0の場合は「データ書き込み」のタイミングではフラッシュしなくなってしまいます。
ここでの「データ書き込み」とは、AUTOCOMMITモードの場合は更新系のクエリが実行されたとき、AUTOCOMMITモードではない場合はトランザクションがCOMMITされたとき、を意味します。
InnoDBログファイルのところでも書きましたが、OSがクラッシュした際にディスクにフラッシュされていないデータは失われてしまいます。データはログファイルとデータファイルに書き込まれているはずなので、バイナリログが失われても困らないと思うかもしれませんが、レプリケーションをしているときやバイナリログを差分バックアップとして利用しているときに困るのです。
バイナリログはマスタのディスクにフラッシュされる前にどんどんスレーブに送られます。マスタがクラッシュして復旧したときに、マスタのバイナリログが欠損していると、スレーブはその欠損している場所からレプリケーションを再開しようとするのでエラーになってしまうわけです。
ただ、経験上、このような事態になった場合は、マスタのバイナリログの欠損した部分は、マスタ上ではデータファイルに書き込まれているはずですし、スレーブではリレーログとして実行済みなので、欠損部分を無視してマスタの新しいバイナリログの先頭からレプリケーションを再開することで不整合を起こさず回復できています。しかしながら、レプリケーションを再開した後で、データに不整合が発生していないかどうかの確認は入念に行うべきでしょう。
sync_binlog = 1とすれば、データに変更がある度にバイナリログはディスクにフラッシュされるのでこのような心配は要らないのですが、変更があるたびにシステムコールfdatasync(2)が発行されることになるので、ものすごくパフォーマンスに影響が出ます。どの程度パフォーマンスが低下するのかは、次の節でまとめます。
まとめると、性能重視のパラメータは、
で、安全重視のパラメータは
となります。
innodb_flush_methodとinnodb_doublewriteはベンチマークの結果からは有意な差は見られなかったので、デフォルトのままでよいと思います。
innodb_flush_log_at_trx_commitは先に解説した通り、どちら重視でも1にするべきでしょう。
性能重視と安全重視の2パターンあるのには理由があります。
図2を見てください。
これはMySQL付属のsql-bench/test-insertを、パラメータを変えて性能重視と安全重視とで実行した結果のグラフです。横軸は性能重視の実時間を1とした場合の安全重視の実時間の比です。ベンチマークの種類によってばらつきはありますが、おおよそ2〜4.5倍程度の性能差が出ています。
多少の差ならば安全重視でいきたいところなのですが、これほど差があると考えてしまいますね。
性能重視の場合でも、単体のクラッシュリカバリは完遂できますし、レプリケーションの不一致もなんとかがんばれば対応することができます。そもそもOSクラッシュはほとんど起こらない事象であると考えるならば、その僅かな可能性のために犠牲になるほかの膨大な時間のパフォーマンス低下をどうとらえるか、という判断基準になると思います。
それは扱うデータの重要性により決定することなので、ここでは性能重視と安全重視の2パターンをそのリスクも含めて紹介した次第です。
図2：性能重視と安全重視のベンチマーク結果
LinuxのReiserFSの場合、どうもfsync(2)が完了してもデータが永続化されないようです。
試しに、write(2)してfsync(2)する、という処理を無限に繰り返すプログラムを実行している状態で電源をブチっと切ってみました。すると、どうやら起動時のReiserFSのリカバリの作用らしく、最後にfsync(2)したときとは程遠い状態に巻き戻されてしまいました。これはfdatasync(2)でも同様でした。ただし、ファイルシステムをsyncオプションつきでmountした場合は巻き戻されることありませんでした。
さて、これで何が困るかというと、sync_binlog=1にしても、OSクラッシュ時にバイナリログが欠損してしまうのです。もしかしたらInnoDBのログファイルやデータファイルも危ないです。
ほかのファイルシステムで同じ試験をしてみたところ、XFSとext3ではReiserFSのようにはならず、fsync(2)やfdatasync(2)が完了した時点のデータは復旧後もちゃんとありました。
筆者が確認したのはLinuxのReiserFS 3.6のみで、4.0では確認していませんが、DBサーバでReiserFSを使うのはちょっと考えた方がよいかもしれませんね。
がらっと話題を変えまして、新参ストレージエンジンを2つ紹介します。
フィンランドのsolid社が開発しているsolidDB（注9）は先日行われたMySQL Users Conference 2006で発表された、新しいストレージエンジンです。
リリースノートを見る限りでは、
といったInnoDBと似た特徴があるようです。
ベータ版は7月に、リリース版は2006年の第4クォータにリリースするとアナウンスされていますが、原稿執筆時点ではまだベータ版はリリースされていません。
しかしプロトタイプレベルの実装は既に公開されていて、実際に試してみることができます。
現状のインストール方法は、MySQL ABが提供しているバイナリ配布物に、solidが提供しているmysqldのバイナリファイルをコピーする方式です。パッチを当てたりする必要がないので、ちょっと試す分にはこの方が便利かもしれませんね。
最初のプロトタイプ版の公開以来、バージョンアップが重ねられているようですし、革新的な「Bonsai Tree」（注10）という名のインデックスが考案されるなど、意欲的に開発され続けているようです。
ふたつめはFalconというストレージエンジンです。これもMySQL Users Conference 2006で発表されました。
開発者はInterBaseの産みの親、Jim Starkey氏です。InterBaseは20年以上も前に誕生したRDBMSで、紆余曲折があったものの今だに現役です。また、OSSのRDBMSであるFirebird（注11）の原型になったことでも有名です。
Jim Starkey氏は自身の会社ごとMySQL ABに買収されたので、FalconはMySQL ABが開発している、ともいえますね。
カンファレンスの資料（注12）によれば、以下のような特徴があるようです。
執筆時点でまだ実装はお披露目されていません。
MySQL ABのページ（注13）によれば、2006年の夏にはベータ版がMySQL 5.1のPluggable Storage Engineにプラグインするかたちでリリースされるようです。
「夏」というのがスウェーデンの夏なのかアメリカの夏なのかはわかりませんが、本誌が店頭に並ぶ頃にはリリースされているかもしれませんね。
今回は古参のストレージエンジンと新参のストレージエンジンの開拓をしました。
古参ではInnoDBの変更点が多く、耐障害性やパフォーマンスへの影響も大きいことがわかりました。パフォーマンスへの影響でいうと、今回は触れませんでしたが、InnoDBのスレッド関連や平行処理関連のパラメータ、
などを調整するとパフォーマンスが向上するという情報もあります。このへんは搭載されているCPUの数にも影響しますので、みなさんの環境で開拓してみるとよいと思います。
新参では2つのストレージエンジンを紹介しました。安心して使えるようになるにはもう少し時間が必要だと思いますが、リリースされるのが楽しみですね。今回紹介したのはどちらもトランザクションをサポートしたストレージエンジンでしたが、MySQL 5.1ではPluggable Storage Engineが使えるようになり、もっとユニークな、例えばトランザクションも外部キーもサポートしていないけどものすごい速いエンジンとか、が出てくるかも知れませんね。
ストレージエンジンのお話はとりあえず今回で終わりで、次回は別なテーマを開拓する予定です。開拓団は今日も精力的に開拓しておりますので、次号もご期待くださいませ！
うち（注A）のDBサーバでは3wareの9500S（注B）と9550SX（注C）をkernel 2.6系のLinuxで使っています。
このカード、1Uサーバに収まる大きさで、128MB〜256MBのwrite cacheとBBU（注D）を搭載でき、とても重宝しています。
そしてこのwrite cache＋BBUがすぐれもので、かなりディスクI/Oの性能が上がります。fsync(2)やfdatasync(2)は本来ならばディスクへの書き込みが完了するまで返らないのですが、どうもwrite cacheに書いたらすぐに返るようでかなり高速です。
DBサーバではメモリの量とディスク性能が重要になります。こういったwrite cacheを備えたRAIDカードを導入すれば、僅か数万円の投資で単体性能をぐっと上げることができますので、忙しいDBサーバをお持ちの方にはお勧めです。ただし、くれぐれもBBUはお忘れなく。製品によってはBBUがないとwrite cacheが有効にならないものもありますので。
