ERROR 1062 при восстановлении базы UTM

Технические вопросы по UTM 5.0
Ответить
NeXuSs
Сообщения: 51
Зарегистрирован: Пт сен 03, 2010 10:31

ERROR 1062 при восстановлении базы UTM

Сообщение NeXuSs »

Здравствуйте!

Прошу помощи в решении возникшей у меня проблемы. Поиском по форуму пользовался, но целого решения у меня в голове так и не сложилось.

Использую UTM5 сборки 5.2.1-008. На днях решил внедрить архивирование базы UTM, так как она порядком подросла и весит 15 с небольшим Гигабайт. Естественно, решил сначала потестировать все на стенде, где из последнего бэкапа собирался восстановить рабочую базу и учиться архивированию.
Проблема появилась как раз при восстановлении базы. Через, примерно, час работы в консоль вывалилась следующая ошибка:
ERROR 1062 (23000) at line 17968: Duplicate entry '78278' for key 'PRIMARY'
Как результат - потеря целостности базы данных. При ручном просмотре в ней оказалось всего 78 таблиц, против 134. Ядро стартует, но в debug лог сыпятся сообщения об отсутствующих таблицах и в верификаторе
-- 14822 errors
-- 5346 warnings
, в main.log повторяется
ERROR : Apr 14 13:56:37 28c04300 DBCtx: Exception while doing SQL select !
ERROR : Apr 14 13:56:47 28c04300 DBCtx: <684502016> MySQL query failed:
ERROR : Apr 14 13:56:47 28c04300 DBASQLError: MySQL query failed:
Пытался восстановить базу данных из более раннего бэкапа - все прошло гладко, я понятия не имею почему вдруг в базе появилась какая-то ошибка, приведшая к тому, что, по сути, нормального бэкапа-то у меня и нет.
Дамп делаю так:
/usr/local/bin/mysqldump -e -q -uuser -ppassword UTM5 > /msqlbase/bckpbase/utm5_backup
Научите пожалуйста, как можно исправить ситуацию. 15-Гиговый файл дампа в "блокноте" не откроешь, чтобы посмотреть строку, которая ведет к появлению данного сообщения.

xxxupg
Сообщения: 457
Зарегистрирован: Вс май 02, 2010 10:00

Сообщение xxxupg »

ядро utm5 стопаете когда делаете бэкап?

NeXuSs
Сообщения: 51
Зарегистрирован: Пт сен 03, 2010 10:31

Сообщение NeXuSs »

Обязательно.
Есть мысль, конечно, на боевом сервере архивы пособирать руками и когда база станет меньше в размере, сдампить ее и попробовать восстановить. Так как она уже меньше в размере станет, можно будет попробовать разобраться. Но как-то стремно, честное слово :(

NeXuSs
Сообщения: 51
Зарегистрирован: Пт сен 03, 2010 10:31

Сообщение NeXuSs »

Пытаюсь проверить таблицу payment_transactions на боевом сервере, получаю следующее:
billing# mysqlcheck --analyze --check --databases UTM5 --tables payment_transactions -u user -ppass
mysqlcheck: Got error: 2013: Lost connection to MySQL server during query when executing 'CHECK TABLE ... '
В логе MySQL .err, обнаружил после этого следующее, там идет сообщение об ошибках:
140414 16:21:51 InnoDB: Page checksum 3886597968, prior-to-4.0.14-form checksum 1832904419
InnoDB: stored checksum 3886597968, prior-to-4.0.14-form stored checksum 1832904419
InnoDB: Page lsn 36 4257659314, low 4 bytes of lsn at page end 4257659314
InnoDB: Page number (if stored to page already) 1486,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an index page where index id is 0 167
InnoDB: (index "PRIMARY" of table "UTM5"."payment_transactions")
InnoDB: Corruption of an index tree: table "UTM5"."payment_transactions", index "PRIMARY",
InnoDB: father ptr page no 2531600, child page no 2531601
PHYSICAL RECORD: n_fields 23; compact format; info bits 0
0: len 4; hex 800131c6; asc 1 ;; 1: len 6; hex 00001116805f; asc _;; 2: len 7; hex 80000001060110; asc ;; 3: len 4; hex 800009b2; asc ;; 4: len 8; hex 0000000000406f40; asc @o@;; 5: len 4; hex 8000032a; asc *;; 6: len 8; hex 000000000000f03f; asc ?;; 7: len 8; hex 0000000000406f40; asc @o@;; 8: len 4; hex d342590b; asc BY ;; 9: len 4; hex d343aa93; asc C ;; 10: len 0; hex ; asc ;; 11: len 4; hex 80000064; asc d;; 12: len 4; hex 7ffffff5; asc ;; 13: len 0; hex ; asc ;; 14: len 0; hex ; asc ;; 15: len 4; hex 80000000; asc ;; 16: len 4; hex 80000000; asc ;; 17: len 4; hex 80000000; asc ;; 18: len 0; hex ; asc ;; 19: len 4; hex 8541cc78; asc A x;; 20: len 4; hex 80000000; asc ;; 21: len 0; hex ; asc ;; 22: len 4; hex 80000000; asc ;;
n_owned: 0; heap_no: 2; next rec: 231
PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 4; hex 8001313f; asc 1?;; 1: len 4; hex 0026a110; asc & ;;
n_owned: 0; heap_no: 617; next rec: 8750
InnoDB: You should dump + drop + reimport the table to fix the
InnoDB: corruption. If the crash happens at the database startup, see
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/ ... overy.html about
InnoDB: forcing recovery. Then dump + drop + reimport.
140414 16:21:51 InnoDB: Assertion failure in thread 680535968 in file btr/btr0btr.c line 630
InnoDB: Failing assertion: btr_node_ptr_get_child_page_no(node_ptr, offsets) == buf_frame_get_page_no(page)
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/ ... overy.html
InnoDB: about forcing recovery.
12:21:51 UTC - mysqld got signal 6 ;
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.
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.

key_buffer_size=16777216
read_buffer_size=1048576
max_used_connections=13
max_threads=151
thread_count=13
connection_count=13
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 326582 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
140414 16:21:51 mysqld_safe mysqld restarted
140414 16:21:51 [Note] Plugin 'FEDERATED' is disabled.
140414 16:21:51 InnoDB: Initializing buffer pool, size = 8.0M
140414 16:21:51 InnoDB: Completed initialization of buffer pool
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
140414 16:21:51 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Last MySQL binlog file position 0 3573, file name /msqlbase/binlogs/mysql-bin.000175
140414 16:21:51 InnoDB: Started; log sequence number 36 4257794713
140414 16:21:51 [Note] Recovering after a crash using /msqlbase/binlogs/mysql-bin
140414 16:21:51 [Note] Starting crash recovery...
140414 16:21:51 [Note] Crash recovery finished.
140414 16:21:51 [Note] Event Scheduler: Loaded 0 events
140414 16:21:51 [Note] /usr/local/libexec/mysqld: ready for connections.
Version: '5.1.67-log' socket: '/tmp/mysql.sock' port: 3306 FreeBSD port: mysql-server-5.1.67
140414 16:21:52 InnoDB: Warning: purge reached the head of the history list,
InnoDB: but its length is still reported as 38415! Make a detailed bug
InnoDB: report, and submit it to http://bugs.mysql.com

NeXuSs
Сообщения: 51
Зарегистрирован: Пт сен 03, 2010 10:31

Сообщение NeXuSs »

Вобщем, узнал откуда ноги растут - перезапустили mysqld, не остановив ядро UTM :(
Подскажите пожалуйста, можно ли поправить базу, не откатываясь на более ранний бэкап? С того времени было проведено около 1500 платежей, руками забивать с ума сойдешь. Может быть поможет переиндексирование?

kirush
Сообщения: 699
Зарегистрирован: Пт фев 04, 2005 13:58

Сообщение kirush »

Сохраните платежи из БД, и через utm_payment_tool загоните их.

NeXuSs
Сообщения: 51
Зарегистрирован: Пт сен 03, 2010 10:31

Сообщение NeXuSs »

Значит, по-другому вряд ли получится поправить базу? Только восстановление из рабочего дампа и доведение базы до актуального состояния вручную.

NeXuSs
Сообщения: 51
Зарегистрирован: Пт сен 03, 2010 10:31

Сообщение NeXuSs »

В общем, как и писал выше, восстановил базу из более раннего бэкапа, до актуального состояния довел руками, платежи ввел скриптом.
Образовался другой вопрос, по архивации.
База данных до архивации весит 15.5Гб, после того, как произойдет архивирование - 600Мб, все логично, но, новая архивная база, на которую "ссылается" основная, весит уже 37Гб! Почему так получается?
И, как я понимаю, ее ведь тоже надо бэкапить? Ведь в случае падения, история платежей и списаний уже будет недосупна.
Подскажите, кто как поступает в данном случае?

Ответить