Биллинговая система Nodeny

Главная категория => Курилка => Тема начата: Александр (AleksHr) от 22 Января 2010, 09:20:39



Название: Проблема после пропадания питания
Отправлено: Александр (AleksHr) от 22 Января 2010, 09:20:39
Приветствую, вчера отключили свет на несколько часов, UPS долго не продержались, и серверы не выключилися а просто вырубались  :(.
Все загрузилося нормально и вроде работает (корневой раздел у меня на серверах всегда смонтирован только в режыме чтения на всякий случай).

Но! При проверке fsck выдает (в режыме без записи только проверка):
Код:
fsck /var
** /dev/ad0s1d (NO WRITE)
** Last Mounted on /var
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=23559 (4 should be 0)
CORRECT? no

INCORRECT BLOCK COUNT I=1248273 (12 should be 8)
CORRECT? no

** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
UNREF FILE I=1648821  OWNER=mysql MODE=100600
SIZE=0 MTIME=Jan 22 09:12 2010
CLEAR? no

UNREF FILE I=1648824  OWNER=mysql MODE=100600
SIZE=0 MTIME=Jan 22 09:12 2010
CLEAR? no

UNREF FILE I=1648825  OWNER=mysql MODE=100600
SIZE=0 MTIME=Jan 22 09:12 2010
CLEAR? no

UNREF FILE I=1648832  OWNER=mysql MODE=100600
SIZE=0 MTIME=Jan 22 09:12 2010
CLEAR? no

UNREF FILE I=1648837  OWNER=mysql MODE=100600
SIZE=0 MTIME=Jan 22 09:12 2010
CLEAR? no

UNREF FILE  I=1648919  OWNER=www MODE=100600
SIZE=137 MTIME=Jan 22 09:14 2010
RECONNECT? no


CLEAR? no

** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? no

SUMMARY INFORMATION BAD
SALVAGE? no

BLK(S) MISSING IN BIT MAPS
SALVAGE? no

23329 files, 449381 used, 7672784 free (6912 frags, 958234 blocks, 0.1% fragmentation)
[

Делаю umount -f /var:
Код:
fsck /var
** /dev/ad0s1d
** Last Mounted on /var
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
23324 files, 449385 used, 7672782 free (6910 frags, 958234 blocks, 0.1% fragmentation)

Ошибок нет  :o. Монтирую назад файловою систему mount -rw /var - ошыбок также нет. Перегружаю машыну - проверяю - те же самые ошыбки  :(.

Сервер удаленный, локально проверить нет возможности.
/etc/rc.conf:
Код:
fsck_y_enable="YES"
background_fsck="NO"

Итог: ошыбки остались, так как после розмонтирования и последующего монтирования файловой системы их нет. Делаю вывод что в однопользовательском режыме также fsck не увидит ошыбок. Вопрос почему? И что делать?

P.S. В интернете люди пишут что у многих такая ошыбка уже много лет на серверах, и после неудчаного заврешения работы ошыбки только прибавляются (((, но все работает. Поможете?


Название: Re: Проблема после пропадания питания
Отправлено: elite от 22 Января 2010, 10:54:29
Используй gjournal!


Название: Re: Проблема после пропадания питания
Отправлено: Александр (AleksHr) от 22 Января 2010, 11:45:53
Используй gjournal!

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


Название: Re: Проблема после пропадания питания
Отправлено: Efendy от 22 Января 2010, 13:41:12
Сделай бекап БД и конфигов, переставь систему и накати - ведь по времени это несколько часов работы


Название: Re: Проблема после пропадания питания
Отправлено: Александр (AleksHr) от 22 Января 2010, 14:16:19
Сделай бекап БД и конфигов, переставь систему и накати - ведь по времени это несколько часов работы

Цитировать
Сервер удаленный, локально проверить нет возможности.

К серверу попасть нет возможности!! Вообще в ближайшую неделю...

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


Название: Re: Проблема после пропадания питания
Отправлено: blackjack от 22 Января 2010, 15:59:23
Мужики не поверите, вчера таже херня случилась, помогла только пересборка world.
Не запускался ни апач ни мускул ни ссш.
Из всего запустился только isc-dhcpd и snmpd.

У топикстатера система случайно не 8.0 ?

Кстати незнаю как вы удаленно зашли на этот сервер, ссш при этих симптомах у меня не стартовал.


Название: Re: Проблема после пропадания питания
Отправлено: blackjack от 22 Января 2010, 16:02:14
И еще, все сетевые приложения которые не запускались кричали - "No buffer space available"


Название: Re: Проблема после пропадания питания
Отправлено: Александр (AleksHr) от 22 Января 2010, 16:40:37
Не, у меня 7.2. Видимо мне помогло то, что корневой раздел всегда смонтирован только на чтение ))).
blackjack, а у тебя например при смонтированных разделах и запуске fsck выдает ошыбки?


Название: Re: Проблема после пропадания питания
Отправлено: blackjack от 22 Января 2010, 16:58:26
были ошибки, потом fsck исправил их но ситуация не изменилась.


Название: Re: Проблема после пропадания питания
Отправлено: Cell от 22 Января 2010, 20:16:59
Эх, все это очень грустно, на одном из серверов, который я по договору поддерживаю все так и случилось ( пока что делать не придумал.
А на своем сервере вот такая картина наблюдается:
Код:
Jan 21 11:20:45 inet-server kernel: rl1: link state changed to DOWN
Jan 21 11:20:46 inet-server upsmon[1116]: UPS Mustek@localhost on battery
Jan 21 11:33:56 inet-server upsmon[1116]: UPS Mustek@localhost battery is low
Jan 21 11:33:56 inet-server upsmon[1116]: Executing automatic power-fail shutdown
Jan 21 11:33:56 inet-server upsmon[1116]: Auto logout and shutdown proceeding
Jan 21 11:34:02 inet-server shutdown: halt by root:
Jan 21 11:34:08 inet-server upsd[1098]: mainloop: Interrupted system call
Jan 21 11:34:11 inet-server named[826]: stopping command channel on 127.0.0.1#953
Jan 21 11:34:11 inet-server named[826]: stopping command channel on ::1#953
Jan 21 11:34:11 inet-server named[826]: exiting
Jan 21 11:34:12 inet-server syslogd: exiting on signal 15
Jan 21 11:38:53 inet-server syslogd: kernel boot file is /boot/kernel/kernel
Jan 21 11:38:53 inet-server kernel: Copyright (c) 1992-2009 The FreeBSD Project.
Используйте на полную возможности своих упсов!


Название: Re: Проблема после пропадания питания
Отправлено: blackjack от 22 Января 2010, 20:21:21
ну вот есть несколько человек, как бы это выяснить в чем косяк?
и как бы воспроизвести такую ситуацию чтобы подебажить?


Название: Re: Проблема после пропадания питания
Отправлено: Александр (AleksHr) от 22 Января 2010, 20:29:12
cell, blackjack вам трудно на робочей машыне з фряхой тупо запустить fsck? И написать сюда вывод? Интересно будут ли косяки или нет. Если несложно плиз. Он и так работать будеть в режыме без записи, так что боятся нечего.


Название: Re: Проблема после пропадания питания
Отправлено: blackjack от 22 Января 2010, 20:35:42
пилять, это вобще, вот только что запустил и появились ошибки, вчерай клянусь небыло и сервер не ребутился. че за херня

вот фсцк

Код:
[root@db /home/admin]# fsck
** /dev/ad4s1a (NO WRITE)
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
3052 files, 105894 used, 2432625 free (1153 frags, 303934 blocks, 0.0% fragmentation)
** /dev/ad4s1f (NO WRITE)
** Last Mounted on /home
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
12096 files, 1463002 used, 31989579 free (6211 frags, 3997921 blocks, 0.0% fragmentation)
** /dev/ad4s1e (NO WRITE)
** Last Mounted on /usr
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
ALLOCATED FRAGS 23055376-23055391 MARKED FREE
ALLOCATED FRAG 23055439 MARKED FREE
ALLOCATED FRAGS 23055712-23055719 MARKED FREE
ALLOCATED FRAGS 23058696-23058703 MARKED FREE
BLK(S) MISSING IN BIT MAPS
SALVAGE? no

SUMMARY INFORMATION BAD
SALVAGE? no

320452 files, 2138737 used, 28326900 free (60316 frags, 3533323 blocks, 0.2% fragmentation)
** /dev/ad4s1d (NO WRITE)
** Last Mounted on /var
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=7301534 (270240 should be 270144)
CORRECT? no

INCORRECT BLOCK COUNT I=8172880 (363232 should be 363104)
CORRECT? no

** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
UNREF FILE I=4922374  OWNER=root MODE=100644
SIZE=0 MTIME=Jan 21 19:15 2010
CLEAR? no

UNREF FILE I=6806551  OWNER=mysql MODE=100600
SIZE=0 MTIME=Jan 22 18:48 2010
CLEAR? no

UNREF FILE I=6806552  OWNER=mysql MODE=100600
SIZE=0 MTIME=Jan 22 18:48 2010
CLEAR? no

UNREF FILE I=6806553  OWNER=mysql MODE=100600
SIZE=0 MTIME=Jan 22 18:48 2010
CLEAR? no

UNREF FILE I=6806554  OWNER=mysql MODE=100600
SIZE=0 MTIME=Jan 22 18:48 2010
CLEAR? no

UNREF FILE I=6806556  OWNER=mysql MODE=100600
SIZE=0 MTIME=Jan 22 18:48 2010
CLEAR? no

UNREF FILE  I=11121755  OWNER=smmsp MODE=100660
SIZE=723 MTIME=Jan 22 20:39 2010
RECONNECT? no


CLEAR? no

LINK COUNT FILE I=11121756  OWNER=smmsp MODE=100660
SIZE=822 MTIME=Jan 22 20:39 2010  COUNT 2 SHOULD BE 1
ADJUST? no

** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? no

SUMMARY INFORMATION BAD
SALVAGE? no

BLK(S) MISSING IN BIT MAPS
SALVAGE? no

501508 files, 4505259 used, 46271763 free (641179 frags, 5703823 blocks, 1.3% fragmentation)
** /dev/ad6s1d (NO WRITE)
** Last Mounted on /backup
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
25944 files, 28846278 used, 89409591 free (2015 frags, 11175947 blocks, 0.0% fragmentation)


Название: Re: Проблема после пропадания питания
Отправлено: blackjack от 22 Января 2010, 20:38:39
придется теперь ребутится
благо, настроена репликация базы

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


Название: Re: Проблема после пропадания питания
Отправлено: Александр (AleksHr) от 23 Января 2010, 00:08:24
blackjack, а я говорил!!!  :D

Так должно быть. На смонтированых файловых сестемах fsck всегда походу находит мусор (если во время проверки хоть какая нить запись на диск осуществляется). Розслабся ), если бы была ошибка - роздел бы не примонтировался.


Название: Re: Проблема после пропадания питания
Отправлено: Andrey Zentavr от 23 Января 2010, 18:28:50
кстати, у кого-то работает биллинг с резервным сервером и при дауне основного нормально переключается на резервный? потому что у меня ядро сразу вылетает, а в админке пишет что нет соединения с базой.
А вот это интересно :) Где прочитать об отказоустойчивости NoDeny?


Название: Re: Проблема после пропадания питания
Отправлено: Efendy от 26 Января 2010, 12:14:59
А вот это интересно :) Где прочитать об отказоустойчивости NoDeny?
В NoDeny есть одно неудобное требование: БД должна быть всегда в рабочем состоянии. Т.е. необходимо всеми силами обеспечить УПСами и рейдами это звено и все будет в порядке на много лет


Название: Re: Проблема после пропадания питания
Отправлено: blackjack от 26 Января 2010, 13:55:12
и всетаки считаю было бы неплохо, а точнее супер, если бы мы умели конектиццо на резервный сервер при дауне основного.


Название: Re: Проблема после пропадания питания
Отправлено: Efendy от 26 Января 2010, 15:38:47
и всетаки считаю было бы неплохо, а точнее супер, если бы мы умели конектиццо на резервный сервер при дауне основного.
вероятно в новой версии)


Название: Re: Проблема после пропадания питания
Отправлено: versus от 26 Января 2010, 22:41:11
и всетаки считаю было бы неплохо, а точнее супер, если бы мы умели конектиццо на резервный сервер при дауне основного.

ну если подходить серьезно, то тут просто изменять нодени мало будет, во первых должен быть кластер, как минимум репликация мускула мастер - мастер, во вторых нормальный хертбит, тогда и менять ничего  не надо в нодени все будет работать из коробки. При падении одного сервера хертбит подхватывает его айпи на другой мастер и тот работает как основной . При поднятии старого мастера надо будет догнать репликацию и ждать следующего даунтайма текущего мастера. Конечно это увеличит количество айди в базе потому как мастер - мастер работает при инсерте айди либо только четные либо нечетные. Да и сама репликация достаточно геморойный процесс в мускуле, но жить будет долго и счастливо. Конечно надо держать руку на пульсе и вовремя реагировать на падения.


Название: Re: Проблема после пропадания питания
Отправлено: Andrey Zentavr от 29 Января 2010, 01:42:00
во вторых нормальный хертбит, тогда и менять ничего  не надо в нодени все будет работать из коробки.

Вот что я знаю точно - так что linux 1000% работает с heartbeat для мониторинга нод и DRBD для синхронизации разделов - лично поднимал несколько таких систем.
Но вроде как фря этого не умеет.
Или я чего-то недопрочитал?


Название: Re: Проблема после пропадания питания
Отправлено: blackjack от 29 Января 2010, 15:18:27
собрал я кластер с MySQL 5.0.89.

опция для сборки WITH_NDB=yes

таблицы надо создавать с ENGINE=NDB;

для корректной работы необходимо минимум 3 сервера, я собирал на двух о чем меня вежливо предупредили

Код:
/usr/local/libexec/ndb_mgmd -f /var/lib/mysql-cluster/config.ini 
Warning line 41: Cluster configuration warning:
  arbitrator with id 1 and db node with id 2 on same host 172.16.21.122
  Running arbitrator on the same host as a database node may
  cause complete cluster shutdown in case of host failure.

еще один глюк, что все утилиты ndb* после установки размещаюся в каталоге /usr/local/libexec которого нет в переменной PATH

можна все это спрятать за carp интерфейсом, и работать.

С базой биллинга я не тестировал в реальных условиях - не рискнул.

Может у кого-то есть тестовый стенд чтобы проверить все это.

Руководствовался этим руководством. http://cn.km.ua/mysql-cluster.pdf


Название: Re: Проблема после пропадания питания
Отправлено: Andrey Zentavr от 29 Января 2010, 17:59:52
Необходимо поднять три виртуалки на фре?


Название: Re: Проблема после пропадания питания
Отправлено: blackjack от 29 Января 2010, 18:46:38
три физических сервера надо, если виртуалка, то весь смысл теряется


Название: Re: Проблема после пропадания питания
Отправлено: versus от 29 Января 2010, 20:00:50
во вторых нормальный хертбит, тогда и менять ничего  не надо в нодени все будет работать из коробки.

Вот что я знаю точно - так что linux 1000% работает с heartbeat для мониторинга нод и DRBD для синхронизации разделов - лично поднимал несколько таких систем.
Но вроде как фря этого не умеет.
Или я чего-то недопрочитал?
Фря это икона ? Я думал вам нужно отказоустойчивое решение для сервера БД... А тут уже операционка дело десятое.... Хоть на слонярисе лишь бы база работала 24х7 ИМХО..


Название: Re: Проблема после пропадания питания
Отправлено: goletsa от 29 Января 2010, 22:15:01
Нуда, гдето я мельком видел чтобы базы под Solaris/SPARC работают куда шустрее на больших нагрузках.
Не зря таки Oracle купил Sun.
А уж вкусности ZFS...


Название: Re: Проблема после пропадания питания
Отправлено: Elisium от 30 Января 2010, 00:38:57
ZFS есть и на фре.
А по поводу нагрузок - врятли они у вас настолько большие, чтобы прочуствовать разницу ...
По крайней мере тазик среднеофисной производительности может переварить 2-3к онлайна и быть загруженым меньше, чем на треть.

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


Название: Re: Проблема после пропадания питания
Отправлено: versus от 30 Января 2010, 12:28:19
Нуда, гдето я мельком видел чтобы базы под Solaris/SPARC работают куда шустрее на больших нагрузках.
Не зря таки Oracle купил Sun.
А уж вкусности ZFS...


Полгода опенсолярис был настольной системой, устраивало все, кроме возможности прикрутить ruby on rails для разработки приложений. Очень достойная система, хоть и не очень быстрая. После нее убунта кажется просто скоростной )) Вкусности ZFS действительно вкусные... Зоны действительно виртуализация, а чего только вирутальные сети стоят. Но требует конечно определенных усилий в освоении. Нен все команды работают так как кажестся на основе линукс/фря.

Ну а погибла солярка у меня в попытке скрестить бобра с ослом, т.е. героической попытке поднять рельсы на ней.


Название: Re: Проблема после пропадания питания
Отправлено: goletsa от 30 Января 2010, 19:15:59
Ну все равно солярка на x86 это костыль. Делалось только по сути для популизации ОС.
У мну тож гдето валяются официальные диски Solaris10\ Opensolaris разных выпусков.

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


Название: Re: Проблема после пропадания питания
Отправлено: blackjack от 03 Февраля 2010, 21:04:04
запустил кластер из двух стораджей и одного управляющего сервров

пока перекинул таблицы з трафиком в ндб

и сделал
Код:
--- /home/admin/50.32.3/nodeny/nodeny.pl	2010-01-25 13:44:00.000000000 +0200
+++ /usr/local/nodeny/nodeny.pl 2010-02-03 19:21:34.000000000 +0200
@@ -30,7 +30,7 @@
   `port` smallint(5) unsigned NOT NULL,
   `proto` smallint(5) unsigned NOT NULL,
   KEY `time` (`time`)
-) ENGINE=MyISAM;
+) ENGINE=NDB;
 SQL
 
 # Шаблон таблицы трафика
@@ -43,7 +43,7 @@
   `out` bigint(20) unsigned NOT NULL default '0',
   KEY `mid` (`mid`),
   KEY `time` (`time`)
-) ENGINE=MyISAM;
+) ENGINE=NDB;
 SQL
 
 # Шаблон таблицы информации о трафике
@@ -59,7 +59,7 @@
   `detail` tinyint(3) unsigned NOT NULL default '0',
   KEY `time` (`time`),
   KEY `mid` (`mid`)
-) ENGINE=MyISAM;
+) ENGINE=NDB;
 SQL
 
 # Шаблон таблицы суточного трафика
@@ -70,7 +70,7 @@
   `in` bigint(20) unsigned NOT NULL default '0',
   `out` bigint(20) unsigned NOT NULL default '0',
   KEY `mid` (`mid`)
-) ENGINE=MyISAM;
+) ENGINE=NDB;
 SQL
 
 $User_select_Tbl=<<SQL;
@@ -82,7 +82,7 @@
   `mid` int(10) unsigned NOT NULL default '0',
   PRIMARY KEY  (`id`),
   KEY `grp` (`grp`)
-) ENGINE=MyISAM AUTO_INCREMENT=1;
+) ENGINE=NDB AUTO_INCREMENT=1;
 SQL
 
 # условие, по которому считаем, что клиент во включенном состоянии: неблокируемая авторизация или `всегда онлайн`


посмотрим что получится, если пару дней сбоев не будет, будем идти дальше, пока поэкспериментирую на этих таблицах, если что и случится - немного потеряем.


Название: Re: Проблема после пропадания питания
Отправлено: blackjack от 04 Февраля 2010, 11:02:19
не создались таблицы в 0 часов, надо было рестартануть ядро, а я забыл


Название: Re: Проблема после пропадания питания
Отправлено: Elisium от 13 Марта 2010, 23:12:54
Апну старую тему.
Может я не вьезжаю, но.

Кто как делал связку gmirror + gjournal ?

1. Один винт. Заливается ось. Делается journal. Потом mirror на второй винт. (не пробовал вообщето)
2. Один винт. Заливается ось. mirror на второй винт. Потом делается journal на mirror разделы. (тоже не пробовал)
3. Один винт. Заливается ось. mirror на ЭТОТ винт. Потом делается journal на mirror разделы. Потом mirror на ВТОРОЙ винт (сделал так)

Вроде бы ниче сложного, но чегото задумался ...
Или это проблема на пустом месте ? (первый вариант не соберется?)

п.с. КАК протестить такую связку ?
Тупо жать сброс несколько раз на какой нить работающей базе ? ))

п.п.с. под вечер туго соображаю уже, а проверить такую интересную задумку хочется ..((


Да, вдогонку.
Пересобрал последнее ядро, получил 7.3 Пререлиз
Сразу после перезагрузки МНОГО процессов стали отваливаться с Segmentation fault 11.
Пришлось вернуться на 7.2-р7
Кто-нибуть сталкивался с подобным ?
Или нужно было еще пересобрать мир ? Хотя вроде делал бинарное обновление freebsd-update.