URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID8
Нить номер: 6325
[ Назад ]
Исходное сообщение
"Разрушение таблиц Mysql"
Отправлено igors1979 , 08-Май-09 20:29 
Уважаемые господа. Заранее спасибо всем за помощь

Есть сервер выделенный под mysql
Freebsd 7.2
Мysql 5.0
4Gb оперативная память
2 винчестера SATAII RAID

На сервере одна рабочая база - общий объем ~ 10 Gb
При любых манипуляциях связанных с изменением таблиц происходит разрушение. При чем не всегда, но часто - без какой либо закономерности.

Проверка таблиц в phpmyadmin дает следующее:
Table is marked as crashed
1 client is using or hasn't closed the table prope...
Checksum for key:  8 doesn't match checksum for re...
Key 1 doesn't point at all records
Key 4 doesn't point at same records that key 1

Поискал по названиям ошибок - везде одно и то же решение - сделать repair таблиц. Но запускать по крону repair как то не хочется :)

Подскажите, пож-ста, куда копать? Заранее спасибо

Содержание
Сообщения в этом обсуждении
"Разрушение таблиц Mysql"
Отправлено svn , 09-Май-09 00:55 
Попробовать innodb.

Перейти на Postgresql.

Перейти на ...

"Разрушение таблиц Mysql"
Отправлено Sarge , 09-Май-09 04:58 
а с винчестером всё в порядке? Не сыпется? Память не сбоит?
"Разрушение таблиц Mysql"
Отправлено igors1979 , 09-Май-09 12:27 
>а с винчестером всё в порядке? Не сыпется? Память не сбоит?

а как проверить это дело? какова методика проверки таких вещей?


"Разрушение таблиц Mysql"
Отправлено svn , 09-Май-09 15:21 
>какова методика проверки таких вещей?

Память проверяется memtest, есть в меню загрузки практически во всех дистрибутивов linux или тут http://www.sysresccd.org/Main_Page

С дисками всё немного сложнее, надо немного понимать как они работают. Но обычно если в системном журнале нет ошибок о невозможности прочтения или записи сектора - диск в порядке.


Дело в том что портить таблицы документированное свойство mysql ))
C такими большими базами на mysql дышать надо осторожно, и тем более не трогать структуру и метаданные.

"Разрушение таблиц Mysql"
Отправлено igors1979 , 09-Май-09 16:11 
>Память проверяется memtest, есть в меню загрузки практически во всех дистрибутивов linux

Вот результат:

memtest 20
memtester version 4.0.8 (64-bit)
Copyright (C) 2007 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffffffffffff000
want 20MB (20971520 bytes)
got  20MB (20971520 bytes), trying mlock ...locked.
Loop 1:
  Stuck Address       : ok
  Random Value        : ok
  Compare XOR         : ok
  Compare SUB         : ok
FAILURE: 0xf3651e9130a74fbe != 0xe3651e9130a74fbe at offset 0x000e27cb.
FAILURE: 0xfd02b5dd8f8105d7 != 0xed02b5dd8f8105d7 at offset 0x0011857e.
  Compare MUL         : FAILURE: 0x00000002 != 0x00000001 at offset 0x0011857e.
  Compare DIV         : FAILURE: 0x6f27575c6fecb37a != 0x6f27575c6fecb37b at offset 0x0011857e.
  Compare OR          : FAILURE: 0x6b21044065aca25a != 0x6b21044065aca25b at offset 0x0011857e.
  Compare AND         :   Sequential Increment: ok
  Solid Bits          : ok
  Block Sequential    : ok
  Checkerboard        : ok
  Bit Spread          : ok
  Bit Flip            : ok
  Walking Ones        : ok
  Walking Zeroes      : ok

Loop 2:
  Stuck Address       : ok
  Random Value        : ok
  Compare XOR         : ok
FAILURE: 0xe23c850a0c8c2b58 != 0xf23c850a0c8c2b58 at offset 0x000861fc.
  Compare SUB         : FAILURE: 0xa8c468882713e538 != 0xf8c468882713e538 at offset 0x000861fc.
FAILURE: 0xb39368d7cdfc8219 != 0xa39368d7cdfc8219 at offset 0x000f022b.
  Compare MUL         : FAILURE: 0x00000001 != 0x00000002 at offset 0x000861fc.
  Compare DIV         : FAILURE: 0x72d7d3f3f6be6103 != 0x72d7d3f3f6be6102 at offset 0x000861fc.
  Compare OR          : FAILURE: 0x72c341e1749e2101 != 0x72c341e1749e2100 at offset 0x000861fc.
  Compare AND         :   Sequential Increment: ok
  Solid Bits          : ok
  Block Sequential    : ok
  Checkerboard        : ok
  Bit Spread          : ok
  Bit Flip            : ok
  Walking Ones        : ok
  Walking Zeroes      : ok

"Разрушение таблиц Mysql"
Отправлено Sarge , 09-Май-09 18:09 
>Дело в том что портить таблицы документированное свойство mysql ))

Можно ссылку на эту часть документации?

igors1979: битая память, срочно меняйте.

"Разрушение таблиц Mysql"
Отправлено svn , 09-Май-09 21:56 
>Можно ссылку на эту часть документации?

Официальная команда repair :)

"Разрушение таблиц Mysql"
Отправлено Sarge , 10-Май-09 08:12 
А что делать в постгрессе если база побилась? Только выкидывать? Обычно, вроде как, удобные средства восстановления считаются неотъемлемой частью надёжных решений (fsck для фс к примеру)...
"Разрушение таблиц Mysql"
Отправлено svn , 10-Май-09 09:32 
>А что делать в постгрессе если база побилась?

Как это? ))

Если выключили плохо, или другая исправимая без потери данных - то postgresql автоматически всё починит. Если же диск перестал читаться, или другая безвозвратная потеря части данных, то разумеется надо восстанавливать из резервной копии, если конечно данные важны :)

"Разрушение таблиц Mysql"
Отправлено Sarge , 10-Май-09 12:10 
>>А что делать в постгрессе если база побилась?
>
>Как это? ))

да хотябы память косячная, как в данном случае оказалось.

>Если выключили плохо, или другая исправимая без потери данных - то postgresql
>автоматически всё починит. Если же диск перестал читаться, или другая безвозвратная
>потеря части данных, то разумеется надо восстанавливать из резервной копии, если
>конечно данные важны :)

Бэкап + repair всё-таки получше чем просто бэкап. Не делать же резервные копии каждые 5 минут...

"Разрушение таблиц Mysql"
Отправлено svn , 10-Май-09 21:43 
>да хотябы память косячная, как в данном случае оказалось.

В этом случае нельзя гарантировать что данные в базе правильные. Ну исправит он метаданные, а с данными то беда ))

В postgresql конечно есть способы восстановить всё что можно.


>Бэкап + repair всё-таки получше чем просто бэкап.

Бекап просто нужен. repair как sql команда, нужен только в падучей субд, коей mysql и является. То что myisam таблицы портятся на ровном месте, широко известный в узких кругах (разработчиков и настройщиков mysql) факт.

>Не делать же резервные
>копии каждые 5 минут...

В нормальных субд (в том числе и postgresql) резервная копия может делаться непрерывно, и позволяет получить любое прошлое состояние субд с точностью до транзакции.

"Разрушение таблиц Mysql"
Отправлено Sarge , 11-Май-09 08:27 
>>да хотябы память косячная, как в данном случае оказалось.
>
>В этом случае нельзя гарантировать что данные в базе правильные. Ну исправит
>он метаданные, а с данными то беда ))

Часть данных будет нормальной в любом случае, а остальное может не так уж и важно (раз уж резервная копия не делалась). Всё одно это намного лучше чем потерять разом все 15 гиг.

>В postgresql конечно есть способы восстановить всё что можно.

какие? Насколько они быстрее/медленней repair и сколько ручной работы требуют?

>>Бэкап + repair всё-таки получше чем просто бэкап.
>
>Бекап просто нужен. repair как sql команда, нужен только в падучей субд,
>коей mysql и является. То что myisam таблицы портятся на ровном
>месте, широко известный в узких кругах (разработчиков и настройщиков mysql) факт.

ну может что-то и известно в очень узких кругах, а в широких кругах неплохо используется. У меня за 7 лет использования проблем тоже небыло. Может всё дело в нецелевом использовании?

>В нормальных субд (в том числе и postgresql) резервная копия может делаться
>непрерывно, и позволяет получить любое прошлое состояние субд с точностью до
>транзакции.

Это вы про слейвы? А разве в случае битой памяти от них будет много проку?

"Разрушение таблиц Mysql"
Отправлено igors1979 , 10-Май-09 12:08 

>
>igors1979: битая память, срочно меняйте.

Именно так и сделали - это решило вопрос!

Спасибо за поддержку!