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;