Стабильность нового СТГ

[vop 370]

Похоже у меня склероз. А можно поподробнее про гаранитрованную запись в файл. Больно интересный вопрос...

Если не ошибаюсь, это было где-то в 2002 году. Я тогда много своих соображений тебе высказывал. В том числе и по переводу авторизатора с tcp протокола на udp, или, например, из критичных на мой взгляд вопросов - переход на целочисленную арифметику и накопительный подсчет данных. В общем, много тогда говорили - возможно что и забылось уже.

 

Давай лучше к данному вопросу, который мучает умы уже много времени. Правила гарантированного сохранения данных при работе с файлами очень простые. Есть несколько разных вариантов. Это конечно правильно ты мыслишь с разными bak-файлами, но не совсем правильно (с моей точки зрения, как минимум).

 

Вот смотри в чем проблема - в определенных случаях возникает ситуация, когда сервер прекращает работу в тот момент, когда файл stat имеет нулевую длинну. Т.е. если кильнуть сервер, нажать резет и т.д. - то возникают такие неприятности, что какой(-ие)-нибудь файлы stat на этот момент имеют длинну 0. Что надо добиться? Надо добиться, что бы файл stat никогда не был нулевой длинны. Никогда, ни секундочку, как говорится, ни единый "машинный такт".

 

Для этого есть очень простые правила, которыми пользуются программеры разного софта. Будь то cron при перезаписи таблицы, будь то rsync или vi, или практически любые другие программы, работающие с данными. Вот они в моем изложении:

 

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

2. Для обновления файла с данными используется единственная функция, которая (как говорят в умных книжках) имеет гарантию неисчезающего существования файла - т.е. система обязаны выполнить функцию "за один системный цикл" без прерывания и т.д. (о, как умничаю ) Я говорю о функции rename();

 

Т.е. исходя из этих двух правил мы имеем очень простой алгоритм изменения данных в файле.

1. Создаем временный файл (текстовые редакторы, обычно, созадют файлы с раширением .bak). Мы можем делать какой-нибудь tmp, с номером pid, например. Основной файл с данными цел.

2. Записываем во временный файл обновленные данные, при этом считаем, сколько записали байт. Получаем копию нашего будушего файла с данными. Основной файла цел.

3. Закрываем файл и проверяем его размер, сравнивая с количеством записанных байт (что бы не наткнуться, например, на диск-квоту, которая не всегда кричит, что место закончилось). Основной файл цел.

4. Если все нормально - и файл есть, и размер нормальный - просто делаем rename из временного в основной. При этом, новый файл заменыет старый, и нет не единого момента, когда файл с данными отсутствует, или обнулен.

 

Прошу прощения, если много слов написал. Но у меня такое впечатление, что я когда-то тут или на наге об этом уже писал, и даже кусок кода для примера приводил. Ну да ладно, мне не жалко. Потому-как потеря данных в программе - это вообще никуда не годится, и это дело надо исправлять, как можно скорее.

 

P.S. И не говорите, что поменяв файловую базу на базу SQL можно избавиться от этой проблемы. С SQL можно так наворотить, что проблема с файлом stat покажется вообще детской

[stg-34 0]

При этом, новый файл заменыет старый, и нет не единого момента, когда файл с данными отсутствует, или обнулен.

Есть, есть. Это операция не на один такт, может эта операция и уменьшает вероятность обнуления, но можно попасть на момент, когда старый (перезаписываемый) файл удален, а операция переименования нового не завершена. Короче та же фигня только сбоку. В общем, если бы можно было выполнить эти операции как одну транзакцию, то да, но, к сожалению это не так.

 

На самом деле спасает журналируемая ФС, или варианты журнлирования "руками", как сделано у меня

[Lambert 5]

На самом деле спасает журналируемая ФС, или варианты журнлирования "руками", как сделано у меня

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

Как думаешь?

[vop 370]

Есть, есть. Это операция не на один такт, может эта операция и уменьшает вероятность обнуления, но можно попасть на момент, когда старый (перезаписываемый) файл удален, а операция переименования нового не завершена. Короче та же фигня только сбоку. В общем, если бы можно было выполнить эти операции как одну транзакцию, то да, но, к сожалению это не так.

 

If the rename() function fails for any reason other than [EIO], any file named by new shall be unaffected.

 

Перевожу на русский толковый - что бы ни случилось (кроме физической поломки винта), любой из двух файлов (старый или новый) должен остаться на новом месте, причем, остаться целкой. Так-что нет никакого момента "когда старый удален" и так далее. Это ГАРАНТИЯ функции rename() по стандарту POSIX, который требует атомарной реализации этой функции Она не уменьшает вероятность пропажи файла, а ИСКЛЮЧАЕТ вообще их пропажу.

 

На самом деле спасает журналируемая ФС, или варианты журнлирования "руками", как сделано у меня

 

Ой, сомневаюсь, что тебе поможет журналируемая fs. Мало того, что не поставят все любители старгейзера себе журнальную fs, так с ней тоже работать надо уметь правильно :)

[Kucher2 122]

Да простит меня автор программы, но собеседник ваш - дело говорит.

Возможно vop не прав в деталях, но он прав в сути: система должна быть устойчивой к такого рода сбоям. Если этого нельзя сделать, опираясь на какие-то стандартные приёмы работы с данными, значит нужно хотя бы поспособствовать тому, чтобы администраторы не ломали себе голову, пытаясь сохранить работоспособность биллинга и рисуя всякие там скрипты, а так же запихивая базы в mysql (не могу не согласиться с vop, что в общем-то это неправильно - похоже на то, если бы у вас сломался холодильник и чтобы спасти продукты в нём - вы покупаете новый большой холодильник, чтобы засунуть внутрь старый).

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

Я всегда был и остаюсь сторонником простоты использования. Именно поэтому мне нравится СТГ. Даже какое-то чувство патриотизма за отечественных программистов.

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

[stg-34 0]

.........

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

.........

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

.........

Я, в целом, согласен, как подтверждение этого, в стг было добавлено создание bak-файлов. И как было написано пару постов выше повышает надежность.

 

Почему у тебя не появляются баки, не скажу, надо смотреть, мне кажется или

1. у тебя старая версия, которая не поддерживает этот функционал

2. ты куда-то не туда прописал в конфиге эти опции.

 

ПС: UPS, RAID и журналируемые ФС полезные штуки

[stg-34 0]

If the rename() function fails for any reason other than [EIO], any file named by new shall be unaffected.

 

Перевожу на русский толковый - что бы ни случилось (кроме физической поломки винта), любой из двух файлов (старый или новый) должен остаться на новом месте, причем, остаться целкой. Так-что нет никакого момента "когда старый удален" и так далее. Это ГАРАНТИЯ функции rename() по стандарту POSIX, который требует атомарной реализации этой функции Она не уменьшает вероятность пропажи файла, а ИСКЛЮЧАЕТ вообще их пропажу.

 

На самом деле спасает журналируемая ФС, или варианты журнлирования "руками", как сделано у меня

 

Ой, сомневаюсь, что тебе поможет журналируемая fs. Мало того, что не поставят все любители старгейзера себе журнальную fs, так с ней тоже работать надо уметь правильно :)

Не, это просто умиляет

Перечитай тему о чем мы говорим. Если нет времени, то могу сообщить: мы говорим о сохранении целостности данных при физическом сбое оборудования. Например выключении питания или нажатии кнопки ресет. А ты рассказываешь как гарантировано переписать файл в отсутсвие физичесих сбоев. Спасибо, но в остутисвии физических сбоев переписать гарантированно файл и дурак сможет.

 

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

 

По поводу журналироемой ФС. Очень рекомендую прочитать что такое журналируемая ФС

 

В кратце, именно журналируемая фс гарантирует прохождение операции до конца. На пальцах переименование выглядит так:

1. поставить пометку, что мы начали переименовывать такой-то файл

2. переименовать

3. поставить отметку, что транзакция прошла успешно.

 

Так вот, если в средине этой операции произойдет сбой, то пометки об успешном завершении не будет, и система откатится в предыдущее состояние.

 

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

[Watson 0]

При тестировании последней версии старгайзера заметил что неправильно считает трафик тоесть увеличивает в 2 раза.Загрузки делал с разных ресурсов.Рулесы взяты с рабочего сервера 2.0.16 на котором трафик считается правильно.У кого то были такие прооблемы или это только у меня.Сервер на файлах.Alt linux 4.0 server.

[madf 279]

Мы просто пытаемся общими усилиями добиться нормальной работы СТГ.

 

Возвращаясь к теме - обновил СТГ до последней версии (stg-2.4-2007.06.26-14.14.41) с сайта local.com.ua, Строки

 

RemoveBak=no

ReadBak=yes

 

в конфиг СТГ дописал, сбросил сервер. По прежнему не вижу bak-файлов после перезагрузки и СТГ лежит. Где грабли? :/

1. Баки могут не появится. Потому что записи статистики еще небыло. Она происходит с определенным периодом для всех юзеров одновременно.

2. Почему при этом портятся файлы - пока сказать трудно.

3. mv stat stat.bak ничем не отличается от mv temp.stat stat. mv - операция не атомарная и атомарной быть не может - она выполняется за много тактов работы процессора. Журналируемая ФС поддерживает целостность на уровне транзакций: или операция с файлом завершится до конца (commit) или она совсем не начнется (rollback). "Ручная" реализация гарантированной записи невозможна. Скорость вращения диска в приводе, движения головки, изменения напряженности магнитного поля - величины большие, но конечные. Если отсечка питания происходит в момент позиционирования головки в середине записи файла (например, при фрагментации или переходе из кластера в кластер) файл не может быть записан до конца.

[stg-34 0]

"Ручная" реализация гарантированной записи невозможна.

Не согласен.

 

1. ставим флаг начала операции (создаем bak), и одновременно запоминаем предыдущее состояние

2. переисываем файл

3. удаляем флаг, тем самым подтверждая, что операция прошла успешно.

 

Если сбой происходит в п.1 файл остается не затронутым

Если сбой происходит в п.2, у нас нет отметки о завершении операции, востанавливаем по данным сохраненным в п.1

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

 

Т.е. я не вижу как в данной схеме можно получить поломанные данные.

[vop 370]

2. Почему при этом портятся файлы - пока сказать трудно.

 

Возможно, тебе сказать трудно. Я Борису об этом 5 лет назад говорил. Тогда еще не было файлов stat в базе старгейзера. Но опасность исчезновения данных уже были заложены заранее не совсем разумной работой с данными.

 

mv - операция не атомарная и атомарной быть не может

 

В общем, на этом и закончим. При чем тут mv - не знаю.

[stg-34 0]

mv - это переименование файлов. вообще-то...

Понимаешь, ценность таких советов нулевая. Какой смысл давать совет использовать операцию, которая гарантированно работает в отсутсвии физ. сбоев, если мы обсуждаем физ. сбои?

 

Сорри, если обидел.

[stg-34 0]

Возможно, тебе сказать трудно. Я Борису об этом 5 лет назад говорил. Тогда еще не было файлов stat в базе старгейзера. Но опасность исчезновения данных уже были заложены заранее не совсем разумной работой с данными.

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

Могу архивы поднять

[vop 370]

2. переисываем файл

Вот этого делать нельзя!!! Нельзя переписывать файл по живому. Вообще, нельзя открывать ни один рабочий файл на запись. Хоть кто-нибудь читал, что я там накарябал?

 

Новый файл создается отдельно. На момент выполнения rename уже никто никуда не переписывается и не двигается. Одной операцией запмисывается указатель на новый массив данных.

[stg-34 0]

Вот этого делать нельзя!!! Нельзя переписывать файл по живому. Вообще, нельзя открывать ни один рабочий файл на запись. Хоть кто-нибудь читал, что я там накарябал?

Ну, ёперный балет.

 

Да как же еще объяснить, что переименование и перезапись, в данном контексте, не имеют принципиальных различий. Не то, не то не является атомарной операцией.

[vop 370]

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

Могу архивы поднять

С рождения у тебя на каждую величину были отдельные файлики - ip, cash, pswd, на каждый счетчик и т.д. И для каждого счетчика тоже были отдельные файлы. Вот так и получалось, что при инициализации каждого клиента, старгейзер читал по 15 файлов.

 

Вот из моего старого конвертора. loadd - это типа трафик по Днепру Тут не все файлы, а только те, которые нужны были для сбора статистики на верхний уровень.

 

#define BILLI_FILE_IP    BILLI_HOME_DIR"/%s/ip"
#define BILLI_FILE_LOADI BILLI_HOME_DIR"/%s/loadi"
#define BILLI_FILE_LOADD BILLI_HOME_DIR"/%s/loadd"
#define BILLI_FILE_LOADE BILLI_HOME_DIR"/%s/loade"
#define BILLI_FILE_PLAN  BILLI_HOME_DIR"/%s/plan"
#define BILLI_FILE_CASH  BILLI_HOME_DIR"/%s/currcash"
#define BILLI_FILE_PSWD  BILLI_HOME_DIR"/%s/pswd"

[stg-34 0]

Ты где траву берешь?

 

Я не знаю что ты за конвертер писал, на каждую величину никогда не было отдельно файла

 

Или ты мне щас начнешь доказывать старый бред про лайнком?

[vop 370]

Да как же еще объяснить, что переименование и перезапись, в данном контексте, не имеют принципиальных различий. Не то, не то не является атомарной операцией.

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

 

The rename function is specified in the stdio.h library header file in C and the cstdio header in C++. It is specified in ANSI C.

In POSIX, rename will fail (with EXDEV) if the old and new names are on different mounted file systems. On Linux, if a call to rename succeeds it is [b]guaranteed to have been atomic[/b] from the point of view of the current host.

 

Причем чуть ранее я привел тебе цитату из документа, озаглавленного селдующим образом:

 

The Open Group Base Specifications Issue 6
IEEE Std 1003.1, 2004 Edition
Copyright © 2001-2004 The IEEE and The Open Group, All Rights reserved.

 

А как утверждают источники...

 

POSIX (IPA: /ˈpɒsɪks/) or "Portable Operating System Interface"[1] is the collective name of a family of related standards specified by the IEEE to define the application programming interface (API) for software compatible with variants of the Unix operating system. Originally, the name stood for IEEE Std 1003.1-1988, which as the name suggests, was released in 1988. 

 

Т.е. я тебе привел цитату из оригинального требования POSIX, а вовсе не свое мнение или предположение. Так-что я немного потерялся, о чем дальше говорить?

[stg-34 0]

Да, говорить дальше просто не о чем. Цитаты, то ты привел, но видимо их смысл для тебя не ясен. Ты нигде не сказал, что происходит когда в средине выполнения операции гаснет свет.

 

Я задал простой вопрос. Из чего следует, что перезапись атомарная? Ответа нет. Разговор зашел в тупик.

[vop 370]

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

[Kucher2 122]

Боже мой, люди - не спорьте, я уже навалял скрипт - всё работает на ура!

Вероятность падения базы правда есть всё равно, но в десятки раз меньшая. И хрен с ней.

Когда-нибудь истина будет найдена. И прав будет тот, кто её найдет и реализует.

[stg-34 0]

аминь