linux增加/根目錄的磁盤空間（基于LVM)

linux增加/根目錄的磁盤空間（基于LVM）

問題引出：

         在測試過程中替換so檔案，報磁盤空間不足的錯誤

[[email protected] ~]# df -h Filesystem            Size  Used Avail Use% Mounted on /dev/mapper/VolGroup00-LogVol00                        28G   27G  0  100% / /dev/sda1              99M  9.1M   85M  10% /boot none                 1014M  5.4M 1009M   1% /dev/shm /dev/sdb1              19G   77M   18G   1% /NewDisk [[email protected] ~]#

問題分析：

         這是一套公司的系統，由于當時系統部署架構的考慮，把中間件和資料庫部署在同一台機器上了，并且給了30G的磁盤空間。

         系統上占用磁盤空間的有2部分，一是軟體本身（我們的中間件），二是安裝的oracle資料庫。使用du指令，大概檢視了下所寫磁盤大小，發現都是在長期操作中，寫到背景資料庫的資料越來越大，導緻資料庫的表空間越來越大，對應的實體檔案就是datafile，占用了很大的表空間。

問題解決方法分析：

1、  系統不做改變，對資料庫的一些log、不用的資料進行删除

2、  注意到系統還有一塊20G的空磁盤沒有使用(/dev/sdb1)，把資料庫生成的資料遷移一部分到這塊新的磁盤并指定新生成資料到這塊磁盤上

3、  注意到系統的磁盤部署，當時使用的是lvm邏輯卷進行管理的，LVM的一個優點就是友善進行邏輯卷的動态增加，可以把/dev/sdb1這塊實體磁盤加到根目錄所在的卷組裡面，然後對根目錄所在的邏輯卷進行擴容

最後決定：方法1,2都是可行的，對自己的oracle稍有把握的人都可以實作。本人決定采用方法3，一是考慮系統本身會不斷的産生日志等增加空間，這樣整個磁盤都被系統所用，當然包括我們的中間件和資料庫；二是當時設計這個系統構架的采用LVM進行管理的，可能也想到了後面雖然業務的增加，磁盤空間将不夠，将要進行動态擴容。這種設計的理念的是OK的，但是這種設計也有他很大的局限性，下面再進行分析

LVM邏輯卷擴容的3種模式介紹

以下是自己對LVM邏輯卷進行擴容的實際應用中的3種模式進行了歸納和總結（個人觀點）

1、  不涉及根目錄的磁盤(自己用畫圖附件畫的圖，有點龊哈)

如上圖所示：sdb1隻是普通的資料卷組了邏輯卷，沒有被linux的根目錄所用，這個時候，可以把第一塊磁盤剩下的未使用的分區（sdb2）以及第二塊磁盤sdc，第三塊磁盤sdd等都可以通過LVM管理加進邏輯卷組，然後對邏輯卷進行擴容

2、  涉及根目錄的磁盤1

如圖所示：sda1被根目錄使用，組了邏輯卷，sda2是平常所說的linux的swap分區，和根目錄在同一個卷組下，隻是屬于不同的邏輯卷，這個時候，如果根目錄磁盤空間不夠了，要對其進行擴容。如果這塊sda當時設計的時候還有很大一部分空餘磁盤空間未用，那麼很慶幸的告訴你，這樣也是很容易把剩餘的磁盤空間通過LVM加到邏輯卷組，然後對邏輯卷進行擴容的。

3、  涉及根目錄的磁盤2

如圖所示：sda1被根目錄使用，組了邏輯卷1，sda2是swap分區，第一塊磁盤sda空間已經用完，必須通過新加的磁盤sdb，對根目錄所在的邏輯卷1進行擴容。那麼，恭喜你，中獎了，這是最麻煩的一種情況。要對邏輯卷進行動态調整，調整的時候要重新挂載檔案系統。是以根目錄的調整與其它lvm管理的檔案系統的調整稍有不同，必須先進入rescue模式。如果沒有linux系統相關經驗，很可能就死在最後一步linux rescue上。

具體解決問題步驟

1、 對系統做快照

這是我們測試組的真實測試環境，以下所做的操作涉及到根目錄邏輯卷的調整，萬一把系統給弄挂了，那肯定是要挨批的。

事實上，自己在解決這個問題之前，也隻是理論分析，以為和LVM邏輯卷擴容的3種模式介紹中的1,2方式一樣容易解決，把系統搞死了很多次，也幸虧做了虛拟機快照，才能保證萬一解決不成功可以回退或者多次實驗的可能性。網上查找資料的時候，也遇到一些同行做這個操作的時候，把系統搞死了，不知道去linux rescue的時候，最後把系統重裝的惡果。

2、使用LVM進行邏輯卷的擴容

（1）對系統新加磁盤并使用fdisk進行分區（這裡已有省略）

（2）檢視系統的邏輯卷組vg和邏輯卷lv

[[email protected] ~]# vgs   VG         #PV #LV #SN Attr  VSize  VFree   VolGroup00   1   2   0 wz--n 29.88G 32.00M [[email protected] ~]# lvs   LV       VG         Attr   LSize  Origin Snap%  Move Copy%   LogVol00 VolGroup00 -wi-ao 27.91G                            LogVol01 VolGroup00 -wi-ao  1.94G

或者使用vgdisplay和lvdisplay

[[email protected] ~]# vgdisplay   --- Volume group ---   VG Name               VolGroup00   System ID               Format                lvm2   Metadata Areas        1   Metadata Sequence No  3   VG Access             read/write   VG Status             resizable   MAX LV                0   Cur LV                2   Open LV               2   Max PV                0   Cur PV                1   Act PV                1   VG Size               29.88 GB   PE Size               32.00 MB   Total PE              956   Alloc PE / Size       955 / 29.84 GB   Free  PE / Size       1 / 32.00 MB   VG UUID               Fj19eG-A1Ev-qs48-yI6b-HoL6-INnf-GwThFD  [[email protected] ~]# lvdisplay   --- Logical volume ---   LV Name                /dev/VolGroup00/LogVol00   VG Name                VolGroup00   LV UUID                SRV5oM-Kndv-QlHn-68Pq-OlvT-LdJj-julBsj   LV Write Access        read/write   LV Status              available   # open                 1   LV Size                27.91 GB   Current LE             893   Segments               1   Allocation             inherit   Read ahead sectors     0   Block device           253:0   --- Logical volume ---   LV Name                /dev/VolGroup00/LogVol01   VG Name                VolGroup00   LV UUID                RxmWcw-lV95-O4T4-HanR-RvqZ-UEPZ-NPLh04   LV Write Access        read/write   LV Status              available   # open                 1   LV Size                1.94 GB   Current LE             62   Segments               1   Allocation             inherit   Read ahead sectors     0   Block device           253:1 [[email protected] ~]#

(3)對新磁盤建立pv

[[email protected] ~]# pvcreate /dev/sdb1   Physical volume "/dev/sdb1" successfully created

(4)把PV加入VG

[[email protected] ~]# vgextend  VolGroup00 /dev/sdb1   Volume group "VolGroup00" successfully extended

并使用lvdisplay 和 vgdisplay進行檢查确認

（5）擴充lv

[[email protected] ~]# vgs   VG         #PV #LV #SN Attr  VSize   VFree   VolGroup00   2   2   0 wz--n 48.50G  18.66G   [ro[email protected] ~]# lvextend -L +18.5G /dev/VolGroup00/LogVol00 /dev/sdb1   Extending logical volume LogVol00 to 46.41 GB   device-mapper ioctl cmd 9 failed: Invalid argument   Couldn't load device 'VolGroup00-LogVol00'.   Problem reactivating LogVol00

由于我們的系統環境是LVM邏輯卷擴容的3種模式介紹中介紹的第三種情況，是以此時，系統就hang住了。

當時以為是在ssh遠端操作的結果，後來在圖形化界面的終端進行操作還是同樣問題。後來經過查找資料，才知識是因為調整的時候要重新挂載檔案系統。是以根目錄的調整與其它lvm管理的檔案系統的調整稍有不同，必須先進入rescue模式。進入rescue模式，需要挂載isoCD光牒，弄到晚上9點多了，手頭上沒有isoCD光牒，就回去睡覺下載下傳了一個，然後第二天用移動硬碟拷過來繼續幹

2、 linux的rescue模式

重新開機系統，系統就這幅德行了

當然很着急，還好後面進行了問題的解決

挂載iso鏡像，并設定系統從CD ROM啟動

在boot：裡面輸入 linux rescue進入linux系統救援模式

按照提示一步一步進行，在是否啟用網絡的時候選擇不啟用

進入下一步之後

選擇continue之後，按照提示進行指令界面

df是檢視分區挂載情況

由于要重置邏輯卷的大小，是以要把挂載的檔案系統給解除安裝了，使用umount

然後是vg的激活，vgchange

和最後的調整檔案系統大小，使用lvm vgchange 和 e2fsck，具體看截圖

這個時候，再shutdown -r系統，就OK了，但是啟動系統之後出現以下問題：

是因為linux系統啟動的時候讀的/etc/fstab的配置檔案内容沒有變，但是我們調整了磁盤的部署，解決方法如下：

在以上界面輸入root使用者的密碼，進行維護：

發現沒有挂載/boot分區,使用vim /etc/fstab檢視配置檔案内容

把 LABEL=/boot的分區類型由ext4修改為ext3，并把/dev/sdb1這段注釋掉，如下

儲存退出，重新開機，之後就OK了

調整之後的分區情況如下：