在很多的時候，隨著工作的持續開展，可能會接手更多的伺服器資源，這個時候我們手裡就不但是一兩台伺服器那麼簡單，可能幾十個，上百個，甚至上千個，這個時候伺服器資訊的維護就變得額外重要，拋開業務線的規劃，對於dba來說，掌握伺服器的資訊，做到知根知底，才能在問題發生的時候合理處理問題。伺服器資訊可以分成幾個方面來看，比如作業系統情況，核心版本，硬碟，記憶體，空間使用情況，累計執行時間，資料庫例項執行時間，系統中的swap爭用情況等等，盡可能根據實際的情況進行一些維度的劃分和細粒度的歸納。比如說在生產中，考慮容災，會有一主一備，甚至一主多備，這個時候，我們也需要考慮主備環境中的硬體資源的情況，資源使用情況。舉幾個例子。比如我們手頭有兩台伺服器，是作為異地容災的，我們通過簡單的解析得到了兩台伺服器的初步資訊。伺服器一：rhel 6,空間使用近70g,120g記憶體，24cpu,伺服器已啟動590多天，資料庫例項啟動自2023年，伺服器二：rhel 4,空間分配達3.1t,使用率達2.5t,40g記憶體24cpu,伺服器已啟動280多天,資料庫例項啟動自2023年,swap爭用較高
我們來看看這兩台伺服器資訊在特定的場景中會有哪些考慮，當然有些細節還沒有羅列出來。
在這種情況我們怎麼來分析呢，這個時候我們可以看到系統版本，空間資源使用情況都差不多，系統的記憶體相對有些緊張，跑了好幾個資料庫勉強才有8g的記憶體空間，主庫伺服器上有兩個資料庫例項在跑，而備庫中有兩個備庫例項在跑，另外還有一台其他業務的資料庫例項，這種情況下，就可能會有一些災難場景，我們可以了解到主庫伺服器已經執行了近800天，已經兩年多了，而備庫也有差不多1年半了。在這種情況，系統的資源使用情況比較緊俏，很可能就會出現問題。一旦出現問題，就會有問題的放大效應，比如備庫出現了介質損壞，那麼額外的那個資料庫例項就沒有辦法恢復了，因為本地的空間情況剩餘也只有50g左右，如果規劃系統的rman備份，也沒有多少空間可用，而且同時主庫已經跑了2年多了，壓力還是相似甚至開始加大的狀態下，主庫長期在這種資源緊俏的時候更容易出現問題，這個時候主庫出現問題，備庫的隱患還是沒有解除，因為這個時候系統的壓力全部都到了備庫上了。如果備庫壓力突增，更可能出現問題。所以這個時候與時俱進做乙個前瞻的準備還是不錯的，比如我們的主庫資源配置較低，但是我們配備了乙個高配的備庫，這樣就相對可以輕鬆很多，如果出現問題，問題處理的餘地還很大，甚至我們還是希望主庫能夠切換到備庫上來，這樣出現問題之後切換系統的穩定性反而更強了。所以說如果手頭擁有大量的伺服器資源，不妨還是適當規劃一些，看看是否能夠做一些合理的改變，在問題發生的時候更加從容一些，畢竟自動化運維是乙個很大的方向，我們不能保證系統的資源都是完全一樣的，可能很多時候因為各種因素，會有很大的差別，這些系統資源的權衡是自動化運維所不能完全考慮到的，所以我還是希望這是屬於半自動化運維中的範疇。
自動化運維伺服器，ansible操作
分發金鑰，建立免密連線 向遠端伺服器節點拷貝檔案 通過ansible遠端操作mysql yum install ansible y 在沒有公網的內網中，可以 配置檔案修改vi etc ansible hosts 配置檔案格式如下 配置檔案內容 test test 0002 ansible ssh h...
運維自動化
1，cobbler安裝環境準備 安裝epel epel release 6 8.noarch.rpm x86 64 epel release 6 8.noarch.rpm x86 安裝系列依賴環境 要是區域網用，建議關閉iptables 或是放行25151 80 69埠 和關閉selinux 檢視狀...
自動化運維
考慮的因素 源 打包為映象 發布到映象庫 利用k8s發布到物理機器執行，以服務的形式對外提供服務 目前的做法 0 建立乙個執行遠端命令的框架 1 每個應用建立乙個部署檔案指令碼 a 指定元 位址 c 同步源 到目標主機 d 接受指令碼引數 vername 2 版本號，映象tag fromport 3...