LINUX.ORG.RU
ФорумAdmin

Восстановление базы mysql, из неправильного бэкапа

 , ,


0

2

Добрый день. Просят помочь восстановить базу, бэкап которой делался просто через копирование файлов /var/lib/mysql даже без остановки сервера. База для сайта на 1сбитрикс, конкретно нужно из таблички dev вытащить одну запись с кодом какой-то процедурки на сайте..

Можно ли это сделать? Восстановил данные в /var/lib/mysql_restored, подправил конфиги на эту директорию, и, естественно, Mysql не стартует..

innodb_force_recovery = 1-6 не помогли..

Один вопрос. Почему у вас везде умирает муська?
То хард доведем до появления бэдов, то бэкап на живой СУБД делаем копированием файлов. Может все-таки дело «не в бабине»?

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

Это следствие того, что она самая мейнстримовая среди начинающих и прочих пхпшников. Соответственно больше поломок и плача на форумах.

evgeny_aa ()
Ответ на: комментарий от goingUp

Тоже думаю, что база не жилец, но может можно восстановить хотя бы табличку?

2019-12-01  2:30:15 139621252817472 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2019-12-01  2:30:15 139621252817472 [Note] InnoDB: The InnoDB memory heap is disabled
2019-12-01  2:30:15 139621252817472 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-12-01  2:30:15 139621252817472 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2019-12-01  2:30:15 139621252817472 [Note] InnoDB: Compressed tables use zlib 1.2.8
2019-12-01  2:30:15 139621252817472 [Note] InnoDB: Using Linux native AIO
2019-12-01  2:30:15 139621252817472 [Note] InnoDB: Using generic crc32 instructions
2019-12-01  2:30:15 139621252817472 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2019-12-01  2:30:16 139621252817472 [Note] InnoDB: Completed initialization of buffer pool
2019-12-01  2:30:16 139621252817472 [Note] InnoDB: Highest supported file format is Barracuda.
2019-12-01  2:30:16 139621252817472 [Note] InnoDB: Starting crash recovery from checkpoint LSN=41936310197
2019-12-01  2:30:16 139621252817472 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
2019-12-01 02:30:16 7efc1b2d6240 InnoDB: Error: page 545 log sequence number 41936346710
InnoDB: is in the future! Current system log sequence number 41936344617.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: for more information.
2019-12-01 02:30:16 7efc1b2d6240 InnoDB: Error: page 465 log sequence number 41936346941
InnoDB: is in the future! Current system log sequence number 41936344617.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: for more information.
2019-12-01 02:30:16 7efc1b2d6240 InnoDB: Error: page 491 log sequence number 41936347958
InnoDB: is in the future! Current system log sequence number 41936344617.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: for more information.
2019-12-01 02:30:16 7efc1b2d6240 InnoDB: Error: page 806 log sequence number 41936348205
InnoDB: is in the future! Current system log sequence number 41936344617.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: for more information.
2019-12-01 02:30:16 7efc1b2d6240 InnoDB: Error: page 566 log sequence number 41936349119
InnoDB: is in the future! Current system log sequence number 41936344617.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: for more information.
2019-12-01 02:30:16 7efc1b2d6240 InnoDB: Error: page 536 log sequence number 41936350120
InnoDB: is in the future! Current system log sequence number 41936344617.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: for more information.
2019-12-01  2:30:16 139621252817472 [Note] InnoDB: Starting final batch to recover 44 pages from redo log
191201  2:30:16 [ERROR] mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 10.1.26-MariaDB-0+deb9u1
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 352445 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x30000
InnoDB: Probable data corruption on page 3498
InnoDB: Original record (compact record)
InnoDB: on that page.
InnoDB: Cannot find the dir slot for record (compact record)
InnoDB: on that page!
2019-12-01 02:30:16 7efbfdffb700 InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex d812c48200000daa00000d9f00000dab00000009c399540445bf000000000000000000002b4a00043f65801438ea07d303b2000500000010000000000000000000000000000000005bab000000000000000000000000000000002019-12-01  2:30:22 140240621142592 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

PATRI0T ()

Grep «кусок кода» ничего не выцепляет?

skyman ★★ ()
Ответ на: комментарий от PATRI0T

Тоже думаю, что база не жилец, но может можно восстановить хотя бы табличку?

Не думаю, что обычными способами сможешь. Но расковырять формат и вытащить данные - думаю, можно будет.

turtle_bazon ★★★★★ ()

По идее, такой способ создания бэкапа имеет право на жизнь, так как он не нагружает базу запросами и выполняется упираясь исключительно в скорость дисков.
Вот то что сервер не остановили - это плохо. Но если активная запись не велась, то может прокатить и так. Надо знать с какой версии mysqld брались файлы, такой же версии и подкладывать. Еще можно попробовать подсунуть все, кроме ib_logfile0 and ib_logfile1, вот пример: https://dba.stackexchange.com/questions/87692/flush-clean-mysql-ib-logfile0-i...

redwagon ()
Ответ на: комментарий от redwagon

отвечая на вопрос goingUp «как так-то, что дохнет вторая база за месяц» - я настроил бэкап средствами backuppc, и знал, что надо для баз обязательно скриптики дописать, экспортирующие дампы.. Но блин, это отложилось в долгий ящик, пока увы, не понадобилось. В общем, классика.. вину признаю(( скрипты для экспорта написал

Сейчас попробую удалить логи, посмотрим, что выйдет.

PATRI0T ()
Ответ на: комментарий от swagcat228

насколько я понял, ему нужны нормальные mysqldump-ы.. а у меня их нет, у меня голые файлы базы. вот бы из них наковырять..

PATRI0T ()

Перкона вот єто рекомендует, попробуй.

https://github.com/chhabhaiya/undrop-for-innodb

Мі продовіе бекапі делаем через xtrabackuр, чего и тебе советую.

Делает на лету, без остановки сервера, и надежно (восстанавливали буквально на прошлой неделе)

PunkoIvan ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.