mysql - MySQL の BLACKHOLE エンジンの目的は何ですか?

Question

後で取り戻せないものを保存するのはなぜですか? ポイントは何ですか？

Answer 1

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

ドキュメントに記載されているその他の用途は次のとおりです。

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

Answer 2

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

さらに、バックアップしたくないデータベースまたはテーブルがプライマリ サーバーに含まれているとします。おそらく、それらはチャーン率の高いキャッシュ テーブルであり、コンテンツを失っても問題ありません。したがって、ディスク容量を節約し、CPU、メモリ、およびディスク IO の不必要な使用を避けるために、レプリケーション オプションを使用して、バックアップしたくないテーブルに影響を与えるステートメントを無視するようにスレーブを構成します。

ただし、レプリケーション フィルターはスレーブ サーバーにのみ適用されるため、マスター サーバーで実行されたすべてのステートメントのバイナリ ログは、ネットワーク経由で送信する必要があります。ここでは帯域幅が浪費されています。マスターサーバーはトランザクションのバイナリログを送信しており、スレーブはそれらを受信すると単に破棄します。不必要な帯域幅の使用を避けるために、もっとうまくやることはできるでしょうか?

はい、できます。そこで BLACKHOLE エンジンの出番です。マスター サーバーが実行されているのと同じコンピューターで、2 番目のダミー サーバーを実行します。mysqldこのプロセスは、BLACKHOLE データベースをホストしています。このダミー プロセスを構成して、マスター プロセスのバイナリ ログから複製し、実際のスレーブと同じレプリケーション オプションを使用して、独自のバイナリ ログを生成します。ダミー プロセスのバイナリ ログには、実際のスレーブが必要とするステートメントのみが含まれるようになり、バイナリ ログから不要なステートメントを除外する以外の実際の作業は行われません (BLACKHOLE エンジンを使用しているため)。最後に、元のマスター プロセスの binlog からではなく、ダミー プロセスの binlog から複製するように真のスレーブを構成します。これで、マスター サーバーとスレーブ サーバーをホストする 2 台のコンピューター間の不要なネットワーク トラフィックを排除しました。

この設定は、BLACKHOLE docs のこの段落と図で説明および図解されているものです:

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

フィルタリングに加えて、ドキュメントはバイナリログを有効にしたBLACKHOLEサーバーを使用すると「リピーターとして役立つ可能性がある...メカニズム」であることを暗号的に示唆しています。この使用例は、ドキュメントではあまり具体化されていませんが、これが理にかなっているシナリオを想像することは可能です。たとえば、多数のスレーブ サーバーがあり、それらすべてが相互に高速なローカル接続を持つローカル ネットワーク上のコンピューター上にあり、インターネット経由でのみ接続できるリモート スレーブから大量のデータを複製する必要があるとします。すべてをマスター ボックスから直接レプリケートする必要はありません。同じデータを何度も取得し、必要な数倍のインターネット帯域幅を使用することになるからです。しかし、あなたもおそらく、スレーブがマスターよりもはるかに信頼性の低いマシンで実行されているか、ボックスを強制終了する可能性のある他のプロセスを実行しているため、既存のスレーブの1つだけをマスターから複製し、他のスレーブをそのスレーブから複製したくないすべての CPU またはメモリを消費することによって、中間スレーブでソフトウェアまたはハードウェアの障害が発生し、スレーブ ネットワーク全体がダウンするリスクを冒したくありません。職業はなんですか？

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

これと、ドキュメントで詳細に説明されている中間フィルタリング スレーブの両方がエッジ ケースです。ほとんどの MySQL ユーザーは、これらの戦略のいずれかを使用することでメリットが得られる状況に自分自身がいることに気付くことは決してないでしょう。しかし、少なくとも理論的には、BLACKHOLE エンジンを使用して、スレーブを複製するネットワークに中間ノードを作成し、そのノードが実際にディスクにデータを保存する必要なく、帯域幅を節約することができます。