初めてこれを入手したときは、以下の説明に問題がある可能性があります。参考までに、公式ドキュメントと以下のリンクを参照してください。
1.スプリットブレインの問題
参照：https：//qbox.io/blog/split-brain-problem-elasticsearch
ノードがクラッシュしたり、ノード間の通信が何らかの理由で中断されたりすると、問題が発生します。スレーブノード
がマスターノードと通信できない場合、スレーブノードはまだ接続されているマスターノードから新しいマスターノードを選択します。次に、新しい
マスターノードが前のマスターノードの責任を引き継ぎます。古いマスターノードがクラスターに再参加するか、通信を再開すると、新しいマスター
ノードはそれをスレーブノードに降格するため、競合は発生しません。ほとんどの場合、このプロセスはシームレスで「効果的」です。
ただし、マスターノードとスレーブノードの2つのノードのみの場合を考えます。2つの間の通信が中断されると、
スレーブはマスターに昇格しますが、通信が復元されると、2つのマスターノードがあります。元のマスターマスターノード
は、スレーブノードがオフラインであり、スレーブノードとして再機能する必要があると考えていますが、新しいマスターノードは、元のマスターノードがオフラインであり、スレーブノードである必要があると考えています。
現時点では、クラスタースプリットブレインシンドロームの問題が発生します。（個人テストでは、2つのノードのスプリットブレインの問題は再現されませんでした。詳細なテストの
理由はない可能性があります。私の側の2つのノードのスレーブノードが電話を切った後、マスターノードは通常変更を実行できます/クエリ操作を行いますが、マスターノードは
後でハングしますスレーブノードはデータノードでもあるため、クエリは可能ですが、変更することはできません
。pythonesプラグインはコードレベルから使用されるため、プラグイン2つのノードによって引き起こされるスプリットブレインの問題を保護する可能性があります。メカニズム、
コードが変更操作を実行すると、常に障害が発生したマスターノードに接続しようとするため、タイムアウト例外が発生し、操作中のデータ同期は正常です）
説明については、別のブログを参照してください。10ノードのクラスターがあり、3ノードがクラスターから切断されているとします。
検出メカニズムにより、これら3ノードが新しいクラスターを形成し、結果として2つのクラスターが同じになる場合があります。名前、これは
スプリットブレインです。discovery.zen.minium_master_nodesを設定する必要があります：6（このノードは多すぎます。
実際のテストはありませんが、説明を見ると理解できます。3つのクォーラムを試すための4つのノードがあります。 、つまり3つのクォーラム）
2ノードのスプリットブレインの問題について議論する公式フォーラムへの投稿があります。スプリットブレインの問題を回避するには、参照して
ください。ref：https：//discuss.elastic.co/t/how-can-a-configure- two-node-in-one-cluster / 171088/11件の
投稿にメンバーesチームがあり、次のように述べています。スプリットブレインと非行を回避するための推奨事項
です。3つのノードすべてがマスター適格ノードである必要があります基本的に3つの構成情報を一覧表示しますノード。
したがって、それは、3個のノード以上で構成することをお勧めします。もちろん、より多くのノード、より良いHAは、実際のビジネスの状況と利用可能に応じて、かもしれ
サーバリソース。
公式のesドキュメントにも2ノードクラスターの説明がありますが、次の点を指摘することが重要
です。障害に対する耐性 がないため、本番環境に2ノードクラスターを展開することはお勧めしません。したがって、お勧めしません。本番
環境で2ノードクラスターに従事する。
2つのノードのフェイルオーバーをテストしていたとき、次の簡単な構成を行った後、
discovery.seed_hosts：["ip1"、 "ip2"]
cluster.initial_master_nodes：["ip1"、 "ip2"]が
見つかりました：
スレーブノードの場合ダウンしている：そこに、一つのマスターノードが残っているESは、スレーブノードが残っていることがわかります（左）と異常な情報がスローされない、とログ
修正操作とクエリ操作上のコード側は依然として正常に完了することができます。
場合マスターノードがハング：スレーブノードの場合は残り、ESは、接続エラーを報告し、常に選挙をトリガーしようとするが、常に選挙（以下ログを参照）中にマスターノードにアクセスしようとするログ
のクエリ操作を上コード側は正常に完了できますが、変更操作は実行できません。コード側から変更操作を実行すると、マスターノードタイムアウト例外への接続が報告されます
（redis-thatでマスタースレーブレプリケーションの効果を実現したい）つまり、マスターノードがハングした後、スレーブノードはマスターノードを自動的にアップグレードしますが、実際にはそれを実現できません。スレーブノードが
マスターノードにpingを実行しようとしたため、接続エラー例外が発生しました）
マスターノードがハングダウンした後、スレーブノードログ：マスターはまだ検出または選出されていません。選出にはID [マスターノードID]のノードが必要です...クォーラムではない[スレーブノード]を検出しました。検出は続行されます[マスターノード]の使用
参照：https：//www.elastic.co/guide/en/elasticsearch/reference/current/high-availability-cluster-small-clusters.html#high-availability-cluster-design-two-nodes
2.es組み込みの自動検出メカニズム：zen
ref：https ：//www.elastic.co/guide/en/elasticsearch/reference/6.8/modules-discovery-zen.html
は、同じcluster.nameを次のように構成するだけで済みます。ノードを接続します同じクラスターに参加します
4ノードクラスター
cluster.name: my-application
node.name: node-1
path.data: /opt/es/elasticsearch-7.6.1/data
path.logs: /opt/es/elasticsearch-7.6.1/log
network.host: ip1
http.port: 9200
discovery.seed_hosts: ["ip1", "ip2", "ip3", "ip4"]
cluster.initial_master_nodes: ["ip1", "ip2", "ip3", "ip4"]
bootstrap.system_call_filter: false
bootstrap.memory_lock: false
http.cors.enabled: true
http.cors.allow-origin: "*"
discovery.zen.minimum_master_nodes: 3
cluster.name: my-application
node.name: node-2
path.data: /opt/es/elasticsearch-7.6.1/data
path.logs: /opt/es/elasticsearch-7.6.1/log
network.host: ip2
http.port: 9200
discovery.seed_hosts: ["ip1", "ip2", "ip3", "ip4"]
cluster.initial_master_nodes: ["ip1", "ip2", "ip3", "ip4"]
bootstrap.system_call_filter: false
bootstrap.memory_lock: false
http.cors.enabled: true
http.cors.allow-origin: "*"
discovery.zen.minimum_master_nodes: 3
cluster.name: my-application
node.name: node-3
path.data: /opt/es/elasticsearch-7.6.1/data
path.logs: /opt/es/elasticsearch-7.6.1/log
network.host: ip3
http.port: 9200
discovery.seed_hosts: ["ip1", "ip2", "ip3", "ip4"]
cluster.initial_master_nodes: ["ip1", "ip2", "ip3", "ip4"]
bootstrap.system_call_filter: false
bootstrap.memory_lock: false
http.cors.enabled: true
http.cors.allow-origin: "*"
discovery.zen.minimum_master_nodes: 3
cluster.name: my-application
node.name: node-4
path.data: /opt/es/elasticsearch-7.6.1/data
path.logs: /opt/es/elasticsearch-7.6.1/log
network.host: ip4
http.port: 9200
discovery.seed_hosts: ["ip1", "ip2", "ip3", "ip4"]
cluster.initial_master_nodes: ["ip1", "ip2", "ip3", "ip4"]
bootstrap.system_call_filter: false
bootstrap.memory_lock: false
http.cors.enabled: true
http.cors.allow-origin: "*"
discovery.zen.minimum_master_nodes: 3
ノードのヘルスステータスを確認します。
アクセス：http：// ip：9200 / _cluster / healthreturns
：
{
"cluster_name": "my-application",
"status": "green",
"timed_out": false,
"number_of_nodes": 4,
"number_of_data_nodes": 4,
"active_primary_shards": 6,
"active_shards": 12,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 0,
"delayed_unassigned_shards": 0,
"number_of_pending_tasks": 0,
"number_of_in_flight_fetch": 0,
"task_max_waiting_in_queue_millis": 0,
"active_shards_percent_as_number": 100
}