The OpenNET Project / Index page

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




Версия для распечатки Пред. тема | След. тема
Новые ответы [ Отслеживать ]
Достать mysql-базу из удаленной VM Proxmox, !*! brt, 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


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

  • Достать mysql-базу из удаленной VM Proxmox, !*! ACCA, 20:46 , 28-Янв-20 (1)
    Что значит "при активации /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:". То есть ты можешь каким-то образом примонтировать этот диск?

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

      > 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.




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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