伺服器搬遷之後的準備工作和應對

  伺服器搬遷後不是簡單能連線上伺服器就可以了，還有許多的事情需要考慮，否則伺服器不可用還是白搭。

  我大體碰到了如下的一些問題，也能夠反應出來對於系統的各種潛在隱患。

1

  批量檢測伺服器的可用狀態

  如果有大批量的伺服器搬遷，有些能夠連通，有些不可以，使用telnet本身就有硬傷，我們直接設定個超時時間，對於服務是否可用一目瞭然。這個時候還是推薦使用nc命令。比如測試伺服器10.129.128.37的22埠是否可通，超時時間為2秒，則可以使用如下的命令。

nc -z -v -n -w 2 10.129.128.37 22

2

 檢查ILO的連線情況

   如果ILO(iDRAC)都不可用，那麼基本上可以保證你的這個伺服器就不可用了。沒有了終極控制權，即使可以連線，但是一旦伺服器出現異常就完全不可控，這個時候尤其注意的是密碼，要知道密碼。

3

 檢查root密碼的情況

   檢查root密碼的重要性不言而喻，如果能夠訪問到伺服器，但是你壓根登入不了，沒有任何預想準備的使用者，那麼這個也可以給伺服器“判刑”了。修改root密碼本身不是件容易的事情，通過各種設定，如果在關鍵步驟還需要密碼呢。

4

防火牆資訊丟失

這樣的情況碰到了幾次，伺服器重啟之後原本能連線的連不上了，這個時候的解決方法還是ILO的連線到伺服器端，然後手工開啟，或者給自己留點餘地，給主庫或者備庫開啟訪問的許可權，這樣即使中控許可權丟失，也還能保證能夠連線。

5

使用硬IP繫結而非主機域名繫結

有些系統會設定自動啟動監聽，很可能伺服器無法開啟自啟動，其中的一個主要原因就是使用了硬IP繫結，在listener.ora裡面如果使用主機域名解析就會省事很多。

或者對於mysql而言，這個問題就會被放大，比如下面的一個slave伺服器啟動之後，無法連線到主庫應用binlog,經過排查，主要的一個原因就是對於使用者許可權的配置使用了硬IP配置，如果使用域名繫結就會方便多了。

slave的錯誤資訊如下：

 2017-07-26 03:55:34 2490 [ERROR] Slave I/O: error connecting to master 'rep_live800@live800.test.com:3306' - retry-time: 5  retries: 5, Error_code: 1130
2017-07-26 03:55:39 2490 [ERROR] Slave I/O: error connecting to master 'rep_live800@live800.test.com:3306' - retry-time: 5  retries: 6, Error_code: 1130
update mysql.user set host='xxxx' where user='xxx';

這個時候重新整理許可權就能夠正常連線了。

--flush privileges

檢視slave的日誌如下：

2017-07-26 03:55:44 2490 [Note] Slave I/O thread: connected to master 'rep_live800@live800.test.com:3306',replication started in log 'binlog.000019' at position 818554844

6

工具的配置問題

如果使用oracle的DG broker配置，如果本身存在一些配置的問題或者就是DG Broker在早期版本不夠強大，很可能會出現一些問題。

比如下面的DG Broker配置總是失敗，就是的問題，最後重新配置DG Broker就可以了。

Data Guard Broker terminating NSV3, timed out waiting for a response from database s3accdb0
07/26/2017 09:13:18
Data Guard Broker terminating NSV3, timed out waiting for a response from database s3accdb0
07/26/2017 09:13:37

7

資料庫無法啟動

資料庫在啟動時很可能失敗，可能因為殭屍程式，可能因為核心引數配置的問題。比如下面的這個問題。

idle> startup mount
ORA-27102: out of memory
Linux-x86_64 Error: 28: No space left on device
而錯誤的原因就在於記憶體中的殭屍程式依舊存在，還沒有釋放。

$ ps -ef|grep smon
oracle    5374  4967  0 12:58 pts/0    00:00:00 grep smon
oracle   24710     1  0 Jul25 ?        00:00:00 ora_smon_statdb1

手工釋放，重啟就可以了。

8

資料庫檔案丟失

資料庫如果你啟動伺服器之後，突然發現資料全都丟失了，sqlplus,mysql完全不可用，先不要著急，你可以看看是不是分割槽沒有掛載。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-2142619/，如需轉載，請註明出處，否則將追究法律責任。