The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Достать mysql-базу из удаленной VM Proxmox"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Файловые системы, диски / Linux)
Изначальное сообщение [ Отслеживать ]

"Достать mysql-базу из удаленной VM Proxmox"  +1 +/
Сообщение от brt (ok), 24-Янв-20, 16:04 
Есть отдельно стоящая нода Proxmox с LVM thin и диском виртуальной машины 130 - /dev/pve/vm-130-disk-0.
VM удалили, через сутки обнаружили это и остановили остальные VM, чтобы не писали в /dev/pve.
Как водится, внутри VM - mysql и очень нужная база данных.
Актуального бекапа VM и базы mysql нет.

Подскажите, как найти и восстановить базу mysql?


Что пробовал без успеха:

1. Восстановить состояние метаданных LVM на момент до удаления VM, в итоге lvs стал показывать искомый volume /dev/pve/vm-130-disk-0, в неактивном состоянии.
   В процессе восстановления пришлось использовать lvconvert --repair, который сломал LVM _https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1625201
   Предложенные workaround с пересозданием tmeta не помогает, при активации /dev/pve/vm-130-disk-0 возникает ошибка:
   device-mapper: reload ioctl on (253:7) failed: No data available

2. Искать testdisk-ом по физическому диску /dev/sda3 начала root-партиции внутри VM. Найденые 18 партиций не содержат известных текстовых фрагментов из VM 130.

3. Искать bgrep по всему физическому диску /dev/sda3 текстовые фрагменты из VM 130. Фрагменты обнаруживаются в двух местах физического диска,
   возможно VM восстанавливали несколько раз. Всё найденное за границами партиций найденных testdisk.
  
4. Восстанавливать только таблицы undrop-for-innodb поиском по диску /dev/sda3. Выгрузилось 12 GB страниц разных mysql-баз, включая искомую, но сильно смущает как гигантские номера таблиц при использовании dictionary/SYS_TABLES.sql и как то, что dictionary/SYS_INDEXES.sql ничего по этим номерам не находит, так и общий формат вывода утилиты:
   2020203D2020    4E414D455F434F    SYS_TABLES    "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0std\n\0\0!\0!\0!\0database\_name\0INSERT INTO tbl\_log\_\n    SET log\_id        "    5643947289462206311    NULL    NULL    NULL    1600742439    ""    741488441
   заметно отличающийся от варианта разработчика из первого ответа здесь:
   _https://dba.stackexchange.com/questions/23251/is-there-a-way-to-recover-a-dropped-mysql-database


Внутри /dev/pve/vm-130-disk-0:
    # dpkg -l |grep mysql-server-
         mysql-server-5.5               5.5.47-0+deb8u1                  amd64
    #  fdisk -l
         Disk /dev/sda: 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
         Disklabel type: dos
         Disk identifier: 0x65ab60ca
        
         Device     Boot    Start      End  Sectors  Size Id Type
         /dev/sda1  *        2048 64286719 64284672 30.7G 83 Linux
         /dev/sda2       64288766 67106815  2818050  1.4G  5 Extended
         /dev/sda5       64288768 67106815  2818048  1.4G 82 Linux swap / Solaris
    
proxmox:
    # uname -a
        Linux wz020 4.15.18-12-pve #1 SMP PVE 4.15.18-35 (Wed, 13 Mar 2019 08:24:42 +0100) x86_64 GNU/Linux
    # pveversion
        pve-manager/5.4-3/0a6eaa62 (running kernel: 4.15.18-12-pve)
    # pvs
        PV         VG  Fmt  Attr PSize PFree
        /dev/sda3  pve lvm2 a--  1.64t 6.00g
    # vgs
        VG                           #PV #LV #SN Attr   VSize VFree
        pve                            1  26   0 wz--n- 1.64t 6.00g


Буду благодарен за любые советы и идеи.
Спасибо!

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Достать mysql-базу из удаленной VM Proxmox"  +/
Сообщение от ACCA (ok), 28-Янв-20, 20:46 
Что значит "при активации /dev/pve/vm-130-disk-0" ?

Там несколько шагов в workaround:

    thin_dump /dev/mapper/vg02-pool0_tmeta > lvm_meta_dum
    lvcreate -n pool0meta2 -L 12G vg02
    thin_restore -i lvm_meta_dump -o /dev/mapper/vg02-pool0meta2
    lvconvert --thinpool vg02/pool0 --poolmetadata vg02/pool0meta2


Подозрительно выглядит
   device-mapper: reload ioctl on (253:7) failed: No data available

Похоже на баг https://bugzilla.redhat.com/show_bug.cgi?id=1512854
Намекают, что есть thin-provisioning-tools поновее.

Непонятно, откуда взялось "Внутри /dev/pve/vm-130-disk-0:". То есть ты можешь каким-то образом примонтировать этот диск?

Ответить | Правка | Наверх | Cообщить модератору

2. "Достать mysql-базу из удаленной VM Proxmox"  +/
Сообщение от brt (ok), 29-Янв-20, 15:24 
Прошу прощения за сумбурность - от объема задачи уже каша в голове.

> thin-provisioning-tools поновее

Спасибо, почему-то мне в голову не пришло.

Под активацией имеется ввиду: # lvchange -ay /dev/pve/vm-130-disk-0
С порчей meta удалось разобраться - возникало из-за того что device mapper не всегда отключал meta автоматически.
Про reload ioctl on (253:7) failed: No data available - чуть ниже.


Итого, вопрос по LVM можно сузить до следующего:

Восстановление метаданных LVM до момента удаления 130 и активация:
# vgcfgrestore --force --file /etc/lvm/archive/pve_00336-2034680334.vg pve
# vgimport pve
# lvchange -ay /dev/pve/vm-130-disk-0  # LVM самостоятельно активирует все зависимости, если сможет:
      Thin pool pve-data-tpool (254:6) transaction_id is 324, while expected 311.

# lvs -a
  LV              VG                           Attr       LSize   Pool Origin Data%  Meta%
  data            pve                          twi---tz--   1.57t                                                    
  [data_tdata]    pve                          Twi-a-----   1.57t                                                    
  [data_tmeta]    pve                          ewi-a-----  16.00g                                                    
  root            pve                          -wi-a-----  10.00g                                                    
  vm-130-disk-0   pve                          Vwi---tz--  32.00g data
  vm-137-disk-0   pve                          Vwi---tz--  22.00g data        

Если вручную изменить transaction_id с 311 на 324 в /etc/lvm/archive/pve_00336-2034680334.vg
и повторить восстановление, то активируется и pool data и неудалённая vm-137-disk-0, но удалённая vm-130-disk-0 не активируется:

# vgcfgrestore --force --file /etc/lvm/archive/pve_00336-2034680334.vg pve
# vgimport pve
# lvchange -ay /dev/pve/vm-130-disk-0  # LVM самостоятельно активирует все зависимости, если сможет:
device-mapper: reload ioctl on (254:19) failed: No data available
При этом в debug: pve-vm--130--disk--0: Skipping NODE_DEL [trust_udev]

# lvs -a
  LV              VG                           Attr       LSize   Pool Origin Data%  Meta%
  data           pve                          twi-aotz--   1.57t             5.86   0.44                            
  [data_tdata]    pve                         Twi-a-----   1.57t                                                    
  [data_tmeta]    pve                         ewi-a-----  16.00g                                                    
  root           pve                          -wi-a-----  10.00g                                                    
  vm-130-disk-0  pve                          Vwi---tz--  32.00g data
  vm-137-disk-0  pve                          Vwi-a-tz--  22.00g data        67.91

Похоже, чтобы увидеть список volumes по lvs нужна корректная transaction_id в meta - 311.
А для активации volume нужна корректная transaction_id в data-tpool, где сейчас 324.

Т.о вопрос сводится к:

  Как исправить Thin pool pve-data-tpool (254:6) transaction_id is 324, while expected 311 ?

Все найденные в Интернет решения сводятся к "измените transaction_id в lvm backup и выполните vgcfgrestore",
но у людей зеркальная ситуация: у них в data-tpool меньшая версия чем в meta.

Ответить | Правка | Наверх | Cообщить модератору

3. "Достать mysql-базу из удаленной VM Proxmox"  +/
Сообщение от ACCA (ok), 29-Янв-20, 22:07 
Посмотри здесь - https://blog.monotok.org/lvm-transaction-id-mismatch-and-met.../
Ответить | Правка | Наверх | Cообщить модератору

4. "Достать mysql-базу из удаленной VM Proxmox"  +/
Сообщение от brt (ok), 31-Янв-20, 21:03 
Ещё раз спасибо за подсказку!

Для Thin volumes в архивных файлах /etc/lvm/archive/*.vg нет physical extents, а есть только device_ids. Сопоставление между device_id и physical extents на блочном устройстве хранится в метаданных LVM и может быть выгружено из неактивного пула:

vgimport pve
lvchange --yes -ay pve/data_tmeta
thin_dump  /dev/mapper/pve-data_tmeta -o thin_dump_pve-data_tmeta.xml
lvchange       -an pve/data_tmeta

Т.к. lvremove вместе с thin volume заодно удаляет это сопоставление, то восстановление volume в данном случае невозможно.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Слёрм
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2020 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру