vertica集群中一台伺服器故障，導致節點down了。
通過admintools圖形節點的restart vertica on host功能重啟節點服務，一直失敗。
重新stop整個資料庫，然後再start，還是不行，其它節點都正常，那個故障節點還是down。
檢視日誌，提示 data consistency，資料一致性問題，磁碟檔案有損壞？
經過和原廠技術溝通，通過命令列啟動，通過--force引數忽略問題，強行修復。
./admintools -t start_db --database=bigdata --force
這次正常了，故障節點顯示 recovering 狀態，說明在恢復資料，通過以下命令檢視節點狀態：
./admintools -t list_allnones
資料恢復的過程可能較長，通過以下sql可以檢視具體進度：
select * from projection_recoveries where progress>1;
由於故障期間發生過很多delete操作，需要一點點地同步，最終花了3個小時才徹底恢復資料，服務正常。
理論上來說，vertica是集群高可用的，k-safe=1，資料雙副本，掛掉乙個節點，不影響整體使用。
但是這次發現，細節問題比較多，select語句有時正常，有時非常慢，慢10倍都不止，甚至 delete from t1 where t_date=(select max(t_date) from t1) 這樣的語句會無限期死鎖，沒有響應，正常情況下都是1秒完成。
該情況已反饋給vertica原廠。
ETCD節點故障恢復
我在微服務組裡面主要負責配置中心的構建，我們的配置中心使用到了etcd。在我們的內網環境中搭建了三個節點的etcd，不過這三個節點的etcd都搭建在同一臺機器上。後來機器資源不夠了系統直接kill了etcd，導致內網的etcd三個節點全部掛掉了。剛開始想逐個啟動就完事了，但是按照之前的data di...
NameNode故障後的資料恢復
namenode故障後，可以採用如下兩種方法恢復資料。方法一 將secondarynamenode中資料拷貝到namenode儲存資料的目錄 kill 9 namenode程序 刪除namenode儲存的資料 opt module hadoop 2.7.2 data tmp dfs name ch ...
openstack 計算節點重啟後恢復
計算節點斷電意外重啟後，nova compute 服務無法啟動，檢視日誌資訊，報錯如下 20b8b6c4e48a08508349b69dbef0f instance d3a92cf7 9852 47a9 add3 ba18e837a15a ensuring static filters 2013 1...