最初のように習慣を身につけてから見てください!!!
1はじめに
UPは独自のAlibabaCloudサーバーとTencentCloudサーバーでESをテストするために使用されました。ESとKibanaでの以前の操作は正常に実行できますが、今回はESクラスターを構成するときに常に問題が発生しました。..どちらもESですが能够正常启动
、ただし、両側のノードが表示され找不到对方节点
、各ノードにpingを実行した状態になっています。ノードと両側がこの状態であるため、Kibana 2台のサーバーが適切なESに正しく接続されていないため、後続の操作を正常に実行できません。 。
テクニカルディレクターに相談したところ、具体的な理由は不在同一个局域网
内部的な理由か、WAN内にある可能性があるとのことでした。まず、ローカルVMwareで2台の仮想マシンを開いてテストし、それが正しいかどうかを確認することをお勧めします。ローカルマシン上で正常に起動できるかどうか、正常に起動できる場合は、AlibabaCloudとTencentCloud間の通信バリアが原因かどうかを分析します。
そこで、今日このマシンでテストして、以前の構成に問題がないかどうかを確認しました。このマシンでテストした後、このマシンのESクラスターを正常に構成して起動できることがわかりました。
したがって、理由は基本的に、AlibabaCloudサーバーとTencentCloudサーバーの通讯的问题
間でロックできます。これについては後で説明します。
次に、この記事の主な内容について話しましょう。
- RSクラスターのいくつかの基本的な概念について学ぶ
- ESはクラスターを構築する方法と、クラスターを自動的に開始するように設定する方法
- ESクラスター作業の主な原則は何ですか?ここでは、ESクラスターとMysqlクラスターを比較して、ESクラスターがこれを行う理由をよりよく理解できるようにします。
2.クラスターの基本概念
ESクラスターの構成を理解した後、クラスター内のいくつかの概念を理解する必要があります。これらの概念については前に説明しましたが、詳細には説明していません。今日は詳細に説明します。
集群
クラスターは、2つ以上のノードで構成されるノードグループです。クラスター内のマスターノードは1つだけです。他のノードはマスターノードの配置に従い、すべてのノードがESデータを一緒に格納し、これらのデータはすべてItです。これらのノードに保存されます。节点
ノードはESがインストールされた仮想マシンであり、各ノードはデータを格納できます。ノードはマスターノードとスレーブノードに分割されます。マスターノードはすべてのスレーブノードを制御し、索引
インデックスの概念については前に説明しました。ESのインデックスはデータベースの概念と同等ですが、これはまったく同じではありません。ESのインデックス逻辑存储
は単なるユニットであり、実際の物理ストレージユニットではないため、実際の物理存储
ユニットは、以下で説明したい概念です分片
。分片
シャーディングの概念についてはすでに説明しました。すべてのデータはシャードに格納されます。ここでは、上記のインデックスと組み合わせて説明する必要があります。通常、最初にインデックスを作成します。これは、インデックスを作成したindex
後、インデックスにデータを追加します。このとき、データはシャードに保存され、追加されたデータは複数のシャードに保存される場合があります。これにより、インデックスとシャードの関係が作成されます。次の図を示します。
副本
最後に、我々はコピーの概念について知っておく必要があります。実際には、我々はあなたが何を意味することを知っていることがわかります。彼がされたESクラスタのデフォルトは内の各スライスを与える除该分片所在的节点以外的其它的节点
上記のスライスを作成し副本
、しかし并不是所有其它的节点
、コピーを作成します。 ESクラスターのデフォルトこれはにあり其它的3个节点上创建副本
ます。そうすることで、データを容错性
保証できるだけでなく、データを効果的に削減できます存储压力
。他のノードがシャードのコピーを作成すると、フォールトトレランスはさらに向上しますが、各ノードの保存データは大幅に増加します。 。
3.ESクラスターを構築する方法
VMwareに仮想マシンをインストールする方法がわからない場合は、私のブログ「VMwareに仮想マシンをインストールする方法」を読んでください。Baiduネットワークディスクリンクを介してソフトウェアとLinuxシステムを共有しています。
ESクラスターの構築は非常に簡単で、configディレクトリでelasticsearch.ymlファイルを構成するだけです。
主に構成情報は次のとおりです。
#集群的名称
cluster.name: es-cluster
#节点的名称
node.name: es-1
#是否是主节点
node.master: true
#是否是数据节点
node.data: true
#数据存储的目录
path.data: /opt/es/data
#日志存储的目录
path.logs: /opt/es/logs
#本机的ip
network.host: 本机ip
#es对方访问的端口号
http.port: 9200
#es集群内部通信的端口号
transport.tcp.port: 9300
集群中其他机器的IP地址
discovery.zen.ping.unicast.hosts: ["IP地址"]
#避免脑裂,设置集群中能够作为主节点机器的最小个数
discovery.zen.minimum_master_nodes: 2
これらを少し理解した後、それらの概念を詳細に説明しましょう。
-
cluster.name: es-cluster
これは主にESクラスターの名前を定義するためのものであり名称必须要统一
、それ以外の場合は同じクラスターと見なすことはできません。 -
node.name: es-1
これは、各ノードのノードの名前です名称必须不一样
。そうでない場合、各ノードを区別できません。 -
node.master: true
一般每个节点都添加这段代码
ここでノード不一定
を定義した後、ノードはマスターノードになり、マスターノードは起動後にすべてのマスターノードグループから最適なノードを選択するため、ノードがマスターノードになることができるかどうかを定義します。 -
node.data: true
ノードにデータを保存する必要があるかどうかを定義します。これは特定の状況によって異なります同一台
。需要设置
通常不在同一台
不添加
、会社は直接ESとストレージサーバーです。次に、ESサーバーとストレージサーバーの場合は、必要に応じてできます。 -
path.data: /opt/es/data
ESデータのストレージディレクトリを定義していることは、名前から誰でもわかります。 -
path.logs: /opt/es/logs
ESログのストレージディレクトリを定義する名前から誰でも見ることができます -
network.host: 本机ip
この定義は、ESに最終的にアクセスするためのIPです。 -
http.port: 9200
この定義は、ESに最終的にアクセスするためのポートです。これは主に、ブラウザーでESポートにアクセスする方法を指します。 -
transport.tcp.port: 9300
この定義は、ESクラスター内のノード間の通信用のポート番号です。 -
discovery.zen.ping.unicast.hosts: ["IP地址"]
これは私たちのものと似ています通讯录
。主なことは、現在のノードのIPに加えて、クラスター内の他のノードのIPを入力することです。これにより、各ノードは他のノードの情報を知ることができます。 -
discovery.zen.minimum_master_nodes: 2
この性質を理解する前に、まず脑裂
この概念を理解する必要があります。文字通り
理解するには、脳が元の1つの脳から2つ以上の脳に分割されることを意味します。一般に、クラスターは正常に機能しますが、皆さん世界には異常な状況がたくさんあります。クラスターが正常に動作している場合、ワークフローは次のようになります。ただし、ネットワークなどが原因で、ノード3とノード4とマスターノード間の通信が切断されたとします。その他の理由。、次のようになります。この場合、ノード3とノード4は、マスターノードがダウンしていると自然に判断し、この時点でそれらから別のマスターを選択します。ノードでは、次の状況が発生します。このように、クラスター内に2つのマスターノードがあり、各マスターノードは他のマスターノードがないと見なします。私は自分のスレーブノードで遊んでいます。内部だけでなく外部も知らないはずですはい、これは次のような状況になります。最初の要求が行われると、ノード1に配布されます。この時点で、ESクラスターはノード1がマスターノードであると見なし、操作はノード1で実行されるためです。2番目の要求が到着すると、ESクラスターはノード3をマスターノードと見なすため、ノード3が変更されます。
重要なのは、この時点で3番目の要求が到着した直後に、ESクラスターがノード1をマスターノードと見なすと、ノード1が停止し、それを確認できること
数据是没有发生改变
です。したがって、これはスプリットブレインの後に発生する問題です。クライアントの请求可能是分发到了多个主节点
オンですが主节点之间已经失去了通信
、これはリクエストを繰り返した後に発生します节点之间的数据不统一
。したがって、スプリットブレインの問題を解決する必要があります。ここで設定した属性は、この問題を大いに解決するのに役立ちます。これは大部分にすぎず、この問題を完全に解決することはできないことに注意してください。
ここで設定する属性は、クラスター内のマスターノードとして設定できるマシンの
最小
数を意味し、この数の値はこのように定義されます机器总数的半值+1
。はい。ESがすべてのノードの数がこの値未満であることを検出すると、 ESクラスターがスプリットブレインになっていることを意味します。サービスを停止します。これはあなたが説明するための例であり、誰もが理解できます。ここでは、上記の例を取り上げ
て説明します。上記の例では、プロセスがすでに非常によく説明されています。
上記の属性の概念を説明した後、この時点を実際に見て、2台のマシンのESクラスター構成を構成しましょう。
ここでは、他のマシンを直接複製することを選択します.2つの仮想マシンを直接構成するか、私のような1つの仮想マシンを構成して、他のマシンがこのマシンを直接複製するかを選択できます。
クローンのプロセスは次のとおりです。
- 仮想マシンのスナップショットを作成する
-
スナップショットを介して仮想マシンのクローンを作成する
-
クローンマシンのIPを変更してネットワークを再起動します。
私たちはクローンであるため、2台のマシンのIPアドレスは同じであるため、ネットワーク
を
再起動するにはIPADDRパラメータを変更してから変更する必要があります。
次に、2つの仮想マシンでESのelasticsearch.ymlファイルを個別に構成するだけで済みます
192.168.94.128
。
192.168.94.129
:
ここに必要なもう1つのアイデアがあります打开我们刚才创建的数据以及日志目录的权限
。そうでない場合、使用されません。
rootユーザーに切り替えて、次のコマンドを実行します。
chmod 777 /opt/es/data #这个目录需要匹配你自己定义的数据目录
chmod 777 /opt/es/logs #这个目录需要匹配你自己定义的日志目录
その後、ESを再起動できます。
2台のマシンのESは正常に開始されましたが、これは2台のマシンが実際に同じクラスター内にあることを証明するものではありません。現時点ではCerebro
、検出するESノードを管理するツールも使用する必要があります。これは私たちを助けることができます。ノードが本当にクラスター内にあるかどうかを確認します。ソフトウェアも共有します。
リンク:https
://pan.baidu.com/s/1QdQrcD19EfHm6esLWXYzJw抽出コード:qilh
ダウンロード後、解凍し、管理者としてファイルを実行します。
操作が完了すると、次のようなインターフェイスが表示されます。
次に、アドレスhttp:// localhost:9000 /にアクセス
し、ESアドレスを入力してESクラスターを管理します。
クラスターが実際に形成されていることがわかります。es-1がマスターノードです。
4.ESが自動的に起動するように設定
クラウドサーバー上にESクラスターを構築するためにここにいないので、毎回自分で仮想マシンを開いた後、手動でelasticSearchを起動する必要があります。数日間試してみると、これは面倒すぎることがわかりました。起動してください。
分散ファイルシステムについて説明する前に、起動とセルフスタートを設定する手順についてはすでに説明しました。主に次の手順です。
编写开机自启动脚本
/etc/init.dディレクトリの下にelasticSearchのブートスクリプトを追加します
cd /etc/init.d
vi elasticsearch
後でこのスクリプトを貼り付けますが、 注意下面我注释标注的三个地方!!!!!
#chkconfig: 345 63 37
#description: elasticsearch
#processname: elasticsearch-6.3.1
#这里需要填写你自己ES的安装目录,不一样的话记得修改
export ES_HOME=/opt/es/elasticsearch-6.3.1
case $1 in
start)
#这里的用户需要填写你自己的ES启动用户,不是es的话,需要修改
su es<<!
cd $ES_HOME
./bin/elasticsearch -d -p pid
exit
!
echo "elasticsearch is started"
;;
stop)
pid=`cat $ES_HOME/pid`
kill -9 $pid
echo "elasticsearch is stopped"
;;
restart)
pid=`cat $ES_HOME/pid`
kill -9 $pid
echo "elasticsearch is stopped"
sleep 1
#这里的用户需要填写你自己的ES启动用户,不是es的话,需要修改
su es<<!
cd $ES_HOME
./bin/elasticsearch -d -p pid
exit
!
echo "elasticsearch is started"
;;
*)
echo "start|stop|restart"
;;
esac
exit 0
赋予开机脚本权限
保存して終了したら、次のコマンドを入力する必要があります。
chmod 777 elasticsearch
添加到开机服务里面同时开启开机自启
chkconfig --add elasticsearch
chkconfig elasticsearch on
このようにして、ESの起動と自己起動が完了しました。それだけでなく、次のコマンドを使用してesサービスを直接開始、再起動、および閉じることもできます。
#启动es服务
service elasticsearch start
#关闭es服务
service elasticsearch stop
#重启es服务
service elasticsearch restart
5.ESクラスターの動作原理(Mysqlクラスターと比較して)
動作ESクラスターを言う前に、まずMysqlクラスターが動作することを確認します。動作
Mysqlクラスターがメインです。主从复制
つまり、プライマリデータベースが変更され、データベースから変更する必要があり、マスターデータベースがクラッシュしたときにスレーブデータベースが置き換えられます。データベースをマスターし、引き続き責任を負います。
Mysqlのソリューションは主复制
に採用された概念であることがわかりますが、いくつかの問題があります。いくつかのマシンに問題が発生すると、直接マシンのデータが完全に失われ、後続のすべてのデータの同時実行につながることは明らかです。金額は残りのマシンに転送されます。次の図に示すように:
パフォーマンスは確実に低下します。
2つ目は、他のメインデータベースがクラッシュする前に、複数のクエリと変更された操作が実行されている場合があることです。これらの操作がデータベースから完了していない、つまりレプリケーションプロセスが終了していないと仮定すると、メインデータベース突然クラッシュしました。次に、明らかにデータのこの部分に同期番号がない場合、次の図に示すように、後続のデータに違いがあることは明らかです。
これは主に発生し数据的不统一
ます。
この場合、ESクラスターがどのように行われるかを見てみましょう。
ESクラスターで採用されているスキームは次のようになります分片+复制
。
実際分片+复制
、上記分片+副本
のクラスターの基本的な概念についてはすでに説明しました。
ESクラスターは、最初に1つのサーバーにデータを格納するMysqlクラスターとは異なり、すべてのデータを複数のシャードに格納し、これらのシャードはすべてのノードに格納されます。
彼のレプリケーションプロセスは、前述のコピーの概念と同じです。Mysqlクラスターとは異なり、すべてのスレーブデータベースがマスターデータベースと通信する必要があり、各スレーブデータベースがマスターデータベースのデータをレプリケートする必要があります。これはESクラスターの場合であり、各シャードとそのコピーの間でのみ複製する必要があります。
ES的数据容错性非常高
注目度は非常に高いものの、依然として麻痺が続くのは、まさに上記の2つの理由によるものです。
この時点で、この記事で説明されているすべての内容が説明されており、独創性は簡単ではなく、コードワードは簡単ではありません!!
記事の質があなたに役立つ、または役立つと思うなら、私の公開アカウントに注意を払うことができます。新規参入者はあなたのサポートが必要です!!!
あなたがそれを見ないなら、あなたはよく見えます!
見続けてください、あなたはよく見えます!