MySQL :: MySQL 5.6 リファレンスマニュアル :: 15.6 BLACKHOLE ストレージエンジン

MySQL 5.6 リファレンスマニュアル / 代替ストレージエンジン / BLACKHOLE ストレージエンジン

15.6 BLACKHOLE ストレージエンジン

BLACKHOLE ストレージエンジンは、データを受け取るけれども破棄して格納しない「ブラックホール」として機能します。検索は、常に空の結果を返します。

mysql> CREATE TABLE test(i INT, c CHAR(10)) ENGINE = BLACKHOLE;
Query OK, 0 rows affected (0.03 sec)

mysql> INSERT INTO test VALUES(1,'record one'),(2,'record two');
Query OK, 2 rows affected (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM test;
Empty set (0.00 sec)

ソースから MySQL を構築する場合に BLACKHOLE ストレージエンジンを有効にするには、CMake を -DWITH_BLACKHOLE_STORAGE_ENGINE オプションで呼び出します。

BLACKHOLE エンジンのソースを調べるには、MySQL ソース配布の sql ディレクトリを検索します。

BLACKHOLE テーブルを作成するときに、サーバーはデータベースディレクトリ上にテーブルフォーマットファイルを作成します。ファイルはテーブル名から始まり .frm 拡張子が付きます。テーブルに関連するファイルはほかにありません。

BLACKHOLE ストレージエンジンはすべての種類のインデックスをサポートしています。すなわち、テーブル定義にインデックス宣言を含めることができます。

BLACKHOLE ストレージエンジンが SHOW ENGINES ステートメントで使用できるかどうかを確認できます。

BLACKHOLE テーブルへの挿入はデータを格納しませんが、ステートメントベースバイナリロギングが有効になっている場合は、SQL ステートメントはログが記録されてスレーブサーバーに複製されます。これは、繰り返しまたはフィルタメカニズムとして役立つ場合があります。

注記

バイナリログに行ベースフォーマットを使用すると、更新と削除はスキップされ、ログも適用されません。このため、バイナリロギングフォーマットには ROW や MIXED ではなく STATEMENT を使用してください。

アプリケーションがスレーブ側フィルタリングルールを要求するけれども、すべてのバイナリログデータを最初にスレーブに転送するとトラフィックが多すぎるとします。そのような場合は、次に示すようにマスターホスト上に、デフォルトストレージエンジンが BLACKHOLE である「dummy」スレーブプロセスをセットアップできます。

マスターはそのバイナリログに書き込みます。「dummy」 mysqld プロセスはスレーブとして機能し、replicate-do-* および replicate-ignore-* ルールの適切な組み合わせを適用し、それ自体のフィルタリングされた新しいバイナリログを書き込みます。セクション17.1.4「レプリケーションおよびバイナリロギングのオプションと変数」を参照してください。フィルタリングされたこのログはスレーブに提供されます。

ダミープロセスは実際にはデータを保存しないため、レプリケーションマスターホスト上で追加 mysqld プロセスを実行することによる処理オーバーヘッドはほとんどありません。この種類のセットアップは、ほかのレプリケーションスレーブで繰り返すことができます。

BLACKHOLE テーブルの INSERT トリガーは期待どおりに機能します。しかし、実際には BLACKHOLE テーブルはデータを格納しないため、UPDATE および DELETE トリガーは有効ではありません。トリガー定義の FOR EACH ROW 句は、行がないために適用されません。

BLACKHOLE ストレージエンジンのその他の利用方法は、次のとおりです。

ダンプファイル構文の検証。
バイナリロギングのオーバーヘッドを測定 (バイナリロギングが有効である場合と有効でない場合のパフォーマンスを BLACKHOLE を利用して比較することで)。
BLACKHOLE は本質的には「no-op」ストレージエンジンであるため、ストレージエンジン自体には関係ないパフォーマンスボトルネックの検出に使用される場合があります。

コミットされたトランザクションはバイナリログに書き込まれ、ロールバックされたトランザクションは書き込まれないという意味で、BLACKHOLE エンジンはトランザクション対応です。

Blackhole エンジンと自動インクリメントカラム

Blackhole エンジンは no-op エンジンです。Blackhole を使用してテーブルで実行される操作は効果がありません。このことは、自動的に増分する主キーカラムの動作を考慮するときに念頭におくようにしてください。このエンジンはフィールド値を自動的に増分せず、自動インクリメントフィールドの状態を保持しません。これは、レプリケーションで重要な意味を持ちます。

次の 3 つの条件がすべて適用される次のレプリケーションシナリオを検討します。

マスターサーバーには、主キーである自動インクリメントフィールドを持つブラックホールテーブルがあります。
スレーブには同じテーブルが存在しますが、MyISAM エンジンを使用します。
INSERT ステートメント自身で自動インクリメント値を明示的に設定せずに、つまり SET INSERT_ID ステートメントを使用して、マスターのテーブルへの挿入が実行されます。

このシナリオでは、レプリケーションは主キーカラムでの重複エントリーエラーで失敗します。

ステートメントベースのレプリケーションでは、コンテキストイベントの INSERT_ID の値は常に同じになります。このため、主キーカラムで重複値を持つ行を挿入しようとすると、レプリケーションは失敗します。

行ベースのレプリケーションでは、エンジンが戻す行の値は、各挿入で常に同じです。このため、スレーブは主キーカラムで同じ値を使用する 2 つの挿入ログエントリーを再生しようとして、レプリケーションは失敗します。

カラムのフィルタリング

行ベースのレプリケーション (binlog_format=ROW) を使用すると、セクション17.4.1.9「テーブル定義が異なるマスターとスレーブでのレプリケーション」セクションで説明されたように、最後のカラムがテーブルから失われたスレーブがサポートされます。

このフィルタリングはスレーブ側で機能します。すなわち、カラムはフィルタリングされる前にスレーブにコピーされます。スレーブにカラムをコピーすることが望ましくないケースが少なくとも 2 つあります。

データが機密の場合、スレーブサーバーはアクセスすべきではありません。
マスターが多くのスレーブを持つ場合、スレーブに送る前にフィルタリングすると、ネットワークトラフィックが削減される可能性があります。

マスターカラムのフィルタリングは、BLACKHOLE エンジンを使用して実現できます。これは、マスターテーブルフィルタリングの実現方法 (BLACKHOLE エンジンと --replicate-do-table または --replicate-ignore-table オプションを使用) に類似した方法で実行されます。

マスターのセットアップは次のとおりです。

CREATE TABLE t1 (public_col_1, ..., public_col_N,
                 secret_col_1, ..., secret_col_M) ENGINE=MyISAM;

信頼されたスレーブのセットアップは次のとおりです。

CREATE TABLE t1 (public_col_1, ..., public_col_N) ENGINE=BLACKHOLE;

信頼されないスレーブのセットアップは次のとおりです。

CREATE TABLE t1 (public_col_1, ..., public_col_N) ENGINE=MyISAM;

PREV HOME UP NEXT