Повреждение базы данных MySQL после BAD секторов

[NETOS 129]

Всем привет!

Сервак с FreeBSD 8.1 и mysql-server-5.0.92

Еще стоит биллинг NoDeny и Zabbix

 

В общем перестало работать ядро биллинга, понял что нет связи с мускулем. Он не запущен. Обратил внимание что на мониторе сообщения об ошибках, точно не помню то писало, но понял что пипец винту приходит. Купил новый винт, смонтировал его, но при переносе базы не скопировался файл ibdata1. В общем долго мучался что да как потому что не знал что с этим всем делать, первый раз такое. В итоге с помощью mysqldump сохранил базу биллинга, мускуля, но при сохранении zabbix выпала ошибка:

 

mysqldump: Couldn't execute 'SELECT /*!40001 SQL_NO_CACHE */ * FROM `dchecks`': Los connection to MySQL server during query (2013)

 

Походу все это из за поврежденного жесткого диска.

 

Попытки дропнуть базу заббикса не удались.

 

Короче нафиг этот забикс, заново подыму, главное биллинг запустить. Помогите пожалуйста. Что дальше нужно сделать для поднятия базы на новом жестком. Базу заббикса также удалить не могу. Короче завис на этом....

 

 

Прикладываю логи:

InnoDB: Some operating system error numbers are described at
InnoDB: [url="http://dev.mysql.com/doc/refman/5.0/en/operating-system-error-codes.html"]http://dev.mysql.com...rror-codes.html[/url]
InnoDB: File operation call: 'read'.
InnoDB: Cannot continue operation.
121014 22:39:41 mysqld restarted
121014 22:39:41 InnoDB: Started; log sequence number 14 2359723208
InnoDB: !!! innodb_force_recovery is set to 4 !!!
121014 22:39:41 [Note] /usr/local/libexec/mysqld: ready for connections.
Version: '5.0.92' socket: '/tmp/mysql.sock' port: 3306 FreeBSD port: mysql-server-5.0.92
121014 22:52:49 [Note] /usr/local/libexec/mysqld: Normal shutdown

121014 22:52:51 InnoDB: Starting shutdown...
121014 22:52:52 InnoDB: Shutdown completed; log sequence number 14 2359723208
121014 22:52:52 [Note] /usr/local/libexec/mysqld: Shutdown complete

121014 22:52:52 mysqld ended

121014 23:35:12 mysqld started
121014 23:35:12 InnoDB: Started; log sequence number 14 2359723208
InnoDB: !!! innodb_force_recovery is set to 4 !!!
121014 23:35:12 [Note] /usr/local/libexec/mysqld: ready for connections.
Version: '5.0.92' socket: '/tmp/mysql.sock' port: 3306 FreeBSD port: mysql-server-5.0.92
InnoDB: Error: tried to read 16384 bytes at offset 0 999424.
InnoDB: Was only able to read -1.
121014 23:42:02 InnoDB: Operating system error number 5 in a file operation.
InnoDB: Error number 5 means 'Input/output error'.
InnoDB: Some operating system error numbers are described at
InnoDB: [url="http://dev.mysql.com/doc/refman/5.0/en/operating-system-error-codes.html"]http://dev.mysql.com...rror-codes.html[/url]
InnoDB: File operation call: 'read'.
InnoDB: Cannot continue operation.
121014 23:42:02 mysqld restarted
121014 23:42:03 InnoDB: Started; log sequence number 14 2359723208
InnoDB: !!! innodb_force_recovery is set to 4 !!!
121014 23:42:03 [Note] /usr/local/libexec/mysqld: ready for connections.
Version: '5.0.92' socket: '/tmp/mysql.sock' port: 3306 FreeBSD port: mysql-server-5.0.92
InnoDB: Some operating system error numbers are described at
InnoDB: [url="http://dev.mysql.com/doc/refman/5.0/en/operating-system-error-codes.html"]http://dev.mysql.com...rror-codes.html[/url]
InnoDB: File operation call: 'read'.
InnoDB: Cannot continue operation.
121014 22:39:41 mysqld restarted
121014 22:39:41 InnoDB: Started; log sequence number 14 2359723208
InnoDB: !!! innodb_force_recovery is set to 4 !!!
121014 22:39:41 [Note] /usr/local/libexec/mysqld: ready for connections.
Version: '5.0.92' socket: '/tmp/mysql.sock' port: 3306 FreeBSD port: mysql-server-5.0.92
121014 22:52:49 [Note] /usr/local/libexec/mysqld: Normal shutdown

121014 22:52:51 InnoDB: Starting shutdown...
121014 22:52:52 InnoDB: Shutdown completed; log sequence number 14 2359723208
121014 22:52:52 [Note] /usr/local/libexec/mysqld: Shutdown complete

121014 22:52:52 mysqld ended

121014 23:35:12 mysqld started
121014 23:35:12 InnoDB: Started; log sequence number 14 2359723208
InnoDB: !!! innodb_force_recovery is set to 4 !!!
121014 23:35:12 [Note] /usr/local/libexec/mysqld: ready for connections.
Version: '5.0.92' socket: '/tmp/mysql.sock' port: 3306 FreeBSD port: mysql-server-5.0.92
InnoDB: Error: tried to read 16384 bytes at offset 0 999424.
InnoDB: Was only able to read -1.
121014 23:42:02 InnoDB: Operating system error number 5 in a file operation.
InnoDB: Error number 5 means 'Input/output error'.
InnoDB: Some operating system error numbers are described at
InnoDB: [url="http://dev.mysql.com/doc/refman/5.0/en/operating-system-error-codes.html"]http://dev.mysql.com...rror-codes.html[/url]
InnoDB: File operation call: 'read'.
InnoDB: Cannot continue operation.
121014 23:42:02 mysqld restarted
121014 23:42:03 InnoDB: Started; log sequence number 14 2359723208
InnoDB: !!! innodb_force_recovery is set to 4 !!!
121014 23:42:03 [Note] /usr/local/libexec/mysqld: ready for connections.
Version: '5.0.92' socket: '/tmp/mysql.sock' port: 3306 FreeBSD port: mysql-server-5.0.92

[asa 5]

InnoDB гавкнулась, в интернете много расписано, в двух словах если нет бэкапов, очень плохо

единственное что можно будет сделать это запустить в InnoDB в режиме только чтение и попытаться хоть что то сдампить...

[NETOS 129]

Вы имеете ввиду сдампить так:

mysqldump -u root -p bill > /mnt/disk2/backup/bill.sql

 

это сделано! Не пойму как все запустить.

[Melanxolik 63]

давайте так, что у вас теперь есть и что надо?

если есть дамп то его надо пробовать разворачивать, на новом месте или том же без разницы.

 

в идеале можно было не парится и просто перенести файлы базы сперва, и с ними в другом месте работать, но тут много зависит как у вас настроена база, на разбивку файлов или все в одних больших innodb

[NETOS 129]

Короче пизнец!!! Только закончили ремонт... Никак не удалось восстановить базу, с привлечением спецов и штурмом интернета! Пришлось заново забивать, благо накануне сохранили список клиентов в html. Короче вроде как и подгрузили базу, и улицы есть и платежи. Но на главной странице нету списка клиентов, хотя написано что есть n записей. Что могло быть?

 

На будущее. Что можете посоветовать из raid ? Использовать gmirror или какой-то железный рейд. И какой ИБП посоветуете, чтобы часа 3-4 тянул обычную тачку ватт на 300 а если заряда не достаточно то выключал ее. Желательно с SNMP чтобы мне заббикс маякнул что тачка скоро потухнет.

[nightfly 1 239]

На будущее. Что можете посоветовать из raid

Могу посоветовать освоить использование mysqldump. Внезапной, так чтобы ну вобще ВНЕЗАПНО, смерти по бэдам тоже не существует - smartmontools не просто так в портах присутствуют.

 

Администраторы деляться на тех, кто делает бекапы и на безработных.

[NETOS 129]

На будущее. Что можете посоветовать из raid

Могу посоветовать освоить использование mysqldump. Внезапной, так чтобы ну вобще ВНЕЗАПНО, смерти по бэдам тоже не существует - smartmontools не просто так в портах присутствуют.

 

Администраторы деляться на тех, кто делает бекапы и на безработных.

 

Переделал базу и сразу же:

mysqldump -u root -p --all-database > /mnt/disk2/backup/161012.sql

 

а куда сохранять бекап, на тот же диск?

[Melanxolik 63]

NETOS

 

удивляюсь, давайте так:

1. каждая таблица хранится своем файле.

2. все таблицы находят в innodb

3. заббих прожорливая штука и лучше под неё юзать что-то оригинальней, к примеру: биллинг вы храните в обычной папке БД на обычном диске, можно даже 5400к, 160ГБ, а вот под заббих когда кол мониторинга будет ппц лучше изобразить тот же zfs с нулевым raid из двух дисков raptor на10тыс оборот. и пусть спокойно вращается, дальше там делаете симлинк на папку с БД забиха на папку хранящиюся на рэйд массиве. От сюда скорость и все такое... Бэкап каждую ночь, вариантов море...

Еще можно поднять просто второй серв с БД, и сделать его slave, ну вот его и бэкапить, не теряя производительность на первом) вариантов море...

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

И еще. Если вот так падает, можно было не заморачиватся с mysqldump, а просто скопировать папку с БД и её уже обрабатывать или на новом железе или в другом месте.

[Setevoy 127]

В первую очередь хочется посоветовать автоматическое регулярное резервное копирование за пределы серверной

[madf 279]

На будущее. Что можете посоветовать из raid

Могу посоветовать освоить использование mysqldump. Внезапной, так чтобы ну вобще ВНЕЗАПНО, смерти по бэдам тоже не существует - smartmontools не просто так в портах присутствуют.

 

Администраторы деляться на тех, кто делает бекапы и на безработных.

 

Переделал базу и сразу же:

mysqldump -u root -p --all-database > /mnt/disk2/backup/161012.sql

 

а куда сохранять бекап, на тот же диск?

Сохранять на тот-же диск как минимум глупо. Бекапы нужно делать оффсайт. В идеале на отдельный винт который потом ложить в банковскую ячейку (знаю как минимум одного такого человека который так и делает). Ну или на полку.

[Melanxolik 63]

Когда-то в детстве писал. Делалось раз в 3 дня, но если тачка слабая, и база большая, то пробел в графиках обеспечен, так что в этом случае mysqldump не канает.

 

#!/bin/sh

 

backup_dir="/usr/backup_sql"

date=`/bin/date +%d.%m.%Y_%H-%M-%s`

mysqldump="/usr/bin/mysqldump"

gzip="/usr/bin/gzip"

DATABASES="zabbix"

NAME="zabbix"

PASSWORD="LcnzJqqXBVvPD"

 

if [ ! -e "$backup_dir/$DATABASES" ]

then

mkdir -p "$backup_dir/$DATABASES"

fi

 

 

 

for db in $DATABASES; do

echo Dumping $db

$mysqldump --user=$NAME --password=$PASSWORD $DATABASES | $gzip > $backup_dir/$DATABASES/$DATABASES.$date.sql.gz

done;

 

[Melanxolik 63]

Да, еще как вариант при большой БД это уже использование снапшотов раздела с бд.

[Setevoy 127]

Переделал базу и сразу же:

mysqldump -u root -p --all-database > /mnt/disk2/backup/161012.sql

а куда сохранять бекап, на тот же диск?

На амазон, например.

 

Тыц

 

Ну и как-то так:

 

/usr/bin/7za a -pПАРОЛЬ $fpath.7z $fpath.sql

 

/usr/bin/s3cmd put $fpath.7z s3://название_бакета/$fname.7z

[nightfly 1 239]

а куда сохранять бекап, на тот же диск?

Локальное хранение бекапов эквивалентно их отсутствию.

[NETOS 129]

Подыму темку. Нашел статейку по автоматическому резервированию на ftp. Вот: http://mediaunix.com/2011/10/03/rezervnoe-kopirovanie-baz-mysql-na-freebsd/ До сего момента после падения базы использую ручное копирование на внешний хард. Подскажите сервисы бесплатные, но хорошие куда можно заливать файлы по ftp ну конечно чтобы конфиденциально. Или платные, но не дорогие.

[sergeev 1]

А взять в кроне через scp всю папку mysql

[NiTr0 584]

Ну сделайте у себя более-менее нормальное резервирование + резервное копирование...

1) софт-рэйд на машине с биллингом

2) тазик на каком-то древнем пеньке 3/атлоне(семпроне) 64, с новым блоком питания, и с парой винтиков опять же в рэйде, для бэкапов.

Стоимость этого - копейки, гораздо меньше вашей месячной з/п, и на порядки меньше стоимости простоя из-за отказа железа.

[Ромка 567]

Подыму темку. Нашел статейку по автоматическому резервированию на ftp. Вот: http://mediaunix.com...sql-na-freebsd/ До сего момента после падения базы использую ручное копирование на внешний хард. Подскажите сервисы бесплатные, но хорошие куда можно заливать файлы по ftp ну конечно чтобы конфиденциально. Или платные, но не дорогие.

ya.disk. 10Гб дают бесплатно. Но там не ftp, а webdav, что в некоторых случаях гораздо удобнее чем ftp.

[Lambert 5]

а куда сохранять бекап, на тот же диск?

o_O

стриммера у вас, предположим, нет. Но вербатимоские болванки неужто тоже продавать перестали?

[RVL 6]

ну какие болванки ), 21 век на дворе

 

Вот такое решение уже давно использую:

http://market.yandex.ua/model.xml?modelid=7275895&hid=91033

Внутри два винта в 1-ом рейде. Стоит далеко за пределами серверной.

 

Лучше клауда, свой собственный клауд. )

[maxx 202]

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

[Lambert 5]

ну какие болванки ), 21 век на дворе

а какие еще есть способы хранить инфу долговременно по ~2 грн/4.7 гига?

[madf 279]

ну какие болванки ), 21 век на дворе

а какие еще есть способы хранить инфу долговременно по ~2 грн/4.7 гига?

Жесткий диск. 2Тб за $100.

2/4.7 это примерно 0.43 грн/Гб

800/2048 это примерно 0ю39 грн/Гб

И болванки сейчас дико ненадежны. Год прошел и уже не читаются. Так что карман + винт - отличное решение для холодного бекапа.

[Lambert 5]

Выходит дешевле, да.

Но к сожалению, "Винчестер - не место для долговременного хранения информации" (С) Д. Постригань, известный гуру HDD-ремонта

а стриммер - дорого

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

[madf 279]

Выходит дешевле, да.

Но к сожалению, "Винчестер - не место для долговременного хранения информации" (С) Д. Постригань, известный гуру HDD-ремонта

а стриммер - дорого

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

Вот я так музыку хранил. Потом просто выбросил - половина не читалась уже через год.

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

А что может случиться с винтом лежащим в банковской ячейке?