Проблемы с UTM5

zafar · Сообщение **zafar** » Сб июн 13, 2009 10:44

как проверить таблицы InnoDB?

Siny · Сообщение **Siny** » Вс июн 14, 2009 07:45

чтоб попроще можно так
сделайте дамп
удалите базу
создайте
загрузите дамп в режиме myisam
сделайте ремонт
запустите ютм
проверьте верификатор
потом верните все в иннодб
криво, но в вашем случае вряд ли по другому решите

Wishmaster

2 zafar:

Вам не надо самостоятельно перезагружать mysql сервер. Включите максимальный уровень логирования, также включите запись всех запросов в лог. Запустите mysql, дождитесь, пока оно полностью стартанет, зайдите в консоль и дайте команду "check table ..."
Когда сервер упадет (Connection lost ...) лезьте в лог и смотрите, чего там написано, почему оно упало.

С большой долей вероятности могу сказать, что проще всего дропнуть таблицы "discount_transactions...". Можно попробовать их сначала забэкапить, но вероятнее всего, оно вывалится с ошибкой, как и при check table.

2 Siny:

При бэкапе, если повреждены эти таблицы, как только mysqldump до них дойдет, сервер вывалится.

----

Резюмируя. Попробуйте сначала бэкап (а вдруг, получится), если сервер снова свалится, то в вашем конкретном случае, единственный на мой взгляд вариант - дропнуть эти таблицы и воссоздать структуру из УТМ'овского sql.

zafar · Сообщение **zafar** » Пн июн 15, 2009 07:14

090615 08:45:54 mysqld started
InnoDB: 3 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 3 row operations to undo
InnoDB: Trx id counter is 0 415675904
InnoDB: Starting rollback of uncommitted transactions
InnoDB: Cleaning up trx with id 0 415433971
InnoDB: Cleaning up trx with id 0 389372908
InnoDB: Cleaning up trx with id 0 384659687
InnoDB: Rollback of uncommitted transactions completed
090615 8:45:58 InnoDB: Started
/usr/local/libexec/mysqld: ready for connections.
Version: '4.0.24' socket: '/tmp/mysql.sock' port: 3306 FreeBSD port: mysql-server-4.0.24
090615 8:49:26 InnoDB: error clustered record for sec rec not found
InnoDB: index `first_dtr` of table `UTM5/discount_transactions_iptraffic_all`
InnoDB: sec index record PHYSICAL RECORD: n_fields 4; 1-byte offs TRUE; info bits 0
0: len 4; hex ca30900c; asc 0 ;; 1: len 4; hex 80000fa6; asc ;; 2: len 4; hex 8000134c; asc L;; 3: len 4; hex 832027
0c; asc ' ;;

InnoDB: clust index record PHYSICAL RECORD: n_fields 1; 1-byte offs TRUE; info bits 0
0: len 8; hex 696e66696d756d00; asc infimum ;;

TRANSACTION 0 415680110, ACTIVE 8 sec, OS thread id 176086528 fetching rows, thread declared inside InnoDB 330
mysql tables in use 1, locked 0
MySQL thread id 2, query id 4000 localhost root Copying to tmp table
SELECT account_id, slink_id, t_class, SUM(bytes), base_cost, SUM(discount) FROM discount_transactions_iptraffic_all WHERE

disc
ount_date>='1243796400' AND discount_date <='1245037787' AND account_id='3974' GROUP BY

t_class,base_cost,account_id,slink_id
order by account_id, t_class, base_cost

InnoDB: Submit a detailed bug report to http://bugs.mysql.com
090615 8:49:26 InnoDB: error clustered record for sec rec not found
InnoDB: index `first_dtr` of table `UTM5/discount_transactions_iptraffic_all`
InnoDB: sec index record PHYSICAL RECORD: n_fields 4; 1-byte offs TRUE; info bits 0
0: len 4; hex ca347223; asc 4r#;; 1: len 4; hex 80000ff4; asc ;; 2: len 4; hex 80001300; asc ;; 3: len 4; hex 832044
c3; asc D ;;

InnoDB: clust index record PHYSICAL RECORD: n_fields 1; 1-byte offs TRUE; info bits 0
0: len 8; hex 696e66696d756d00; asc infimum ;;

TRANSACTION 0 415680110, ACTIVE 8 sec, OS thread id 176086528 fetching rows, thread declared inside InnoDB 330
mysql tables in use 1, locked 0
MySQL thread id 2, query id 4000 localhost root Copying to tmp table
SELECT account_id, slink_id, t_class, SUM(bytes), base_cost, SUM(discount) FROM discount_transactions_iptraffic_all WHERE

disc
ount_date>='1243796400' AND discount_date <='1245037787' AND account_id='3974' GROUP BY

t_class,base_cost,account_id,slink_id
order by account_id, t_class, base_cost

InnoDB: Submit a detailed bug report to http://bugs.mysql.com
090615 8:49:26 InnoDB: error clustered record for sec rec not found
InnoDB: index `first_dtr` of table `UTM5/discount_transactions_iptraffic_all`
InnoDB: sec index record PHYSICAL RECORD: n_fields 4; 1-byte offs TRUE; info bits 0
0: len 4; hex ca349ee6; asc 4 ;; 1: len 4; hex 80001010; asc ;; 2: len 4; hex 8000131f; asc ;; 3: len 4; hex 832048
c0; asc H ;;

InnoDB: clust index record PHYSICAL RECORD: n_fields 1; 1-byte offs TRUE; info bits 0
0: len 8; hex 696e66696d756d00; asc infimum ;;

TRANSACTION 0 415680110, ACTIVE 8 sec, OS thread id 176086528 fetching rows, thread declared inside InnoDB 330
mysql tables in use 1, locked 0
MySQL thread id 2, query id 4000 localhost root Copying to tmp table
SELECT account_id, slink_id, t_class, SUM(bytes), base_cost, SUM(discount) FROM discount_transactions_iptraffic_all WHERE

disc
ount_date>='1243796400' AND discount_date <='1245037787' AND account_id='3974' GROUP BY

t_class,base_cost,account_id,slink_id
order by account_id, t_class, base_cost

InnoDB: Submit a detailed bug report to http://bugs.mysql.com
090615 8:49:26 InnoDB: error clustered record for sec rec not found
InnoDB: index `first_dtr` of table `UTM5/discount_transactions_iptraffic_all`
InnoDB: sec index record PHYSICAL RECORD: n_fields 4; 1-byte offs TRUE; info bits 0
0: len 4; hex ca34e335; asc 4 5;; 1: len 4; hex 8000100d; asc ;; 2: len 4; hex 8000131c; asc ;; 3: len 4; hex 83204e
f7; asc N ;;

InnoDB: clust index record PHYSICAL RECORD: n_fields 1; 1-byte offs TRUE; info bits 0
0: len 8; hex 696e66696d756d00; asc infimum ;;

TRANSACTION 0 415680110, ACTIVE 8 sec, OS thread id 176086528 fetching rows, thread declared inside InnoDB 330
mysql tables in use 1, locked 0
MySQL thread id 2, query id 4000 localhost root Copying to tmp table
SELECT account_id, slink_id, t_class, SUM(bytes), base_cost, SUM(discount) FROM discount_transactions_iptraffic_all WHERE

disc
ount_date>='1243796400' AND discount_date <='1245037787' AND account_id='3974' GROUP BY

t_class,base_cost,account_id,slink_id
order by account_id, t_class, base_cost

InnoDB: Submit a detailed bug report to http://bugs.mysql.com

zafar · Сообщение **zafar** » Пн июн 15, 2009 07:22

Нельзя ли как то дропнуть эти 3 транзакции которые каждый раз пытается вылечить

InnoDB: Cleaning up trx with id 0 415433971
InnoDB: Cleaning up trx with id 0 389372908
InnoDB: Cleaning up trx with id 0 384659687

Может из за них вся эта проблема?

Wishmaster

У вас проблема не с транзакциями. А с тем, что ПОВРЕЖДЕНЫ таблицы. Отмена транзакций не поможет. Допустим, вы их отмените, но другие транзакции снова ее уронят.

Я уже сказал, пробуйте забэкапить, потом восстановить. Если не получится - дропать таблицы.

З.Ы. http://bugs.mysql.com/bug.php?id=5975
Кстати, а что у вас за версия MySQL?

zafar · Сообщение **zafar** » Пн июн 15, 2009 11:03

version 4.0.24

Wishmaster

zafar писал(а):version 4.0.24

Код: Выделить всё

&#91;8 Oct 2004 14&#58;58&#93; Heikki Tuuri 
http&#58;//lists.mysql.com/internals/17496

fixes this in the latest 4.1 source tree, as well as another UTF-8 bug where InnoDB
printed in SELECTs to the .err log warnings about a prefix being > 255 bytes long.

Regards,

Heikki

Попробуйте обновиться до последней MySQL 4.1

zafar · Сообщение **zafar** » Чт июн 18, 2009 07:11

Wishmaster писал(а):2 zafar:

Вам не надо самостоятельно перезагружать mysql сервер. Включите максимальный уровень логирования, также включите запись всех запросов в лог. Запустите mysql, дождитесь, пока оно полностью стартанет, зайдите в консоль и дайте команду "check table ..."
Когда сервер упадет (Connection lost ...) лезьте в лог и смотрите, чего там написано, почему оно упало.

С большой долей вероятности могу сказать, что проще всего дропнуть таблицы "discount_transactions...". Можно попробовать их сначала забэкапить, но вероятнее всего, оно вывалится с ошибкой, как и при check table.

2 Siny:

При бэкапе, если повреждены эти таблицы, как только mysqldump до них дойдет, сервер вывалится.

----

Резюмируя. Попробуйте сначала бэкап (а вдруг, получится), если сервер снова свалится, то в вашем конкретном случае, единственный на мой взгляд вариант - дропнуть эти таблицы и воссоздать структуру из УТМ'овского sql.

сделали дамп. получилось больше 100 таблиц в текстовом формате. таблицы "discount_transactions..." как и ожидалось вывалились.
теперь как дропнуть таблицы, просто удалить файл ibdata1 ? и как обратно из дампа восстановить в Innodb?

Wishmaster

zafar писал(а):
Wishmaster писал(а):2 zafar:

Вам не надо самостоятельно перезагружать mysql сервер. Включите максимальный уровень логирования, также включите запись всех запросов в лог. Запустите mysql, дождитесь, пока оно полностью стартанет, зайдите в консоль и дайте команду "check table ..."
Когда сервер упадет (Connection lost ...) лезьте в лог и смотрите, чего там написано, почему оно упало.

С большой долей вероятности могу сказать, что проще всего дропнуть таблицы "discount_transactions...". Можно попробовать их сначала забэкапить, но вероятнее всего, оно вывалится с ошибкой, как и при check table.

2 Siny:

При бэкапе, если повреждены эти таблицы, как только mysqldump до них дойдет, сервер вывалится.

----

Резюмируя. Попробуйте сначала бэкап (а вдруг, получится), если сервер снова свалится, то в вашем конкретном случае, единственный на мой взгляд вариант - дропнуть эти таблицы и воссоздать структуру из УТМ'овского sql.
сделали дамп. получилось больше 100 таблиц в текстовом формате. таблицы "discount_transactions..." как и ожидалось вывалились.
теперь как дропнуть таблицы, просто удалить файл ibdata1 ? и как обратно из дампа восстановить в Innodb?

Нет! Делайте стандартно. Сначала попробуйте TRUNCATE TABLE tablename; Если вывалится, тогда DROP TABLE tablename;

Руками файлы удалять нельзя! Innodb вам этого не простит.

Восстанавливать как обычно. mysql -u user -pPassword DBNAME < dump.sql

zafar · Сообщение **zafar** » Пт июн 19, 2009 07:15

>>Нет! Делайте стандартно. Сначала попробуйте TRUNCATE TABLE >>tablename; Если вывалится, тогда DROP TABLE tablename;

DROP - не подходит, TRUNCATE - попробую

>>Руками файлы удалять нельзя! Innodb вам этого не простит.

>>Восстанавливать как обычно. mysql -u user -pPassword DBNAME < >>dump.sql[/quote]

mysqldump мы давали на каждую таблицу отдельно, и получилось больше 100 файлов в текстовом формате. dump.sql - это откуда? может по другому надо делать dump ?

Siny · Сообщение **Siny** » Пт июн 19, 2009 08:04

Wishmaster писал(а): 2 Siny:

При бэкапе, если повреждены эти таблицы, как только mysqldump до них дойдет, сервер вывалится.

mysqldump -f ...
mysql -f

zafar · Сообщение **zafar** » Ср июн 24, 2009 13:21

Действительно, проблема решилась с mysqldump -f ...
Она создала дамп без проблемных табличек но со структурой их создания.

Потом удалил все ib* и *.frm . После перезагрузил без ядра UTM.
ib* файлы создались сами. Потом:

mysqladmin create UTM5
mysql UTM5 < dump.sql

и проблема решилась

Отдельное спасибо "Siny" и "Wishmaster" - реально помогли!