これは、すべてのSQLステートメントがすべてのノードで実行されるが、実際に結果を保存するのは一部のノードだけにする複製環境で役立ちます。これは、ドキュメントに記載されている使用例です： http://dev.mysql.com/doc/refman/5.0/en/blackhole-storage-engine.html
ドキュメントに記載されている他の用途は次のとおりです。
- ダンプファイルの構文の確認。
- バイナリロギングを有効にした場合と有効にしない場合のBLACKHOLEを使用したパフォーマンスを比較することによる、バイナリロギングのオーバーヘッドの測定。
- BLACKHOLEは基本的に「ノーオペレーション」ストレージエンジンであるため、ストレージエンジン自体に関連しないパフォーマンスのボトルネックを見つけるために使用できます。
2台のコンピューターがあり、それぞれがMySQLサーバーを実行しているとします。 1台のコンピューターはプライマリデータベースをホストし、2台目のコンピューターはバックアップとして使用する 複製スレーブ をホストします。
さらに、プライマリサーバーに、バックアップしたくないデータベースまたはテーブルが含まれているとします。おそらく、それらはチャーンの多いキャッシュテーブルであり、コンテンツを失ってもかまいません。したがって、ディスク領域を節約し、CPU、メモリ、ディスクIOの不要な使用を回避するには、 レプリケーションオプション を使用して、バックアップしたくないテーブルに影響するステートメントを無視するようにスレーブを設定します。
ただし、レプリケーションフィルターはスレーブサーバーにのみ適用されるため、マスターサーバーで実行されるallステートメントのバイナリログは、ネットワーク経由で送信されます。ここで無駄になっている帯域幅があります。マスターサーバーは、トランザクションのビンログを送信し、スレーブはそれらを受信すると破棄するだけです。私たちはより良いことをして、不必要な帯域幅の使用を避けることができますか？
はい、できます。そこにBLACKHOLEエンジンが登場します。マスターサーバーが実行されている同じコンピューターで、2番目のダミーmysqldを実行しますこのプロセスはBLACKHOLEデータベースをホストしています。このダミープロセスは、実際のスレーブと同じレプリケーションオプションを使用してマスタープロセスのバイナリログから複製し、独自のバイナリログを生成するように構成します。ダミープロセスのbinlogには、実際のスレーブが必要とするステートメントのみが含まれるようになり、binlogから不要なステートメントを除外する以外の実際の作業は行われていません（BLACKHOLEエンジンを使用しているため）。最後に、元のマスタープロセスのバイナリログからではなく、ダミープロセスのバイナリログから複製するように、真のスレーブを構成します。これで、マスターサーバーとスレーブサーバーをホストしている2台のコンピューター間の不要なネットワークトラフィックがなくなりました。
この設定は、この段落と図によって BLACKHOLE docs から説明および図示されている（より簡潔に）ものです。
アプリケーションでスレーブ側のフィルタリングルールが必要であるものの、すべてのバイナリログデータを最初にスレーブに転送すると、トラフィックが過剰になります。このような場合、デフォルトのストレージエンジンがBLACKHOLEである「ダミー」スレーブプロセスをマスターホストに設定できます。
フィルタリングに加えて、ドキュメントは、ビンログが有効になっているBLACKHOLEサーバーの使用 "がリピーター...メカニズムとして役立つ可能性があることを暗示的に示唆しています"。この使用例はドキュメントでは具体化されていませんが、これが理にかなっているシナリオを想像することは可能です。たとえば、多数のスレーブサーバーがあり、すべてが互いにローカル接続が高速なローカルネットワーク上のコンピューター上にあり、インターネット経由でのみ接続できるリモートスレーブから大量のデータを複製する必要があるとします。それらすべてをマスターボックスから直接レプリケートしたくない場合は、同じデータを数回以上取得し、必要以上に数倍のインターネット帯域幅を使用することになります。しかし、また、既存のスレーブの1つだけをマスターから複製させたくなく、他のスレーブがそのスレーブから複製することを望まないとします。マスターよりも信頼性の高いマシン、またはすべてのCPUまたはメモリを消費してボックスを強制終了する可能性のある他のプロセスを実行していて、スレーブネットワーク全体をダウンさせる中間スレーブでソフトウェアまたはハードウェア障害が発生する危険を冒したくない場合。職業はなんですか？
考えられる1つの妥協案は、スレーブネットワークに追加のボックスを導入して、ストレージとしてではなく信頼性とパフォーマンスのために最適化された仲介者として機能することです。リモートマスターから複製するmysqldプロセス以外は、小さくて信頼性の高いSSDドライブを使用し、他のスレーブがサブスクライブできるバイナリログを生成します。そしてもちろん、この中間スレーブをBLACKHOLEエンジンを使用するように設定して、ストレージスペースを必要としないようにします。
これとドキュメントで詳細に説明されている中間フィルタリングスレーブはどちらもエッジケースです。ほとんどのMySQLユーザーは、これらの戦略のいずれかを使用することから利益を得られる状況に自分自身を見つけることはありません。しかし、少なくとも理論的には、BLACKHOLEエンジンを使用して、ノードを実際にディスクに保存する必要なく、帯域幅節約戦略として複製スレーブのネットワークに中間ノードを作成できます。