Перейти до

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


Рекомендованные сообщения

Всем привет!

Сервак с 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

Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 76
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

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

Ну сделайте у себя более-менее нормальное резервирование + резервное копирование... 1) софт-рэйд на машине с биллингом 2) тазик на каком-то древнем пеньке 3/атлоне(семпроне) 64, с новым блоком питан

Добавлю что "биллинг с рейдом" с UPS, рейд не спасает от повреждения файловой системы.

Posted Images

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Ссылка на сообщение
Поделиться на других сайтах
На будущее. Что можете посоветовать из raid

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

 

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

Ссылка на сообщение
Поделиться на других сайтах
На будущее. Что можете посоветовать из raid

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

 

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

 

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

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

 

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

Ссылка на сообщение
Поделиться на других сайтах

NETOS

 

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

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

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

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах
На будущее. Что можете посоветовать из raid

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

 

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

 

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

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

 

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

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

Ссылка на сообщение
Поделиться на других сайтах

Когда-то в детстве писал. Делалось раз в 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;

 

Ссылка на сообщение
Поделиться на других сайтах

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

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

Ссылка на сообщение
Поделиться на других сайтах
  • 2 months later...

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

o_O

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

Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

 

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

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.


×
×
  • Створити нове...