S
Size: a a a
2021 June 24
NI
зато на 5.1 работает innodb data recovery tools и undrop for innodb :D
NI
https://launchpad.net/percona-data-recovery-tool-for-innodb
https://github.com/twindb/undrop-for-innodb (более новая версия от того же человека: Александра Кузминского)
https://www.parnassusdata.com/en/node/1257
https://twindb.com/undrop-for-innodb/
http://0pl.ru/vosstanovlenie-dannyih-innodb-s-pomoshhyu-percona/
если использовать data recovery tools то только trunk, а не релизовые версии старые.
https://github.com/twindb/undrop-for-innodb (более новая версия от того же человека: Александра Кузминского)
https://www.parnassusdata.com/en/node/1257
https://twindb.com/undrop-for-innodb/
http://0pl.ru/vosstanovlenie-dannyih-innodb-s-pomoshhyu-percona/
если использовать data recovery tools то только trunk, а не релизовые версии старые.
NI
data recover нужно если оно никак не подымется. Если 5.1 не последний, можно попробовать скопировать datadir на сервак/docker с самым новым 5.1 и задебажить где он отваливается
NI
надо поглядеть на другой машине/в контейнере. м.б. не будет валиться. У меня когда-то тоже жесть была всякая, а оказалось, что какой-то придурок собрал генту без поддержки pthread
S
да не, сервер работал у этого mysql uptime был больше года
но повисли запросы которые пытались что-то сделать с метаданными
я попробовал systemctl stop mysql
сделать
оно отрапортовало что ОК
но mysqld_safe и mysqld
в списке процессов осталось
я в итоге сделал kill -9
и оно перестало запускаться
сейчас сделал myisamchk --silent --force /data/mysql/*/*.MYI
оказывается там myisam тоже было
не помогло
но повисли запросы которые пытались что-то сделать с метаданными
я попробовал systemctl stop mysql
сделать
оно отрапортовало что ОК
но mysqld_safe и mysqld
в списке процессов осталось
я в итоге сделал kill -9
и оно перестало запускаться
сейчас сделал myisamchk --silent --force /data/mysql/*/*.MYI
оказывается там myisam тоже было
не помогло
NI
mysqld --user=mysql
NI
Пару старых удалить, а потом командой purge