Elasticsearch --- データ同期、クラスター

1. データの同期

elasticsearch のホテル データは mysql データベースから取得されるため、mysql データが変更されると、それに応じて elasticsearch も変更される必要があります。これがelasticsearch と mysql の間のデータ同期です。

 

アイデア分析:

一般的なデータ同期スキームは 3 つあります。

• 同期呼び出し

• 非同期通知

• ビンログを監視する

 

1.1. 同期呼び出し

解決策 1: 同期呼び出し

基本的な手順は次のとおりです。

• Hotel-demo は、elasticsearch のデータを変更するためのインターフェイスを提供します

• ホテル管理サービスはデータベース操作を完了した後、hotel-demo によって提供されるインターフェイスを直接呼び出します。

 

1.2. 非同期通知

解決策 2: 非同期通知

プロセスは次のとおりです。

• ホテル管理者は、mysql データベース データを追加、削除、変更した後に MQ メッセージを送信します

• Hotel-demo は MQ をリッスンし、メッセージの受信後に elasticsearch データの変更を完了します

 

1.3、バイナリログを監視する

解決策 3: バイナリログを監視する

プロセスは次のとおりです。

• mysqlのbinlog機能を有効にする

• mysqlの追加、削除、変更操作はbinlogに記録されます。

• Hotel-demo は運河に基づいてビンログの変更を監視し、elasticsearch のコンテンツをリアルタイムで更新します

 

1.4. 選択

方法 1: 同期呼び出し

• 利点: 実装が簡単、大雑把

• 短所: 高度なビジネス結合

方法 2: 非同期通知

• 利点: 低結合、一般に実装が困難

• 短所: mq の信頼性に依存する

方法 3: バイナリログを監視する

• 利点: サービス間の完全な分離

• 欠点: binlog を有効にすると、データベースの負担が増加し、実装が複雑になります

  

 

2. クラスター

データ ストレージ用のスタンドアロンの elasticsearch は、大規模なデータ ストレージと単一障害点という 2 つの問題に必然的に直面します。

• 大規模なデータ ストレージの問題: インデックス ライブラリを N 個のシャード (シャード) に論理的に分割し、複数のノードに保存する

• 単一障害点の問題: 断片化したデータを別のノード (レプリカ) にバックアップする

ES クラスター関連の概念:

• クラスター (cluster): 共通のクラスター名を持つノードのグループ。

• ノード (node) : クラスター内の Elasticarch インスタンス

• シャード: インデックスは、シャードと呼ばれるさまざまな部分に分割して保存できます。クラスター環境では、インデックスの異なるシャードを異なるノードに分割できます。

  データ量が多すぎて、単一ポイントのストレージ容量が制限されているという問題を解決します。

ここでは、データを shard0、shard1、shard2 の 3 つの部分に分割します。

• プライマリ シャード (プライマリ シャード): レプリカ シャードの定義に関連します。

• レプリカ シャード (レプリカ シャード) 各プライマリ シャードは 1 つ以上のコピーを持つことができ、データはプライマリ シャードと同じです

 

データのバックアップにより高可用性を確保できますが、各シャードをバックアップすると必要なノードの数が 2 倍になり、コストが高くなりすぎます。

高可用性とコストの間のバランスを見つけるために、次のようにすることができます。

• まずデータをシャーディングして別のノードに保存します

• 次に、各シャードをバックアップし、他のノードに配置して相互バックアップを完了します。

これにより、必要なサービス ノードの数を大幅に減らすことができます。図に示すように、例として 3 つのシャードと各シャードをバックアップ コピーとして使用します。

現在、各シャードには 1 つのバックアップがあり、3 つのノードに保存されています。

• node0: シャード 0 と 1 を保持します

• ノード1: シャード0および2を保持します

• ノード2: 保存されたシャード1および2

 

2.1. クラスターのスプリットブレイン問題

2.1.1. クラスターの責任の分割

elasticsearch のクラスター ノードにはさまざまな役割があります。

デフォルトでは、クラスター内のどのノードも上記の 4 つの役割を同時に持ちます。

 

ただし、実際のクラスターではクラスターの責任を分離する必要があります。

• マスターノード: CPU 要件は高いが、メモリ要件も高い

• データ ノード: CPU とメモリに対する高い要件

• 調整ノード: ネットワーク帯域幅と CPU に対する高い要件

職務を分離することで、さまざまなノードのニーズに応じて、展開用にさまざまなハードウェアを割り当てることができます。また、サービス間の相互干渉を回避します。

典型的な es クラスターの責任区分を次の図に示します。

 

2.1.2. スプリットブレイン問題

スプリット ブレインは、クラスター内のノードの切断によって発生します。

たとえば、クラスターでは、マスター ノードが他のノードとの接続を失います。

この時点で、ノード 2 とノード 3 はノード 1 がダウンしていると考え、マスターを再選出します。ノード 3 が 選出されると、クラスターは引き続き外部にサービスを提供し、ノード 2 とノード 3 がクラスターを形成し、ノード 1 がクラスターを形成します。 2 つのクラスターのデータは同期されていないため、データに差異が生じます。

ネットワークが復元されると、クラスター内に 2 つのマスター ノードがあるため、クラスターのステータスが矛盾し、スプリット ブレイン状況が発生します。

 スプリット ブレインの解決策は、マスターとして選出されるために (適格なノードの数 + 1)/2 を超える投票を要求することです。そのため、適格なノードの数は奇数であることが望ましいです。対応する設定項目はdiscovery.zen.minimum_master_nodesで、es7.0以降はデフォルト設定となっているため、通常はスプリットブレインの問題は発生しません。

たとえば、3 つのノードで形成されたクラスターの場合、投票は (3 + 1) / 2、つまり 2 票を超える必要があります。ノード 3 はノード 2 とノード 3 の投票を取得し、マスターとして選出されます。ノード 1 はそれ自体に 1 票しかないため、選出されませんでした。クラスター内にはまだマスター ノードが 1 つだけあり、スプリット ブレインはありません。

 

まとめ

マスター適格ノードの役割は何ですか?

• グループ選挙に参加する

• マスター ノードは、クラスターの状態を管理し、シャーディング情報を管理し、インデックス ライブラリを作成および削除するリクエストを処理できます。

データノードの役割は何ですか?

• データのCRUD

コーディネーターノードの役割は何ですか?

• リクエストを他のノードにルーティングする

• クエリ結果を結合してユーザーに返します。

 

2.2. クラスター分散ストレージ

新しいドキュメントが追加されると、データのバランスを確保するために異なるシャードに保存する必要があります。では、調整ノードはデータをどのシャードに保存するかをどのように決定するのでしょうか?

原理：

Elasticsearch はハッシュ アルゴリズムを使用して、ドキュメントをどのシャードに保存するかを計算します。

例証します:

• _routing のデフォルトはドキュメントの ID です

• アルゴリズムはシャードの数に関連しているため、インデックス ライブラリが作成されると、シャードの数は変更できません。

新しいドキュメントを追加するプロセスは次のとおりです。

 解釈：

1. id=1 のドキュメントを追加します

2. ID に対してハッシュ操作を実行します。結果が 2 の場合は、shard-2 に保存する必要があります。

3. シャード 2 のプライマリ シャードはノード 3 上にあり、データをノード 3 にルーティングします。

4. 文書を保存する

5. ノード 2 ノード上のシャード 2 のレプリカ 2 に同期します。

6. 結果を調整ノードに返す

 

2.3. クラスター分散クエリ

elasticsearch クエリは 2 つの段階に分かれています。

• 分散フェーズ: 分散フェーズでは、調整ノードがリクエストを各シャードに分散します。

• 収集フェーズ: 収集フェーズ。調整ノードはデータ ノードの検索結果を要約し、それを最終結果セットとして処理してユーザーに返します。

  

2.4. クラスターのフェイルオーバー

クラスタのマスターノードはクラスタ内のノードの状態を監視し、ノードのダウンが検出された場合、データのセキュリティを確保するためにダウンしたノードの断片化されたデータを直ちに他のノードに移行します。これをフェイルオーバーと呼びます。

1) たとえば、図に示すようなクラスター構造:

ここで、node1 がマスター ノードになり、他の 2 つのノードがスレーブ ノードになります。

 

2) 突然、ノード 1 に障害が発生します。

 ダウンタイム後に最初に行うことは、マスターを再選択することです。たとえば、node2 が選択されます。

ノード 2 がマスター ノードになった後、クラスター監視ステータスをチェックし、shard-1 と shard-0 にレプリカ ノードがないことがわかります。したがって、ノード 1 のデータをノード 2 とノード 3 に移行する必要があります。