NETOS 129 Опубликовано: 2012-10-14 20:39:44 Share Опубликовано: 2012-10-14 20:39:44 Всем привет! Сервак с 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 Опубліковано: 2012-10-14 21:02:18 Share Опубліковано: 2012-10-14 21:02:18 InnoDB гавкнулась, в интернете много расписано, в двух словах если нет бэкапов, очень плохо единственное что можно будет сделать это запустить в InnoDB в режиме только чтение и попытаться хоть что то сдампить... Ссылка на сообщение Поделиться на других сайтах
NETOS 129 Опубліковано: 2012-10-14 21:11:05 Автор Share Опубліковано: 2012-10-14 21:11:05 Вы имеете ввиду сдампить так: mysqldump -u root -p bill > /mnt/disk2/backup/bill.sql это сделано! Не пойму как все запустить. Ссылка на сообщение Поделиться на других сайтах
Melanxolik 63 Опубліковано: 2012-10-15 06:01:56 Share Опубліковано: 2012-10-15 06:01:56 давайте так, что у вас теперь есть и что надо? если есть дамп то его надо пробовать разворачивать, на новом месте или том же без разницы. в идеале можно было не парится и просто перенести файлы базы сперва, и с ними в другом месте работать, но тут много зависит как у вас настроена база, на разбивку файлов или все в одних больших innodb Ссылка на сообщение Поделиться на других сайтах
NETOS 129 Опубліковано: 2012-10-16 08:29:57 Автор Share Опубліковано: 2012-10-16 08:29:57 Короче пизнец!!! Только закончили ремонт... Никак не удалось восстановить базу, с привлечением спецов и штурмом интернета! Пришлось заново забивать, благо накануне сохранили список клиентов в html. Короче вроде как и подгрузили базу, и улицы есть и платежи. Но на главной странице нету списка клиентов, хотя написано что есть n записей. Что могло быть? На будущее. Что можете посоветовать из raid ? Использовать gmirror или какой-то железный рейд. И какой ИБП посоветуете, чтобы часа 3-4 тянул обычную тачку ватт на 300 а если заряда не достаточно то выключал ее. Желательно с SNMP чтобы мне заббикс маякнул что тачка скоро потухнет. Ссылка на сообщение Поделиться на других сайтах
nightfly 1 239 Опубліковано: 2012-10-16 08:34:20 Share Опубліковано: 2012-10-16 08:34:20 На будущее. Что можете посоветовать из raid Могу посоветовать освоить использование mysqldump. Внезапной, так чтобы ну вобще ВНЕЗАПНО, смерти по бэдам тоже не существует - smartmontools не просто так в портах присутствуют. Администраторы деляться на тех, кто делает бекапы и на безработных. Ссылка на сообщение Поделиться на других сайтах
NETOS 129 Опубліковано: 2012-10-16 08:45:59 Автор Share Опубліковано: 2012-10-16 08:45:59 На будущее. Что можете посоветовать из raid Могу посоветовать освоить использование mysqldump. Внезапной, так чтобы ну вобще ВНЕЗАПНО, смерти по бэдам тоже не существует - smartmontools не просто так в портах присутствуют. Администраторы деляться на тех, кто делает бекапы и на безработных. Переделал базу и сразу же: mysqldump -u root -p --all-database > /mnt/disk2/backup/161012.sql а куда сохранять бекап, на тот же диск? Ссылка на сообщение Поделиться на других сайтах
Melanxolik 63 Опубліковано: 2012-10-16 08:53:58 Share Опубліковано: 2012-10-16 08:53:58 NETOS удивляюсь, давайте так: 1. каждая таблица хранится своем файле. 2. все таблицы находят в innodb 3. заббих прожорливая штука и лучше под неё юзать что-то оригинальней, к примеру: биллинг вы храните в обычной папке БД на обычном диске, можно даже 5400к, 160ГБ, а вот под заббих когда кол мониторинга будет ппц лучше изобразить тот же zfs с нулевым raid из двух дисков raptor на10тыс оборот. и пусть спокойно вращается, дальше там делаете симлинк на папку с БД забиха на папку хранящиюся на рэйд массиве. От сюда скорость и все такое... Бэкап каждую ночь, вариантов море... Еще можно поднять просто второй серв с БД, и сделать его slave, ну вот его и бэкапить, не теряя производительность на первом) вариантов море... 4. На сколько понимаю, то что произошло от коряво настроенной mysql в вашем случае, не сделаны нужные оптимизации, отсутствуют бинарные логи, а дальше думайте. И еще. Если вот так падает, можно было не заморачиватся с mysqldump, а просто скопировать папку с БД и её уже обрабатывать или на новом железе или в другом месте. Ссылка на сообщение Поделиться на других сайтах
Setevoy 127 Опубліковано: 2012-10-16 08:53:58 Share Опубліковано: 2012-10-16 08:53:58 В первую очередь хочется посоветовать автоматическое регулярное резервное копирование за пределы серверной Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2012-10-16 08:55:24 Share Опубліковано: 2012-10-16 08:55:24 На будущее. Что можете посоветовать из raid Могу посоветовать освоить использование mysqldump. Внезапной, так чтобы ну вобще ВНЕЗАПНО, смерти по бэдам тоже не существует - smartmontools не просто так в портах присутствуют. Администраторы деляться на тех, кто делает бекапы и на безработных. Переделал базу и сразу же: mysqldump -u root -p --all-database > /mnt/disk2/backup/161012.sql а куда сохранять бекап, на тот же диск? Сохранять на тот-же диск как минимум глупо. Бекапы нужно делать оффсайт. В идеале на отдельный винт который потом ложить в банковскую ячейку (знаю как минимум одного такого человека который так и делает). Ну или на полку. Ссылка на сообщение Поделиться на других сайтах
Melanxolik 63 Опубліковано: 2012-10-16 08:56:31 Share Опубліковано: 2012-10-16 08:56:31 Когда-то в детстве писал. Делалось раз в 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 Опубліковано: 2012-10-16 08:59:40 Share Опубліковано: 2012-10-16 08:59:40 Да, еще как вариант при большой БД это уже использование снапшотов раздела с бд. Ссылка на сообщение Поделиться на других сайтах
Setevoy 127 Опубліковано: 2012-10-16 09:05:20 Share Опубліковано: 2012-10-16 09:05:20 Переделал базу и сразу же: 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 Опубліковано: 2012-10-16 09:24:04 Share Опубліковано: 2012-10-16 09:24:04 а куда сохранять бекап, на тот же диск? Локальное хранение бекапов эквивалентно их отсутствию. Ссылка на сообщение Поделиться на других сайтах
NETOS 129 Опубліковано: 2013-01-02 13:02:17 Автор Share Опубліковано: 2013-01-02 13:02:17 Подыму темку. Нашел статейку по автоматическому резервированию на ftp. Вот: http://mediaunix.com/2011/10/03/rezervnoe-kopirovanie-baz-mysql-na-freebsd/ До сего момента после падения базы использую ручное копирование на внешний хард. Подскажите сервисы бесплатные, но хорошие куда можно заливать файлы по ftp ну конечно чтобы конфиденциально. Или платные, но не дорогие. Ссылка на сообщение Поделиться на других сайтах
sergeev 1 Опубліковано: 2013-01-02 14:11:43 Share Опубліковано: 2013-01-02 14:11:43 А взять в кроне через scp всю папку mysql Ссылка на сообщение Поделиться на других сайтах
NiTr0 584 Опубліковано: 2013-01-02 15:18:12 Share Опубліковано: 2013-01-02 15:18:12 Ну сделайте у себя более-менее нормальное резервирование + резервное копирование... 1) софт-рэйд на машине с биллингом 2) тазик на каком-то древнем пеньке 3/атлоне(семпроне) 64, с новым блоком питания, и с парой винтиков опять же в рэйде, для бэкапов. Стоимость этого - копейки, гораздо меньше вашей месячной з/п, и на порядки меньше стоимости простоя из-за отказа железа. Ссылка на сообщение Поделиться на других сайтах
Ромка 567 Опубліковано: 2013-01-02 15:20:07 Share Опубліковано: 2013-01-02 15:20:07 Подыму темку. Нашел статейку по автоматическому резервированию на ftp. Вот: http://mediaunix.com...sql-na-freebsd/ До сего момента после падения базы использую ручное копирование на внешний хард. Подскажите сервисы бесплатные, но хорошие куда можно заливать файлы по ftp ну конечно чтобы конфиденциально. Или платные, но не дорогие. ya.disk. 10Гб дают бесплатно. Но там не ftp, а webdav, что в некоторых случаях гораздо удобнее чем ftp. Ссылка на сообщение Поделиться на других сайтах
Lambert 5 Опубліковано: 2013-01-02 19:29:12 Share Опубліковано: 2013-01-02 19:29:12 а куда сохранять бекап, на тот же диск? o_O стриммера у вас, предположим, нет. Но вербатимоские болванки неужто тоже продавать перестали? Ссылка на сообщение Поделиться на других сайтах
RVL 6 Опубліковано: 2013-01-02 20:09:22 Share Опубліковано: 2013-01-02 20:09:22 ну какие болванки ), 21 век на дворе Вот такое решение уже давно использую: http://market.yandex.ua/model.xml?modelid=7275895&hid=91033 Внутри два винта в 1-ом рейде. Стоит далеко за пределами серверной. Лучше клауда, свой собственный клауд. ) Ссылка на сообщение Поделиться на других сайтах
maxx 202 Опубліковано: 2013-01-02 21:11:41 Share Опубліковано: 2013-01-02 21:11:41 мм, есть база не большая, мылыть помоему самое то. Мне на гмайл приезжают бекапы, темболее гугль диск достаточно прикольная фича. Ссылка на сообщение Поделиться на других сайтах
Lambert 5 Опубліковано: 2013-01-02 22:04:45 Share Опубліковано: 2013-01-02 22:04:45 ну какие болванки ), 21 век на дворе а какие еще есть способы хранить инфу долговременно по ~2 грн/4.7 гига? Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2013-01-03 06:35:43 Share Опубліковано: 2013-01-03 06:35:43 ну какие болванки ), 21 век на дворе а какие еще есть способы хранить инфу долговременно по ~2 грн/4.7 гига? Жесткий диск. 2Тб за $100. 2/4.7 это примерно 0.43 грн/Гб 800/2048 это примерно 0ю39 грн/Гб И болванки сейчас дико ненадежны. Год прошел и уже не читаются. Так что карман + винт - отличное решение для холодного бекапа. Ссылка на сообщение Поделиться на других сайтах
Lambert 5 Опубліковано: 2013-01-03 15:21:30 Share Опубліковано: 2013-01-03 15:21:30 Выходит дешевле, да. Но к сожалению, "Винчестер - не место для долговременного хранения информации" (С) Д. Постригань, известный гуру HDD-ремонта а стриммер - дорого А в чем ненадежность болванок? Если взять проверенный брэнд, записать на минимальной скорости, упаковать в диск-холдер и хранить в сухом, темном, прохладном месте. Почти как лекарство Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2013-01-03 15:35:16 Share Опубліковано: 2013-01-03 15:35:16 Выходит дешевле, да. Но к сожалению, "Винчестер - не место для долговременного хранения информации" (С) Д. Постригань, известный гуру HDD-ремонта а стриммер - дорого А в чем ненадежность болванок? Если взять проверенный брэнд, записать на минимальной скорости, упаковать в диск-холдер и хранить в сухом, темном, прохладном месте. Почти как лекарство Вот я так музыку хранил. Потом просто выбросил - половина не читалась уже через год. Та-же история что и с дискетами: первые работали годами, последние держались пару недель. А что может случиться с винтом лежащим в банковской ячейке? Ссылка на сообщение Поделиться на других сайтах
Рекомендованные сообщения
Создайте аккаунт или войдите в него для комментирования
Вы должны быть пользователем, чтобы оставить комментарий
Создать аккаунт
Зарегистрируйтесь для получения аккаунта. Это просто!
Зарегистрировать аккаунтВхід
Уже зарегистрированы? Войдите здесь.
Войти сейчас