Команды lvm не сообщают об отсутствии данных после lvextend
Вчера на нашем сервере Ubuntu 18.04 произошла странная проблема. Один из членов команды попытался добавить 30 ГБ пространства к этому логическому элементу:
Disk /dev/mapper/rootvg-pgexecstsqllv: 32 GiB, 34359738368 bytes, 67108864 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
В системе должна быть одна группа томов (rootvg), но после выполнения команд lvextend и resize2fs система перестала показывать все значения из pvscan, vgscan, lvscan. Вот пример с vgscan с включенной подробной информацией. Предполагается, что в этой системе есть одна группа томов под названием rootvg. Чтение кэша сообщает "Группы томов не найдены".
vgscan -vv
devices/global_filter not found in config: defaulting to global_filter = [ "a|.*/|" ]
Setting global/locking_type to 1
Setting global/use_lvmetad to 1
global/lvmetad_update_wait_time not found in config: defaulting to 10
Setting response to OK
Setting protocol to lvmetad
Setting version to 1
Setting global/use_lvmpolld to 1
Setting devices/sysfs_scan to 1
Setting devices/multipath_component_detection to 1
Setting devices/md_component_detection to 1
Setting devices/fw_raid_component_detection to 0
Setting devices/ignore_suspended_devices to 0
Setting devices/ignore_lvm_mirrors to 1
devices/filter not found in config: defaulting to filter = [ "a|.*/|" ]
Setting devices/cache_dir to /run/lvm
Setting devices/cache_file_prefix to
devices/cache not found in config: defaulting to /run/lvm/.cache
Setting devices/write_cache_state to 1
Setting global/use_lvmetad to 1
Setting activation/activation_mode to degraded
metadata/record_lvs_history not found in config: defaulting to 0
Setting activation/monitoring to 1
Setting global/locking_type to 1
Setting global/wait_for_locks to 1
File-based locking selected.
Setting global/prioritise_write_locks to 1
Setting global/locking_dir to /run/lock/lvm
Setting global/use_lvmlockd to 0
Locking /run/lock/lvm/P_global WB
Wiping cache of LVM-capable devices
Wiping internal VG cache
Setting response to OK
Setting token to filter:3239235440
Setting daemon_pid to 665
Setting response to OK
Setting global_disable to 0
Reading volume groups from cache.
Setting response to OK
Setting response to OK
Setting response to OK
No volume groups found.
Unlocking /run/lock/lvm/P_global
Setting global/notify_dbus to 1
Команды сообщают, что больше не видят PV, LV и VG. Несмотря на то, что система все еще работает и файлы устройства кажутся нетронутыми.
ls -ld /dev/rootvg /dev/rootvg/* /dev/mapper/root* /dev/dm*
brw-rw---- 1 root disk 253, 0 Jul 13 22:07 /dev/dm-0
brw-rw---- 1 root disk 253, 1 Jul 13 22:07 /dev/dm-1
brw-rw---- 1 root disk 253, 10 Jul 13 22:07 /dev/dm-10
brw-rw---- 1 root disk 253, 11 Jul 13 22:07 /dev/dm-11
brw-rw---- 1 root disk 253, 2 Jul 13 22:07 /dev/dm-2
brw-rw---- 1 root disk 253, 3 Jul 13 22:07 /dev/dm-3
brw-rw---- 1 root disk 253, 4 Jul 13 22:07 /dev/dm-4
brw-rw---- 1 root disk 253, 5 Jul 13 22:07 /dev/dm-5
brw-rw---- 1 root disk 253, 6 Jul 13 22:07 /dev/dm-6
brw-rw---- 1 root disk 253, 7 Jul 13 22:07 /dev/dm-7
brw-rw---- 1 root disk 253, 8 Jul 13 22:07 /dev/dm-8
brw-rw---- 1 root disk 253, 9 Jul 13 22:07 /dev/dm-9
lrwxrwxrwx 1 root root 7 Jul 13 22:07 /dev/mapper/rootvg-appslv -> ../dm-2
lrwxrwxrwx 1 root root 7 Jul 13 22:07 /dev/mapper/rootvg-execdirstsqllv -> ../dm-6
lrwxrwxrwx 1 root root 7 Jul 13 22:07 /dev/mapper/rootvg-execstsqlddlv -> ../dm-8
lrwxrwxrwx 1 root root 8 Jul 13 22:07 /dev/mapper/rootvg-inbacklv -> ../dm-10
lrwxrwxrwx 1 root root 7 Jul 13 22:07 /dev/mapper/rootvg-nodeapplv -> ../dm-9
lrwxrwxrwx 1 root root 7 Jul 13 22:07 /dev/mapper/rootvg-pgarcloglv -> ../dm-4
lrwxrwxrwx 1 root root 7 Jul 13 22:07 /dev/mapper/rootvg-pgbackuplv -> ../dm-3
lrwxrwxrwx 1 root root 7 Jul 13 22:07 /dev/mapper/rootvg-pgexecstsqllv -> ../dm-5
lrwxrwxrwx 1 root root 7 Jul 13 22:07 /dev/mapper/rootvg-rootlv -> ../dm-0
lrwxrwxrwx 1 root root 8 Jul 13 22:07 /dev/mapper/rootvg-tempfslv -> ../dm-11
lrwxrwxrwx 1 root root 7 Jul 13 22:07 /dev/mapper/rootvg-tmplv -> ../dm-1
lrwxrwxrwx 1 root root 7 Jul 13 22:07 /dev/mapper/rootvg-workdirlv -> ../dm-7
drwxr-xr-x 2 root root 280 Jul 13 20:32 /dev/rootvg
lrwxrwxrwx 1 root root 7 Jul 13 22:07 /dev/rootvg/appslv -> ../dm-2
lrwxrwxrwx 1 root root 7 Jul 13 22:07 /dev/rootvg/execdirstsqllv -> ../dm-6
lrwxrwxrwx 1 root root 7 Jul 13 22:07 /dev/rootvg/execstsqlddlv -> ../dm-8
lrwxrwxrwx 1 root root 8 Jul 13 22:07 /dev/rootvg/inbacklv -> ../dm-10
lrwxrwxrwx 1 root root 7 Jul 13 22:07 /dev/rootvg/nodeapplv -> ../dm-9
lrwxrwxrwx 1 root root 7 Jul 13 22:07 /dev/rootvg/pgarcloglv -> ../dm-4
lrwxrwxrwx 1 root root 7 Jul 13 22:07 /dev/rootvg/pgbackuplv -> ../dm-3
lrwxrwxrwx 1 root root 7 Jul 13 22:07 /dev/rootvg/pgexecstsqllv -> ../dm-5
lrwxrwxrwx 1 root root 7 Jul 13 22:07 /dev/rootvg/rootlv -> ../dm-0
lrwxrwxrwx 1 root root 8 Jul 13 22:07 /dev/rootvg/tempfslv -> ../dm-11
lrwxrwxrwx 1 root root 7 Jul 13 22:07 /dev/rootvg/tmplv -> ../dm-1
lrwxrwxrwx 1 root root 7 Jul 13 22:07 /dev/rootvg/workdirlv -> ../dm-7
Похоже, что кэш LVM или что-то подобное было повреждено или пропало. Похоже, это уже случалось с другими, поскольку я нашел ряд подобных вопросов. Этот показался многообещающим:https://superuser.com/questions/421896/vgdisplay-and-lvdisplay-no-volume-groups-found .
К сожалению, это не решило проблему. Есть ли у кого-нибудь идеи, как восстановить кеш LVM? Есть ли что-нибудь, кроме переустановки, которое может это исправить?
Спасибо,
Стив
1 ответ
Перезагрузка (даже в режим восстановления) оставила нас в оболочке обслуживания с сообщением «rootvg не существует», несмотря на то, что все файлы /dev показывались нормально. Чего не хватало, так это всех файлов /dev/dm*, связанных с /dev/mapper.
Я подозреваю, что выполненный оператором lvextend мог перезаписать другой раздел дискового хранилища операционной системы, где хранилась информация о группе томов rootvg. Проверив историю, команды, которые они выполняли, выглядели нормально. Единственная ошибка, которую я заметил, заключалась в попытке выполнить lvextend и resize2fs от имени пользователя без полномочий root (не делал sudo).
Короче говоря, нам снова не удалось восстановить эту систему. Pvscan/vgscan был примерно всем, что было предложено, и с флагом -vvv указывало, что проблема, скорее всего, в кеше. Это уже случалось дважды, что заставило меня усомниться в надежности LVM в Ubuntu 16, 18 и 20.
Мы пересобрали эту систему с помощью Ubuntu 22.04, а затем восстановили нашу базу данных PostgreSQL, которая использовалась в этой системе, из ночной резервной копии. Хотелось бы, чтобы мы выяснили, что является причиной этого, поскольку, судя по результатам поиска в Google, об этом сообщалось как минимум 3-4 раза раньше. Просто ни у кого не было решения или даже предложения, что проверить, и этот сервер нельзя было оставить в том состоянии, в котором он был. Это было необходимо к концу дня.
Теперь у нас будет два сервера с потоковой репликацией PostgreSQL (она должна была уже быть!), и поэтому, если это произойдет снова, мы сможем вывести машину из строя и попытаться проанализировать ее больше, не влияя при этом на наших пользователей.