最近處理的小問題很多，我就拿出來幾個，簡單和大家說一說。我就分為三個方面，硬件問題，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.
同一件事情總是會碰到這樣許許多多的小問題，總是讓人很操心，不過不總結不會進步啊。

總結

以上是生活随笔為你收集整理的最近处理的几个小问题_20160311的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。