「養成習慣,先贊後看!!!!」
1.前言UP之前都是在自己的「阿里雲伺服器和騰訊雲伺服器」上測試的ES,之前的關於ES以及Kibana的操作都是可以正常的執行的,但是這次在「配置ES集群」的時候問題卻是一直有問題.「雖然兩者的ES都能夠正常啟動,但是雙方節點都顯示找不到對方節點,一直處於ping對方節點的狀態」.並且由於雙方節點都處於這種狀態,導致兩臺伺服器的Kibana都無法正常連接到相應的ES,導致後續的操作都無法正常執行.
在這裡插入圖片描述在請教了我們技術主管之後,說是具體原因可能是由於不在同一個區域網裡面的原因,或者因為是在廣域網的原因,建議先嘗試在「本機的VMware上開兩個虛擬機先測試一下」,看看在本機內是否能夠正常啟動,如果正常啟動的話,後面再分析是不是因為阿里雲與騰訊雲之間通訊障礙的原因.
於是我今天就先嘗試在本機上測試一下,看看是不是我之前配置的問題,在本機測試之後發現,本機上面ES的集群是能夠正常配置以及啟動的:
所以原因基本可以鎖定在了就是「阿里雲伺服器和騰訊雲伺服器之間通訊的問題」,這個之後再說.
其次講一下本片文章主要有下面幾個內容:
ES集群工作的主要原理是什麼,這裡我會拿ES集群和Mysql集群對比,這樣能夠更好的理解ES集群為什麼這麼做2.集群的基本概念了解完ES集群如何配置之後,我們就需要順便了解一下集群中的一些概念,這些概念其實之前就已經提到了,但是我們都沒有深入的講解,今天我們剛好再細緻的講解一下.
集群就是由兩個及以上節點構成的一個節點群,在集群中只會有一個主節點,其他的節點都是聽從主節點的安排,並且所有的節點一起來存儲ES的數據,並且這些數據都是分散的存儲在這些節點之中.節點就是安裝了ES的虛擬機,每個節點都能夠存儲數據.節點分為主節點以及從節點,主節點控制所有的從節點,並且索引這個概念我們之前就已經講過了,在ES中的索引就相當於資料庫的概念.但是呢這個又不完全一樣.因為在ES中的「索引只是一個單純的邏輯存儲單位」,並不是真正的物理存儲單位,「真正的物理存儲單位就是我們下面要說的一個概念即分片」.分片這個概念我們之前就已經講過了,我們所有的數據都是存儲在分片裡面的,,這裡我們就需要和上面的索引聯合起來講一下了.一般的我們是先創建索引也就是我們的 「index」,創建完索引之後,我們就會往索引裡面添加數據,這時候這些數據就是存儲在分片裡面的,並且添加的數據可能是存儲在多個分片裡面.這就使得索引和分片的關係入下圖所示:最後我們需要了解一下副本的概念.其實大家看到就知道是什麼意思.在ES集群裡面,他是 「默認會給每個分片在除該分片所在的節點以外的其它的節點上面創建該分片的一個副本.但是並不是所有其它的節點都會創建副本,ES集群默認的是在其它的3個節點上創建副本.」 這樣做既能保證「數據的容錯性」,又能夠有效的「降低數據的存儲壓力」,如果其它節點都創建該分片的副本的話,雖然容錯性更夠進一步的提高,但是每個節點的存儲的數據就會大幅度增加.3.如何搭建ES集群如何不會VMware安裝虛擬機的小夥伴,可以看我的這片博客: VMware中如何安裝虛擬機 並且軟體以及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稍微了解了這些之後,我們再來詳細講解一下他們的概念.
這個主要就是定義我們ES集群的名字,並且這個名稱必須要統一,否則無法當成是同一個集群
這個就是節點的名稱,每個節點的名稱必須不一樣,否則無法分辨各個節點
定義該節點是否可以成為主節點,一般每個節點都添加這段代碼,因為我們這裡定義之後,「該節點不一定就是主節點」,主節點是在啟動之後集群自己從所有的主節點組裡面挑選一個最為適合的節點為主節點.
定義該節點是否需要存儲數據,這個要看具體的情況,一般公司就是直接「ES和存儲伺服器是同一臺,那麼就需要設置,如果是ES伺服器和存儲伺服器是不在同一臺的,那麼就可以不添加」,具體看自己的需求.
這個大家看名字就能看出來就是定義ES數據的存儲目錄
這個大家看名字也能看出來就是定義ES日誌的存儲目錄
這個定義的就是我們的ES最後是通過哪個IP訪問
這個定義的就是我們的ES最後是通過哪個埠訪問,這個主要指的是我們在瀏覽器中如何訪問ES的埠
這個定義的則是ES集群內部各個節點之間通訊的埠號
discovery.zen.ping.unicast.hosts: ["IP位址"]
這個就類似於我們的通訊錄,主要就是將集群中除當前節點的ip外,填寫其他節點的ip,這樣每個節點才能知道其他節點的信息.
discovery.zen.minimum_master_nodes: 2
在了解這個屬性之前,我們需要先了解一下腦裂這個概念.「從字面意思來理解就是腦子分裂了,從原來的一個腦子分裂成了兩個及以上的腦子.「一般情況下集群是能夠正常工作的,但是大家知道,世界上就是存在很多不正常的情況.如果集群正常工作的話,那麼工作的流程應該是這樣的:但是假設由於網絡或者其他的一些原因導致節點3與節點4與主節點的通信斷掉了,就會變成下面這個樣子:在這種情況下,節點3和節點4就會理所應當的認為是主節點掛掉了,那麼這時候他們就會從他們倆中再選出一個主節點,就會出現下面的情況:這樣集群中就會出現兩個主節點,並且每個主節點還都認為沒有其他主節點.自己和自己的從節點玩.不僅是內部,外部肯定也是不知道的,這就會導致下面這種情況:進行第一次請求的時候被」分發到節點1」,因為此時ES集群內部認為節點1是主節點,所以就在節點1處進行了操作.
當二次請求到達時,ES集群又將「節點3」認為是主節點於是就是節點3處進行了修改操作.
關鍵是如果剛好這時第三次請求到達後剛好ES集群又將「節點1當成是主節點」,那麼這樣就歇逼了,可以看到數據是沒有發生改變的.所以就這就腦裂之後會產生的問題.「客戶端的請求可能是分發到了多個主節點上,但是主節點之間已經失去了通信,那麼這樣重複幾次請求之後就會導致節點之間的數據不統一.」
所以我們就需要解決腦裂這個問題,這裡我們設置的這個屬性就能在極大程度上幫助我們解決這個問題,注意這裡只是極大程度上,並不能完全解決這個問題.
這裡我們設置的屬性意思就是「集群中可以設置為主節點機器的最小數目」,並且這個數目的值是這樣定義的,是 「機器總數的半值+1」.一旦ES檢測到所有的節點數<這個值就說明ES集群已經發生腦裂了,就會停止服務.
這裡和大家舉個例子來說明一下,大家就能理解了.這裡我們還是拿上面的例子來講解:上面的例子就已經很好的講解了這個過程.
講解完上面屬性的概念之後,這時候我們就來實際操作一下,分別給兩臺機器配置一下ES集群的配置.
這裡我選擇的是直接Clone我的另一臺機器,大家可以選擇直接配置兩臺虛擬機,也可以像我這樣值配置一臺虛擬機,另一臺機器直接通過Clone這一臺機器即可.
Clone的過程如下:
在這裡插入圖片描述通過快照來Clone虛擬機
之後我們就只需要分別取配置一下我們兩臺虛擬機中ES的elasticsearch.yml文件即可.192.168.94.128:
192.168.94.129:
這裡面還有一個主意點就是需要 「打開我們剛才創建的數據以及日誌目錄的權限」,否則是不能用的
切換到root用戶執行下面的命令即可:
chmod 777 /opt/es/data #這個目錄需要匹配你自己定義的數據目錄
chmod 777 /opt/es/logs #這個目錄需要匹配你自己定義的日誌目錄之後我們重新啟動我們的ES即可.
兩臺機器的ES都已經成功啟動,但是這不能證明這兩臺機器就真的就已經在一個集群裡面了,這時候我們還需要通過一個管理ES節點的工具Cerebro來檢測,這個東西能幫助我們檢查節點是否真的已經在一個集群裡面了.軟體我也分享出來連結：https://pan.baidu.com/s/1QdQrcD19EfHm6esLWXYzJw提取碼：qilh
下載之後解壓,以管理員身份運行該文件即可.
運行完成之後我們便可以看到這樣一個界面:
之後我們訪問該地址:http://localhost:9000/之後填寫我們的ES地址就可以管理我們的ES集群了:可以看到的確已經構成了集群,並且es-1即為我們的主節點.
4.ES設置開機自啟動因為這裡我這裡並不是在雲伺服器上面搭建的ES集群,所以每次都需要我自己打開虛擬機之後自己手動開啟elasticSearch,試了幾天之後發現,這樣太煩了,還是配置一下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 elasticsearchchkconfig --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的解決方案主要就是採用了複製的概念,但是這有幾個問題,一旦幾臺機器出了問題,那麼很顯然就是直接幾臺機器的數據完全就沒了,導致後續所有數據的並發量全部都打到剩下的機器上.如下圖所示:
「性能」肯定會有所降低.
其次就是可能還有一種情況就是在其它幾臺主資料庫崩潰之前「正在執行多次的查詢,修改的操作」,假設剛好這些操作從資料庫還沒有執行完畢即複製過程還沒有結束,主資料庫就突然崩潰了,那麼很顯然這部分的數據就沒有同步號,那麼很顯然之後的數據就會產生差異,就如下圖所示:
這個主要就是造成了 「數據的不統一」.
既然這樣,我們再來看看ES集群是怎麼做的?
ES集群所採用的的方案則是這樣的 「分片+複製」,
其實分片+複製的概念我們已經在上面分片+副本的集群基本概念裡面講過了.
主要就是ES集群並不像Mysql集群一樣一開始就是將數據存儲在一臺伺服器上的,相反的他是將所有的數據存儲在多個分片上,並且這些分片是分散的存儲在所有的節點上面的.
並且他的複製過程就和我們上面所說的副本的概念是一樣的.他並不像Mysql集群一樣,所有從資料庫都需要與主資料庫進行通信,每臺從資料庫都需要複製主資料庫的數據.ES集群則是這樣,只需要每個分片與他的副本之間進行複製即可.
正是因為上述兩點原因使得 「ES的數據容錯性非常高」 ,注意雖然是非常高,但是仍然還是會出現癱瘓的.
到這裡,本文所有講解的內容就都已經講完了,原創不易,碼字不易!!
如果覺得文章質量可以或者對你有幫助的話,可以關注我的公眾號,新人up需要你的支持!!!!
在這裡插入圖片描述「不點在看,你也好看!」
「點點在看,你更好看!」