コンセプト
MyISAM や InnoDB と同様に、BlackHole は別の MySQL エンジンです。文字通りの意味では、
ブラック ホールのように動作します。入るだけで出られない、入ったら消えてしまう。言い換えれば、そこに書き込まれたデータはすべて失われます。Linux の /dev/null と似ています。
たとえば、テーブル テストのエンジンは BlackHole であり、このテーブルへの挿入はすべて失われます。
その選択は失われます。常に空のセットを返します。対応するデータ ディレクトリには test.frm ファイルが 1 つだけあり、他のファイルはそれに関連付けられていません。
使用シナリオ
データを保存しないエンジンには何の意味があるのでしょうか?
重要なのは、データは保存されませんが、データベース上の操作は binlog ログに記録されるということです。
これには利点があり、マスター/スレーブ レプリケーションの仲介として使用でき、メイン データベースからの元の同期操作を仲介として BlackHole エンジン データベースから変更できます。
1. メイン ライブラリの負担を疑似マスター ライブラリとして共有する
ご存知のとおり、多数のスレーブ ライブラリがある場合、すべてのスレーブ ライブラリはメイン ライブラリからデータをロードします。メインライブラリの負担が増加します。しかし、BlackHole の疑似メイン ライブラリから同期すると、メイン ライブラリの負担を軽減できます。元のマスター/スレーブ アーキテクチャはおそらく次のようになります:
现在，BlackHole伪主库作为中介，变成这样：
特に、replicate-do とplica-do は構成できます。擬似マスター ライブラリ内 レプリケート無視ルールは、同期する必要のないテーブルをフィルターします。
2. binlog ログ コレクターとして
#実際のデータは保存せず、binlog の特徴のみを記録するため、データベース分析を容易にするための binlog ログ収集にエンジンを使用できます。
関連知識: binlog ログには、行、ステートメント、混合の 3 つの形式があります。
row は、各行の変更されたレコードを記録します。つまり、update は、条件を満たすすべての変更された行を記録します。Alter table はさらに悪く、テーブル全体を再構築してすべてを記録するのと同じです。行を変更します。したがって、この形式のログは大きくなりやすいため、
statement メソッドではデータを変更する SQL のみが記録されます。row メソッドでは問題ありませんが、コンテキストが記録されます。欠点としては、SQL実行時のコンテキスト情報を相手側で再現する際に、情報が複雑になるためエラーが発生しやすいという点です。
mixed は、行メソッドとステートメント メソッドを組み合わせます。
構成
疑似ライブラリでは、次の構成が必要です:
デフォルトの構成タイプはBlackHoleです。
default_table_type = BLACKHOLE
または##を使用できます。 #default-storage -engine = BLACKHOLE
binlog を開きます: log-bin = ms-mysql-bin
特別に構成します: log-slave-update = 1。この方法のみで、メイン ライブラリの操作は次のようになります。それ以外の場合は、BlackHole を直接ターゲットとする操作のみが binlog に記録されます。
Ignore InnoDB: Skip-innodb. テーブル作成ステートメントに Engine=innodb が含まれる場合、デフォルトの BlackHole エンジンが使用されます。
このアーキテクチャを採用すると、データ同期用の中間層が追加されるため、遅延の問題をさらに考慮する必要があることに注意してください。