Documentation Home
MySQL 8.0 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 36.1Mb
PDF (A4) - 36.2Mb


このページは機械翻訳したものです。

15.20.6.4 InnoDB memcached プラグインのトランザクション動作の制御

従来の memcached とは異なり、daemon_memcached プラグインを使用すると、add, set, incr のコールによって生成されるデータ値の永続性などを制御できます。 デフォルトでは、memcached インタフェースを介して書き込まれたデータはディスクに格納され、get のコールはディスクから最新の値を返します。 デフォルトの動作では最適な RAW パフォーマンスは提供されませんが、InnoDB テーブルの SQL インタフェースと比べて高速です。

daemon_memcached プラグインの使用経験があるため、重要でないデータクラスの永続性設定を緩和することを検討できます。ただし、停止時に一部の更新された値が失われたり、若干古いデータが返されるリスクがあります。

コミットの頻度

永続性と本来のパフォーマンスを両立させる 1 つの条件は、新しいデータや変更されたデータがコミットされる頻度です。 データが重要な場合は、予期しない終了または停止が発生した場合に安全になるように、すぐにコミットする必要があります。 予期しない終了後にリセットされるカウンタや失われる可能性のあるロギングデータなど、データのクリティカル性が低い場合は、コミットの頻度を低くして使用可能な RAW スループットを高くすることをお薦めします。

memcached 操作によって基礎となる InnoDB テーブルのデータが挿入、更新または削除される場合、変更は InnoDB テーブルに即座に (daemon_memcached_w_batch_size=1 の場合) または後で (daemon_memcached_w_batch_size 値が 1 より大きい場合) コミットされる可能性があります。 いずれの場合も、変更はロールバックできません。 ビジー時間中に高い I/O オーバーヘッドを回避するために daemon_memcached_w_batch_size の値を増やすと、ワークロードが減少したときにコミットの頻度が低下する可能性があります。 安全策として、バックグラウンドスレッドで、memcached API 経由で行なった変更を一定の間隔で自動的にコミットします。 間隔は、5 秒のデフォルト設定を持つ innodb_api_bk_commit_interval 構成オプションによって制御されます。

memcached 操作によって基礎となる InnoDB テーブルのデータが挿入または更新されると、MySQL 側でまだコミットされていない場合でも、新しい値はメモリーキャッシュに残されるため、変更されたデータは他の memcached リクエストにすぐに表示されます。

トランザクションの分離

getincr などの memcached 操作によって基礎となる InnoDB テーブルに対するクエリーまたは DML 操作が発生した場合、操作でテーブルに書き込まれた最新のデータ、コミットされたデータのみ、またはトランザクション isolation level のその他のバリエーションを表示するかどうかを制御できます。 この機能を制御するには、innodb_api_trx_level 構成オプションを使用します。 このオプションに指定された数値は、REPEATABLE READ などの分離レベルに対応します。 その他の設定の詳細は、innodb_api_trx_level オプションの説明を参照してください。

厳密な分離レベルでは、取得したデータが突然ロールバックまたは変更されず、後続のクエリーで異なる値が返されることはありません。 ただし、厳密な分離レベルでは、待機を引き起こす可能性のある locking オーバーヘッドの増加が必要になります。 長時間実行トランザクションを使用しない NoSQL 形式のアプリケーションの場合は、通常、デフォルトの分離レベルを使用するか、より厳しくない分離レベルに切り替えることができます。

memcached DML 操作の行ロックの無効化

innodb_api_disable_rowlock オプションを使用すると、daemon_memcached プラグインを介した memcached リクエストによって DML 操作が発生した場合に行ロックを無効にできます。 デフォルトでは、innodb_api_disable_rowlockOFF に設定されており、これは memcachedget および set 操作の行ロックを要求することを意味します。 innodb_api_disable_rowlockON に設定すると、memcached は行ロックの代わりに、テーブルロックをリクエストします。

innodb_api_disable_rowlock オプションは動的ではありません。 起動時に mysqld コマンドラインで指定するか、MySQL 構成ファイルに入力する必要があります。

DDL の許可または禁止

デフォルトでは、daemon_memcached プラグインで使用されるテーブルに対して ALTER TABLE などの DDL 操作を実行できます。 これらのテーブルが高スループットアプリケーションに使用される場合の潜在的な速度低下を回避するには、起動時に innodb_api_enable_mdl を有効にして、これらのテーブルに対する DDL 操作を無効にします。 このオプションは、memcached と SQL の両方を介して同じテーブルにアクセスする場合にはあまり適切ではありません。これは、テーブルに対する CREATE INDEX ステートメントがブロックされるためです。これは、レポートクエリーの実行に重要な場合があるためです。

ディスク、メモリーまたはその両方へのデータの格納

innodb_memcache.cache_policies テーブルでは、memcached インタフェースを介してディスクに書き込まれたデータを格納するか (innodb_only、デフォルト)、従来の memcached (cache_only) と同様にメモリー内のみに格納するか、またはその両方 (caching) を指定します。

caching 設定では、memcached がメモリー内からキーを検出できない場合、InnoDB テーブル内から値を検索します。 InnoDB テーブルのディスクで値が更新されたが、まだメモリーキャッシュから期限切れになっていない場合、caching 設定で get コールから返される値は期限切れになる可能性があります。

キャッシュポリシーは、getset (incr および decr を含む)、delete、および flush 操作で個々に設定できます。

たとえば、get および set 操作で、テーブルを、および同時に (caching 設定を使用して)memcached メモリーキャッシュをクエリーまたは更新でき、一方、deleteflush、またはその両方が (cache_only 設定を使用して) メモリー内コピーでのみ動作するようにします。 このようにして、アイテムを削除またはフラッシュすると、そのアイテムはキャッシュからのみ期限切れになり、アイテムが次回リクエストされたときに InnoDB テーブルから最新の値が返されます。

mysql> SELECT * FROM innodb_memcache.cache_policies;
+--------------+-------------+-------------+---------------+--------------+
| policy_name  | get_policy  | set_policy  | delete_policy | flush_policy |
+--------------+-------------+-------------+---------------+--------------+
| cache_policy | innodb_only | innodb_only | innodb_only   | innodb_only  |
+--------------+-------------+-------------+---------------+--------------+

mysql> UPDATE innodb_memcache.cache_policies SET set_policy = 'caching'
       WHERE policy_name = 'cache_policy';

innodb_memcache.cache_policies の値は、起動時にのみ読み取られます。 このテーブルの値を変更したら、daemon_memcached プラグインをアンインストールして再インストールし、変更が有効になるようにします。

mysql> UNINSTALL PLUGIN daemon_memcached;

mysql> INSTALL PLUGIN daemon_memcached soname "libmemcached.so";