forum.opennet.ru - "Разрушение таблиц Mysql" (13)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"Разрушение таблиц Mysql"

Форумы WEB технологии (Public)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Разрушение таблиц Mysql"		+/–
Сообщение от igors1979 (ok) on 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 как то не хочется :) Подскажите, пож-ста, куда копать? Заранее спасибо
Высказать мнение \| Ответить \| Правка \| Cообщить модератору

Оглавление

Разрушение таблиц Mysql, svn, 00:55 , 09-Май-09, (1)
Разрушение таблиц Mysql, Sarge, 04:58 , 09-Май-09, (2)

Разрушение таблиц Mysql, igors1979, 12:27 , 09-Май-09, (3)

Разрушение таблиц Mysql, svn, 15:21 , 09-Май-09, (4)

Разрушение таблиц Mysql, igors1979, 16:11 , 09-Май-09, (5)
Разрушение таблиц Mysql, Sarge, 18:09 , 09-Май-09, (6)

Разрушение таблиц Mysql, svn, 21:56 , 09-Май-09, (7)

Разрушение таблиц Mysql, Sarge, 08:12 , 10-Май-09, (8)

Разрушение таблиц Mysql, svn, 09:32 , 10-Май-09, (9)

Разрушение таблиц Mysql, Sarge, 12:10 , 10-Май-09, (11)

Разрушение таблиц Mysql, svn, 21:43 , 10-Май-09, (12)

Разрушение таблиц Mysql, Sarge, 08:27 , 11-Май-09, (13)

Разрушение таблиц Mysql, igors1979, 12:08 , 10-Май-09, (10)

Сообщения по теме [Сортировка по времени | RSS]

1. "Разрушение таблиц Mysql" +/–

Сообщение от svn (??) on 09-Май-09, 00:55

Попробовать innodb.
Перейти на Postgresql.
Перейти на ...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Разрушение таблиц Mysql" +/–

Сообщение от Sarge (??) on 09-Май-09, 04:58

а с винчестером всё в порядке? Не сыпется? Память не сбоит?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Разрушение таблиц Mysql" +/–

Сообщение от igors1979 (ok) on 09-Май-09, 12:27

>а с винчестером всё в порядке? Не сыпется? Память не сбоит?
а как проверить это дело? какова методика проверки таких вещей?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Разрушение таблиц Mysql" +/–

Сообщение от svn (??) on 09-Май-09, 15:21

>какова методика проверки таких вещей?
Память проверяется memtest, есть в меню загрузки практически во всех дистрибутивов linux или тут http://www.sysresccd.org/Main_Page
С дисками всё немного сложнее, надо немного понимать как они работают. Но обычно если в системном журнале нет ошибок о невозможности прочтения или записи сектора - диск в порядке.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Разрушение таблиц Mysql" +/–

Сообщение от igors1979 (ok) on 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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Разрушение таблиц Mysql" +/–

Сообщение от Sarge (??) on 09-Май-09, 18:09

>Дело в том что портить таблицы документированное свойство mysql ))
Можно ссылку на эту часть документации?
igors1979: битая память, срочно меняйте.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Разрушение таблиц Mysql" +/–

Сообщение от svn (??) on 09-Май-09, 21:56

>Можно ссылку на эту часть документации?
Официальная команда repair :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Разрушение таблиц Mysql" +/–

Сообщение от Sarge (??) on 10-Май-09, 08:12

А что делать в постгрессе если база побилась? Только выкидывать? Обычно, вроде как, удобные средства восстановления считаются неотъемлемой частью надёжных решений (fsck для фс к примеру)...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Разрушение таблиц Mysql" +/–

Сообщение от svn (??) on 10-Май-09, 09:32

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "Разрушение таблиц Mysql" +/–

Сообщение от Sarge (??) on 10-Май-09, 12:10

>>А что делать в постгрессе если база побилась?
>
>Как это? ))
да хотябы память косячная, как в данном случае оказалось.
>Если выключили плохо, или другая исправимая без потери данных - то postgresql
>автоматически всё починит. Если же диск перестал читаться, или другая безвозвратная
>потеря части данных, то разумеется надо восстанавливать из резервной копии, если
>конечно данные важны :)
Бэкап + repair всё-таки получше чем просто бэкап. Не делать же резервные копии каждые 5 минут...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "Разрушение таблиц Mysql" +/–

Сообщение от svn (??) on 10-Май-09, 21:43

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "Разрушение таблиц Mysql" +/–

Сообщение от Sarge (??) on 11-Май-09, 08:27

>>да хотябы память косячная, как в данном случае оказалось.
>
>В этом случае нельзя гарантировать что данные в базе правильные. Ну исправит
>он метаданные, а с данными то беда ))
Часть данных будет нормальной в любом случае, а остальное может не так уж и важно (раз уж резервная копия не делалась). Всё одно это намного лучше чем потерять разом все 15 гиг.
>В postgresql конечно есть способы восстановить всё что можно.
какие? Насколько они быстрее/медленней repair и сколько ручной работы требуют?
>>Бэкап + repair всё-таки получше чем просто бэкап.
>
>Бекап просто нужен. repair как sql команда, нужен только в падучей субд,
>коей mysql и является. То что myisam таблицы портятся на ровном
>месте, широко известный в узких кругах (разработчиков и настройщиков mysql) факт.
ну может что-то и известно в очень узких кругах, а в широких кругах неплохо используется. У меня за 7 лет использования проблем тоже небыло. Может всё дело в нецелевом использовании?
>В нормальных субд (в том числе и postgresql) резервная копия может делаться
>непрерывно, и позволяет получить любое прошлое состояние субд с точностью до
>транзакции.
Это вы про слейвы? А разве в случае битой памяти от них будет много проку?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "Разрушение таблиц Mysql" +/–

Сообщение от igors1979 (ok) on 10-Май-09, 12:08

>
>igors1979: битая память, срочно меняйте.
Именно так и сделали - это решило вопрос!
Спасибо за поддержку!

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Разрушение таблиц Mysql"		+/–
Сообщение от svn (??) on 09-Май-09, 00:55
Попробовать innodb. Перейти на Postgresql. Перейти на ...
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору

2. "Разрушение таблиц Mysql"		+/–
Сообщение от Sarge (??) on 09-Май-09, 04:58
а с винчестером всё в порядке? Не сыпется? Память не сбоит?
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "Разрушение таблиц Mysql"		+/–
	Сообщение от igors1979 (ok) on 09-Май-09, 12:27
	>а с винчестером всё в порядке? Не сыпется? Память не сбоит? а как проверить это дело? какова методика проверки таких вещей?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "Разрушение таблиц Mysql"		+/–
	Сообщение от svn (??) on 09-Май-09, 15:21
	>какова методика проверки таких вещей? Память проверяется memtest, есть в меню загрузки практически во всех дистрибутивов linux или тут http://www.sysresccd.org/Main_Page С дисками всё немного сложнее, надо немного понимать как они работают. Но обычно если в системном журнале нет ошибок о невозможности прочтения или записи сектора - диск в порядке. Дело в том что портить таблицы документированное свойство mysql )) C такими большими базами на mysql дышать надо осторожно, и тем более не трогать структуру и метаданные.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "Разрушение таблиц Mysql"		+/–
	Сообщение от igors1979 (ok) on 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
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "Разрушение таблиц Mysql"		+/–
	Сообщение от Sarge (??) on 09-Май-09, 18:09
	>Дело в том что портить таблицы документированное свойство mysql )) Можно ссылку на эту часть документации? igors1979: битая память, срочно меняйте.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "Разрушение таблиц Mysql"		+/–
	Сообщение от svn (??) on 09-Май-09, 21:56
	>Можно ссылку на эту часть документации? Официальная команда repair :)
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "Разрушение таблиц Mysql"		+/–
	Сообщение от Sarge (??) on 10-Май-09, 08:12
	А что делать в постгрессе если база побилась? Только выкидывать? Обычно, вроде как, удобные средства восстановления считаются неотъемлемой частью надёжных решений (fsck для фс к примеру)...
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "Разрушение таблиц Mysql"		+/–
	Сообщение от svn (??) on 10-Май-09, 09:32
	>А что делать в постгрессе если база побилась? Как это? )) Если выключили плохо, или другая исправимая без потери данных - то postgresql автоматически всё починит. Если же диск перестал читаться, или другая безвозвратная потеря части данных, то разумеется надо восстанавливать из резервной копии, если конечно данные важны :)
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "Разрушение таблиц Mysql"		+/–
	Сообщение от Sarge (??) on 10-Май-09, 12:10
	>>А что делать в постгрессе если база побилась? > >Как это? )) да хотябы память косячная, как в данном случае оказалось. >Если выключили плохо, или другая исправимая без потери данных - то postgresql >автоматически всё починит. Если же диск перестал читаться, или другая безвозвратная >потеря части данных, то разумеется надо восстанавливать из резервной копии, если >конечно данные важны :) Бэкап + repair всё-таки получше чем просто бэкап. Не делать же резервные копии каждые 5 минут...
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "Разрушение таблиц Mysql"		+/–
	Сообщение от svn (??) on 10-Май-09, 21:43
	>да хотябы память косячная, как в данном случае оказалось. В этом случае нельзя гарантировать что данные в базе правильные. Ну исправит он метаданные, а с данными то беда )) В postgresql конечно есть способы восстановить всё что можно. >Бэкап + repair всё-таки получше чем просто бэкап. Бекап просто нужен. repair как sql команда, нужен только в падучей субд, коей mysql и является. То что myisam таблицы портятся на ровном месте, широко известный в узких кругах (разработчиков и настройщиков mysql) факт. >Не делать же резервные >копии каждые 5 минут... В нормальных субд (в том числе и postgresql) резервная копия может делаться непрерывно, и позволяет получить любое прошлое состояние субд с точностью до транзакции.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "Разрушение таблиц Mysql"		+/–
	Сообщение от Sarge (??) on 11-Май-09, 08:27
	>>да хотябы память косячная, как в данном случае оказалось. > >В этом случае нельзя гарантировать что данные в базе правильные. Ну исправит >он метаданные, а с данными то беда )) Часть данных будет нормальной в любом случае, а остальное может не так уж и важно (раз уж резервная копия не делалась). Всё одно это намного лучше чем потерять разом все 15 гиг. >В postgresql конечно есть способы восстановить всё что можно. какие? Насколько они быстрее/медленней repair и сколько ручной работы требуют? >>Бэкап + repair всё-таки получше чем просто бэкап. > >Бекап просто нужен. repair как sql команда, нужен только в падучей субд, >коей mysql и является. То что myisam таблицы портятся на ровном >месте, широко известный в узких кругах (разработчиков и настройщиков mysql) факт. ну может что-то и известно в очень узких кругах, а в широких кругах неплохо используется. У меня за 7 лет использования проблем тоже небыло. Может всё дело в нецелевом использовании? >В нормальных субд (в том числе и postgresql) резервная копия может делаться >непрерывно, и позволяет получить любое прошлое состояние субд с точностью до >транзакции. Это вы про слейвы? А разве в случае битой памяти от них будет много проку?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "Разрушение таблиц Mysql"		+/–
	Сообщение от igors1979 (ok) on 10-Май-09, 12:08
	> >igors1979: битая память, срочно меняйте. Именно так и сделали - это решило вопрос! Спасибо за поддержку!
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору

Архив \| Удалить	Индекс форумов \| Темы \| Пред. тема \| След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 \| 2 \| 3 \| 4 \| 5 ] [Рекомендовать для помещения в FAQ]