Давно заметил что в Ubuntu (server edition) во время инсталляции начали предлагать использовать LVM. Но я все не решался поставить production на него. Затем пообщался со теми кто его использовал, почитал доку – и последний год стал его использовать, так как постиг скрытую в нем мощь 
Допустим, у нас есть простенький бюджетный сервер. Мы развернули новое приложение, и его база стала расти весьма стремительно. Итого – база, веб-файлы и система живут на одном физическом диске.
Был куплен диск WD Razor, и на него перенесли базу. Нагрузка диска (iostat -x -m 1) составила 1-2%. Решено перенести туда же и веб-файлы, однако решение это пришло лишь через пару дней. Так что получилось наглядно продемонстрировать возможности LVM.
Part1. Creating…
Когда поставили разор на нем создали один раздел – LVM:
Disk /dev/sdb: 74.3 GB, 74355769344 bytes
255 heads, 63 sectors/track, 9039 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdb1 1 9039 72605736 8e Linux LVM
Пару слов об организации LVM.
Уровень 1: volume group (vg). Это наивысший уровень абстракции, объединяющий в себе logical volumes и physical volumes.
Уровень 2: physical volume (pv). Это некое блочное устройство, способное хранить данные (HDD, RAID, …)
Уровень 3: logical volume (lv). Это эквивалент раздела на жестком диске.
Таким образом в группу добавляются физические тома (pv), и потом во всем этом пространстве свободного места создаются разделы (lv), на которых уже создается файловая система.
Итак, сначала создавался pv:
Затем vg:
И затем на все свободное место указанного pv (/dev/sdb1) создали lv с именем var_lib_mysql:
Дело за малым:
mount /dev/mapper/sys_vg-var_lib_mysql /mnt
/etc/init.d/mysql stop
mv /var/lib/mysql/* /mnt/
mv /var/lib/mysql/.* /mnt/
umount /mnt
mount /dev/mapper/sys_vg-var_lib_mysql /var/lib/mysql
chown -R mysql:mysql /var/lib/mysql
/etc/init.d/mysql start
Вот собственно и почти все. Последний штрих – прописать монтирование раздела в fstab, дабы это происходило при загрузке автоматом. Можно скучно сделать это через blkid, увидеть там нужный UUID (например, f6946e54-c7d6-4688-8fac-05dcb1bf9973), скопировать его, открыть /etc/fstab и вставить туда строку вида:
а можно сделать так:
Да, если сделать umount /var/lib/mysql && mount /var/lib/mysql до ребута – то /dev/disk/by-uuid/f6946e54-c7d6-4688-8fac-05dcb1bf9973 (или какой там получится) там еще не будет. Для того чтоб появился до ребута надо перезапустить udev:
Part2. Resizing…
Как я говорил раньше, с опозданием пришла мысль о том, что неплохо бы вынести и статические файлы на этот же винт. И сделать это совсем просто! Для этого от того lv что был создан раньше (и именуется var_lib_mysql) откусим немного места.
Сначала остановим все службы (говорят, reiserfs увеличивается/уменьшается без проблем налету, но я этого пока не пробовал на себе):
umount /var/lib/mysql
Затем уменьшим файловую систему, а затем и lv на 20ГБ:
lvreduce -L-20G /dev/mapper/sys_vg-var_lib_mysql
На всякий случай я предпочел проверить фс на ошибки (а вдруг!):
Ну и возвращаем обратно MySQL:
/etc/init.d/mysql start
Теперь создадим lv для веб-файлов, и так как их намного меньше 20ГБ, я решил оставить 5ГБ про запас, никому их не присвоив. Потом можно будет налету добавить туда где закончится место.
mkreiserfs /dev/mapper/sys_vg-var_www
Далее – перенос файлов:
/etc/init.d/apache2 stop
mount /dev/mapper/sys_vg-var_www /mnt
mv /var/www/* /mnt/
mv /var/www/.* /mnt/
umount /mnt
mount /dev/mapper/sys_vg-var_www /var/www
/etc/init.d/apache2 start
/etc/init.d/nginx start
И опять не забываем про fstab:
По материалам:
PS: после изменения размера мог измениться UUID для lv var_lib_mysql, хотя я и не уверен в этом. Но проверить не помешает.
PS2: если работаете удаленно – не забывайте про screen.
PS3: писалось по памяти, так что могут быть некоторые неточности. Тупой копипаст без вовлечения мыслительного процесса чреват боком. Я предупредил 
