MySQL 5.6での機能強化点(その1) - パフォーマンスと使い勝手を大きく向上
InnoDBの運用をより便利に、柔軟に
MySQL 5.6では、InnoDBの運用がより便利になるような機能も複数実装されています。どのような機能が実装されたのか、紹介します。
オンラインDDL
従来は、インデックスの追加/削除を実行する時は、INSERT、UPDATE等の操作はブロックされていました。そのため、サービス提供中にパフォーマンスチューニングできず、メンテナンス時間を確保してインデックスを追加する、といった対応をしているケースもありました。MySQL 5.6では参照・更新処理をブロックせずにインデックスの追加/削除ができるようになっているため、メンテナンス時間を最小限にすることが可能です。
また、列の追加/削除処理もオンラインで実行できます。そのため、サービス稼働後にアプリの修正があり、後からスキーマ定義を変更する必要が出てきた場合でも、サービスを稼働させながらスキーマ定義の変更が可能です。
以下は、オンラインで実行できるDDL操作の一覧です。
MySQLサーバー間で、テーブル単位でのデータ移行が簡単に
「InnoDBでもMyISAMのように、テーブル単位でデータを別のサーバーに移行したい」これは以前から多く頂いていた要望ですが、MySQL 5.6では、InnoDBのデータもテーブル単位で移行できるようになりました。MyISAMの場合と手順は異なりますが、次の手順でInnoDBのデータをテーブル単位で移行できます。
移行元のMySQLサーバー
- FLUSH TABLE FOR EXPORT;
- OS上で、.ibdファイルと.cfgファイルをコピー (1.を実行することにより、.cfgファイルが作成される)
- UNLOCK TABLES;
移行先のMySQLサーバー
- 移行元と同じテーブル定義でテーブルを作成
- ALTER TABLE DISCARD TABLESPACE;
- OS上で、移行元で取得した.ibdファイルと.cfgファイルをコピー
- ALTER TABLE IMPORT TABLESPACE;
もちろん、上記手順は同一サーバー内でテーブル単位でのバックアップ目的でも利用できます。
バッファプールのダンプ&リストア
InnoDBには、一度アクセスしたデータをInnoDB Buffer Poolというメモリ上の領域にキャッシュしておくことで、2回目以降のアクセスを高速化する仕組みがあります。この場合、メモリ上のデータはMySQLサーバーを再起動すると消えてしまうため、再起動直後はパフォーマンスが劣化してしまう、という現象が起きます。
このような現象を防ぐために、MySQLサーバー再起動直後にバッファプール上にデータをキャッシュするための適当なクエリを実行してからアプリケーションを動かしているケースもありますが、MySQL 5.6ではバッファプールの内容をダンプ&リストアできるため、この課題を解決できます。
再起動時に自動的にバッファプールのダンプとリストアを行う場合は、以下のパラメータを設定します。
- innodb_buffer_pool_dump_at_shutdown=ON
※設定可能な値はON、OFF(デフォルト値はOFF)詳細はこちらを参照下さい。
- innodb_buffer_pool_load_at_startup=ON
※設定可能な値はON、OFF(デフォルト値はOFF)詳細はこちらを参照下さい。
また、任意のタイミングでバッファプールのダンプ、リストアを実施することもできます。夜間にバッチ処理が流れて、バッファプール上のデータが入れ替わってしまうような場合など、バッチ処理実行前にバッファプールをダンプし、バッチ処理完了後にリストアする、といった使い方が可能です。任意のタイミングでダンプ、リストアを実施する場合は、以下のコマンドを実行します。
バッファプールのダンプ
SET GLOBAL innodb_buffer_pool_dump_now=ON;
※設定可能な値はON、OFF(デフォルト値はOFF)詳細はこちらを参照下さい。
バッファプールのリストア
SET GLOBAL innodb_buffer_pool_load_now=ON;
※設定可能な値はON、OFF(デフォルト値はOFF)詳細はこちらを参照下さい。
また、ダンプされるデータは実データそのものではなく、テーブルスペースとページの情報のみのため、非常に小さいサイズになります。そのため、この機能を使うためにバッファプールと同程度のディスク空き容量を確保しないといけない、といったこともありません。
デッドロック検出の高速化、デッドロックの情報をエラーログに出力
デッドロックを検出する際のアルゴリズムが変更され、より高速にデッドロックを検出できるようになりました。
また、デッドロック発生時に情報をエラーログに出力することが可能になりました。従来であれば、SHOW ENGINE INNODB STATUSコマンドで直近に発生したデッドロックの情報のみが確認できる状態でしたが、エラーログに記録しておくことにより、デッドロック発生後の調査が楽になります。
デッドロック発生時の情報をエラーログに出力する場合は、以下のパラメータを設定します。
- innodb_print_all_deadlocks=ON;
※設定可能な値はON、OFF(デフォルト値はOFF)詳細はこちらを参照下さい。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- MySQL5.6- さらなる機能追加とNoSQL
- SQL実行計画の疑問解決には「とりあえずEXPLAIN」しよう
- MySQL Clusterにおけるチューニングの基礎
- MySQL 5.6での機能強化点(その2)- NoSQL APIとパフォーマンス・スキーマ
- MySQLのチューニングを戦う方へ
- MySQLのリアルタイムモニタリングに「innotop」
- MySQL 5.6での機能強化点(その3)- 人気のレプリケーションが更に機能強化
- ここが新しい!MySQL 5.1
- データノード設定時のポイント!
- MySQL Database Service(MDS)の分析クエリを高速化する「HeatWave」の使いどころ