LINUX.ORG.RU
ФорумAdmin

Проблема с mysql,


0

2

Добрый день всем.

Возник трабл. При попытке обработать таблицу otrs\

mysql> alter table article_plain ENGINE='InnoDB';        
Получаю:
                                                         
ERROR 2013 (HY000): Lost connection to MySQL server during query

Пробовал выкручивать системные timeout:

   
mysql> show variables like '%packe%';                                                                                                                                                                                            
+--------------------------+------------+
| Variable_name            | Value      |
+--------------------------+------------+
| max_allowed_packet       | 536870912  |
| slave_max_allowed_packet | 1073741824 |
+--------------------------+------------+
2 rows in set (0.00 sec)
   
mysql> show variables like '%timeout%';                                                   +----------------------------+----------+
| Variable_name              | Value    |
+----------------------------+----------+
| connect_timeout            | 500      |
| delayed_insert_timeout     | 300      |
| innodb_lock_wait_timeout   | 500      |
| innodb_rollback_on_timeout | OFF      |
| interactive_timeout        | 90000    |
| lock_wait_timeout          | 31536000 |
| net_read_timeout           | 6000     |
| net_write_timeout          | 6000     |
| slave_net_timeout          | 3600     |
| wait_timeout               | 90000    |
+----------------------------+----------+
10 rows in set (0.00 sec)

Таблицу весит 19гиг, места хватает, операция обрывается минут через 15, куда еще можно посмотреть?

Таже ошибка появляется и во время выполнения mysqldump, из-за чего нету возможности сделать backup таблицы.

Ответ на: комментарий от YAR

В логах вижу следующее:

InnoDB: with raw, and innodb_force_... is removed.
130929 13:34:53  InnoDB: Assertion failure in thread 53215645696 in file btr0pcur.c line 437
InnoDB: Failing assertion: btr_page_get_prev(next_page, mtr) == buf_block_get_page_no(btr_pcur_get_block(cursor))
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
10:34:53 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=8388608
read_buffer_size=1048576
max_used_connections=64
max_threads=382
thread_count=63
connection_count=63
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1185990 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

130929 13:34:53 mysqld_safe mysqld restarted
130929 13:34:54 InnoDB: The InnoDB memory heap is disabled
130929 13:34:54 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130929 13:34:54 InnoDB: Compressed tables use zlib 1.2.7
130929 13:34:54 InnoDB: Initializing buffer pool, size = 16.0G 
130929 13:34:55 InnoDB: Completed initialization of buffer pool
130929 13:34:55 InnoDB: highest supported file format is Barracuda.

Обрыв идет всегда на одной строке. Уже что только не попробовал чтобы слить данные, но всегда до определенного момента. Как бы пропустить попробовать эту запись?

--force тоже не помогает, он обрывается, ведь в момент ошибки идет перезапуск сервера mysql автоматом и соединение не востанавливается.

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

проблема похоже имеенно с таблицей.

Попробуйте сделать «check table» и если потребуется «repair table», вдруг поможет.

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

Обрыв идет всегда на одной строке. Уже что только не попробовал чтобы слить данные, но всегда до определенного момента.

На одной и той-же строке БД? Попробуйте её просто селектом прочитать, мало-ли. Ну и проверка таблицы, как уже советовали.

Кажется можно сделать дамп БД в несколько заходов, но не уверен что это умеет mysqldump

MrClon ★★★★★ ()

Чувак, стоит почистить старые тикеты перед тем, как делать реструктуризацию базы. ОТРС имеет такую возможность, удалить тикеты безвозвратно.

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

Сам знаешь ситуацию, нельзя... максимум убрать в архив. Проблема интересней оказалось, перестала писать таблицу article_plain после апдейта, то есть данные вроде как есть, но любой запрос к записям приводит к краху БД.

InventoR ()

Попробуй таблицу кусками задампить. Можно зайти через веб-интерфейс типа phpmyadmin и дампить с записи №1 по 100 000, потом с 100 001 по 200 000 и т.д. Поступал так с большими базами, когда не было времени разбираться почему не бэкапится.

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

А строку ты эту смотрел - чего она из себя представляет? В эту таблицу юзеры пишут? Может там с кодировкой что-то.

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

В общем решение оказалось печальным, сделали дамп до куда смогли, так как дальше 340000 строки чтение приводило к краху самого сервере, он тупо перезапускался и востановили все это на другой сервак.

Пробовали даже переносить эту таблицу на SSD, загрузка стояла 100 процентов при попытке вычитать, и ровно через 100 секунд сервер завершал свою работу.

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