最近處理的幾個小問題_20160311

最近處理的小問題很多，我就拿出來幾個，簡單和大家說一說。我就分為三個方面，硬體問題，Oracle表空間遷移，MySQL斷電恢復
首先是硬體問題。
如果看到下面的系統日誌，就會發現早在2014年就出現了一些警告和問題，隨後看似已經修復了部分，但是實際情況是這臺伺服器的電源已經壞了一個，另外一個已經快扛不住了。但是通過這些資訊就很難讀到之前的問題，因為問題已經過去了好久，一直沒有問題，應該就是沒有問題吧，或者之前的人已經處理了吧，如果這樣想，是一種樂觀的方式。
最好還是做一些確認，我就是那麼想的，然後在某一天一臺備庫的伺服器就突然殉職了。究其原因就是電源問題。

開啟系統的ILO介面，才突然發現只識別了一個電源，而且已經無法正常開啟電源了。
對於這類問題，還有一個想法就是，機器過就過老，更新換代如此頻繁，還是有好的硬體配置就用上，很多時候都是感覺捨不得，動不得，如果你要遷移某個伺服器，去和各個部門協調，總會有這個不能動，那個不能改的顧慮，但是伺服器可不會講這些情面，有時候**還是有道理的，這些問題也能夠反應出來我們對待問題的態度，都是被動接受，而不是主動改進。出了問題之後發現這些必須得動，必須得改，感覺那個時候就有些匆忙，倉促了。
  然後第二個問題，是一個表空間的遷移問題。
之前幫助開發的同事處理了一個表空間無法擴充套件的小case,然後建議他們後續進行硬碟擴容，從根本上解決這個問題，開發同事還真聽進去了，申請了一塊較大的硬碟，但是還是希望我來幫助他們來遷移這個表空間，這個問題其實很簡單。
可以使用常規的方法即可，唯一的不同在於這個表空間是個bigfile tablespace,所以心裡還是存在一點小小的顧慮，是否對於能夠100%成功。
因為這個表空間的設定，裡面只有一個資料檔案，新的磁碟分割槽在/data下面。
在遷移的時候，開發的同事還是希望能夠線上遷移，從我的大量實踐來說，這些也都不是大的問題，然後使用了下面的指令碼。
alter tablespace CYTJ_DATA offline;
!cp '/home/oracle/tablespace/cytj_data.dbf' '/data/cytj/datafile/cytj_data.dbf';
alter tablespace CYTJ_DATA rename datafile '/home/oracle/tablespace/cytj_data.dbf' to  '/data/cytj/datafile/cytj_data.dbf';
alter tablespace CYTJ_DATA online;
當然拷貝大的檔案，第二步花費了一些時間，其它步驟都是秒級完成。
遷移完了，還是有一些後續的補充工作的。
首先要刪除原有的檔案，再三確認之後，就可以刪除了。
但是使用df -h發現，空間卻壓根沒有釋放，應該能夠釋放50多G才對。
#df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             4.0G  359M  3.4G  10% /
/dev/sda11            106G   96G  5.5G  95% /home
/dev/sdb1             551G   61G  463G  12% /data
對於這個問題，解決方法也比較簡單，就是檢視控制程式碼的使用情況。
通過下面的命令可以看到遷移前和遷移後都存在一些控制程式碼關聯，哪些遷移前的檔案已然被標示為deleted
#lsof |grep cytj_data.dbf
oracle     1536  oracle  263u      REG               8,11 64424517632    2490413 /home/oracle/tablespace/cytj_data.dbf (deleted)
oracle     5427  oracle  262uW     REG               8,17 64424517632   31719427 /data/cytj/datafile/cytj_data.dbf
oracle     5431  oracle  262u      REG               8,17 64424517632   31719427 /data/cytj/datafile/cytj_data.dbf
oracle     5433  oracle  260u      REG               8,17 64424517632   31719427 /data/cytj/datafile/cytj_data.dbf
oracle     6393  oracle  257u      REG               8,17 64424517632   31719427 /data/cytj/datafile/cytj_data.dbf
oracle     8729  oracle  257u      REG               8,11 64424517632    2490413 /home/oracle/tablespace/cytj_data.dbf (deleted)
oracle     8971  oracle  256u      REG               8,11 64424517632    2490413 /home/oracle/tablespace/cytj_data.dbf (deleted)
oracle     9358  oracle  256u      REG               8,11 64424517632    2490413 /home/oracle/tablespace/cytj_data.dbf (deleted)
以其中的一個程式為例，發現是一個應用連線。
#ps -ef|grep 1536
oracle    1536     1  0 18:07 ?        00:00:00 oraclecytj (LOCAL=NO)
root      6321  5715  0 22:48 pts/0    00:00:00 grep 1536
所以這些session還是對這個遷移造成了潛移默化的影響，我們需要釋放這些控制程式碼來，就可以kill掉了。
清理掉這些程式之後，再次檢視就沒有問題了。
#df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda11            106G   52G   50G  52% /home
/dev/sdb1             551G   61G  463G  12% /data
問題解決完了，還需要注意什麼呢，需要設定這個資料檔案的maxsize，這個分割槽目前有500G左右，所以大可以放心把它置為500G以內。原來的maxsize值是50G，差的還很遠呢。

第三個問題是關於MySQL的從庫問題。
因為之前有一臺伺服器因為硬體問題掉電，在補充了新的電源之後又開始正常工作了，但是檢視從庫的狀態發現顯示為：
> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.127.0.91
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000226
          Read_Master_Log_Pos: 506545322
               Relay_Log_File: mysql-relay.000023
                Relay_Log_Pos: 884805415
        Relay_Master_Log_File: mysql-bin.000225
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 1594
                   Last_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 884805205
              Relay_Log_Space: 1580224534
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 1594
               Last_SQL_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 200
                  Master_UUID: 170281bc-1957-11e4-ad6e-842b2b4841e9
             Master_Info_File: /U01/app/mysql_3306/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State:
           Master_Retry_Count: 86400
對於這個問題，stop slave,start slave是不會自動修復的。
可以使用change master來修復。
> stop slave;
Query OK, 0 rows affected (0.02 sec)
如果以前修復可以手工對應下標和日誌來指定修復，但是在gtid的場景裡，還是不需要這樣了。
> change master to Master_Log_File='mysql-bin.000226', Master_Log_Pos=884805205;
ERROR 1776 (HY000): Parameters MASTER_LOG_FILE, MASTER_LOG_POS, RELAY_LOG_FILE and RELAY_LOG_POS cannot be set when MASTER_AUTO_POSITION is active.
> change master to master_host='10.127.0.xxx',master_port =3306,master_user='repl',master_password='xxxx',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.51 sec)
然後再次檢視發現就開始縮小了日誌差距，大概等了十幾分鍾之後，就追平了日誌gap.
同一件事情總是會碰到這樣許許多多的小問題，總是讓人很操心，不過不總結不會進步啊。

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