MySQLのブラックホールエンジンの目的は何ですか？

Question

後で取得できないものを保存するのはなぜですか？ポイントは何ですか？

Answer 1

すべてのSQLステートメントがすべてのノードで実行される複製環境で役立ちますが、実際に結果を保存するノードのみが必要です。これは、ドキュメントに記載されているユースケースです。 http://dev.mysql.com/doc/refman/5.0/en/blackhole-storage-engine.html

ドキュメントに記載されている他の用途には次のものがあります。

• ダンプファイル構文の検証。
• バイナリロギングを使用してパフォーマンスを比較することにより、バイナリロギングを使用してバイナリロギングを有効にすることで、バイナリロギングからのオーバーヘッドの測定。
• Blackholeは本質的に「No-op」ストレージエンジンであるため、ストレージエンジン自体に関係のないパフォーマンスボトルネックを見つけるために使用できます。

Answer 2

それぞれがMySQLサーバーを実行している2つのコンピューターがあるとします。 1つのコンピューターがプライマリデータベースをホストし、2番目のコンピューターは 奴隷の複製 バックアップとして使用すること。

さらに、プライマリサーバーにバックアップしたくないデータベースまたはテーブルが含まれているとします。おそらく、それらは高鳥のキャッシュテーブルであり、コンテンツを失うかどうかは関係ありません。したがって、ディスクスペースを保存し、CPU、メモリ、ディスクIOの不必要な使用を避けるために、 複製オプション バックアップしたくないテーブルに影響を与えるステートメントを無視するようにスレーブを構成するには。

ただし、複製フィルターは適用されるためです スレーブサーバー上, 、ビンログの すべて マスターサーバーで実行されたステートメントは、ネットワークを介して送信する必要があります。ここには帯域幅が無駄になっています。マスターサーバーは、スレーブがそれらを受け取ったときに単に捨てられるトランザクションのためにビンログを送信しています。私たちはより良いことをして、不必要な帯域幅の使用を避けることができますか？

はい、私たちはできます、そしてそれはブラックホールエンジンが入ってくるところです。 同じコンピューター マスターサーバーが実行されていること、私たちは2番目のダミーを実行します mysqld プロセス、これはブラックホールデータベースをホストしています。このダミープロセスを構成して、マスタープロセスのビンログから複製し、実際の奴隷と同じ複製オプションを使用し、独自のビンログを作成します。ダミープロセスのビンログには、実際の奴隷が必要とする声明のみが含まれており、ビンログからの不要なステートメントをフィルタリングする以外に実際の作業を行っていません（ブラックホールエンジンを使用しているため）。最後に、元のマスタープロセスのビンログからではなく、ダミープロセスのビンログから複製するように真のスレーブを構成します。現在、マスターサーバーとスレーブサーバーをホストする2つのコンピューター間の不必要なネットワークトラフィックを排除しました。

このセットアップは、この段落と図によって説明され、説明されているものです（はるかに） ブラックホールドキュメント:

アプリケーションにスレーブ側のフィルタリングルールが必要であるが、すべてのバイナリログデータをスレーブに転送すると、最初にトラフィックが多すぎると仮定します。そのような場合、デフォルトのストレージエンジンがブラックホールである「ダミー」スレーブプロセスをマスターホストに設定することができます。

フィルタリングに加えて、ドキュメントはまた、ビンロギングを有効にしてブラックホールサーバーを使用することを不可解に示唆しています 「リピーターとして役立つ可能性があります...メカニズム」. 。このユースケースはドキュメントではあまり肉付けされていませんが、これが理にかなっているシナリオを想像することは可能です。たとえば、奴隷サーバーがたくさんあると仮定します。すべてが、互いに高速なローカル接続を備えたローカルネットワーク上のコンピューターに、すべてがインターネットにしか接続できないリモートスレーブから大量のデータを複製する必要があると仮定します。マスターボックスから直接複製することは望ましくありません。それ以来、同じデータを数倍以上取得し、必要なものよりも数倍のインターネット帯域幅を使用しています。しかし、あなたがそうだと仮定します また 既存の奴隷の1つだけがマスターから複製したいとは思わないで、他の人はその奴隷を複製したいのです。すべてのCPUまたはメモリを食べることで、中間奴隷のソフトウェアやハードウェアの障害を奴隷ネットワーク全体に倒したくないことがあります。職業はなんですか？

考えられる妥協の1つは、奴隷ネットワークに追加のボックスを導入して、ストレージではなく信頼性とパフォーマンスのために最適化された仲介者として機能することです。小さくて信頼性の高いSSDドライブを与え、それを除いて何も実行しません mysqld リモートマスターから複製するプロセスを行い、他の奴隷が購読できるビンログを生産させます。そして、もちろん、ストレージスペースを必要としないように、この中間奴隷をブラックホールエンジンを使用するように設定します。

これと文書で詳細に説明されている中間フィルタリングスレーブの両方がエッジケースです。ほとんどのMySQLユーザーは、これらの戦略のいずれかを使用することで利益を得ることができる状況で自分自身を見つけることはありません。しかし、少なくとも理論的には、ブラックホールエンジンを使用して、ディスク上にデータを実際に保存するためにそのノードを必要とせずに、帯域幅保存戦略として奴隷を複製するネットワークに中間ノードを作成できます。