Vertica 高可用性測試

2021-09-08 23:11:25 字數 1502 閱讀 2951

vertica也是mpp架構的資料庫,相比大家熟悉的mpp架構,比如greenplum和hadoop這些產品,vertica最大的不同就是沒有主節點這個概念。

也就是說vertica集群中(k-safe=1情況),任何乙個節點宕機都不會影響到其他節點對外提供服務。

而在其他有主節點的架構中,一旦主節點掛掉,整個集群就會掛掉,所以還需要考慮進一步冗餘主節點。

對架構有深入了解的朋友會問,沒有主節點,那vertica的元資料存放在**呢?

答案是存放在每乙個節點中,因為元資料並不會很大,所以每個節點冗餘元資料是可行的。

基於上面的理解,我們在乙個3節點的vertica集群測試環境中,任意停掉乙個節點,其他節點都是可以對外提供服務的。

admintools 工具選擇 「7 advanced menu」 ,然後選 「2 stop vertica on host」 或者 「3 kill vertica process on host」, 最後選擇要停止服務的節點。

admintools -> 7  advanced menu -> 2  stop vertica on host / 3  kill vertica process on host -> select host(s)
注:在選擇「2 stop vertica on host」 或者 「3 kill vertica process on host」,優先選擇前者,前者停不掉才考慮後者殺掉。

這裡殺掉第二個節點的vertica程序。

dbadmin=> select node_name, node_state from nodes;

node_name | node_state

-------------------+------------

v_testdb_node0001 | up

v_testdb_node0002 | down

v_testdb_node0003 | up

(3 rows)

第二個節點宕機,但和預計的情況一樣,從第乙個節點和第三個節點的訪問資料,都可以正常訪問到。

--說明節點1訪問正常:

[dbadmin@vertica1 ~]$ vsql

password:

--說明節點3訪問正常:

[dbadmin@vertica3 ~]$ vsql

password:

從節點2訪問,會報錯:

[dbadmin@vertica2 ~]$ vsql

vsql: could not connect to server: 拒絕連線

is the server running on host "???" and accepting

tcp/ip connections on port 5433?

所以,應用端配置連線,建議不要簡單的固定集群某個節點的ip位址,而應該想辦法配置一組ip,實現當發現有ip位址不能訪問,可以連線別的節點ip位址正常訪問資料庫的邏輯。

可用性測試

工作一直緊張,但今天還是岔出了一件事情,就是對我負責的模組進行使用者可用性測試。兩個小時的測試還是有點收穫,小記之。剛剛從公司的培訓課程中學到了 usability test 沒想到這麼快就用到了實踐中,雖然這次的可用性測試不是很正式的從公司外部請使用者來做,也沒有用單面透視玻璃對使用者行為作 暗訪...

可用性測試

1.頁面部分 1.頁面清單是否完整 是否已經將所需的頁面全部都列出來了 2.頁面是否顯示 在不同解析度下頁面是否存在,在不同瀏覽器版本中頁面是否顯示 3.頁面在視窗中的顯示是否正確 美觀 在調整瀏覽器視窗大小時,螢幕重新整理是否顯示 4.頁面特殊效果顯示是否正確 2.頁面元素部分 2.元素是否顯示 ...

Web可用性測試

專案 問題 答案 yes no n a 瀏覽1 對瀏覽者所處網頁有清晰的標記?2 有清楚指向主頁的鏈結?3 各主要部分都可以由主頁進入?4 有 索引,已備需要?5 架構簡單,沒有不必要的分級?6 有易用的搜尋功能,已備需要?功能1 所有功能都有清晰的標籤?2 不需要離開 即可運用各必需的功能?3 沒...