Добрый день,

у меня есть пара простеньких демонов на perl. Основная их задача - сбор статистики с оборудование и запись данных в БД. Есть несколько САР на perl.

Столкнулся с тем, что демоны и САР периодически дохнут при работе с БД. Превышение интервала ожидания, потеря конекта к БД, рестарт БД, ошибки в запросах,... приводят к смерти софтины.

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

В голову приходит - обернуть DBI своим классом и переназначить часть функционала DBI. Проверять адекватность коннекта, запускать функционал DBI в eval, анализировать коды ошибок, переконекчиваться, перезаливать данные в БД. После некоторого числа попыток или таймаута в несколько минут, тихо и мирно умирать, удаляя за собой pid файл, освобождая разделяемую память и закрывая коннекты ко всем БД.

Может уже кто-то написал такой модуль?

Подскажите пожалуйста.

Универсального модуля не писал, но по своему опыту и продолжая твою мысль, можно сделать некую обертку для реконнекта, в ней же проверять залилось все необходимое в базу(если нет - перезаливать), а как таковой обработки ошибок не делал, все сообщения об ошибках писал в лог, на всякий случай, лог вешал на ротацию.   

Ну я думаю так.
Делаем класс, который просто переназначает соответствующие методы класса DBI и делов-то.
Там нужно переписать connect, disconnect, prepare, execute, do, fetchrow_array
В основной же библиотеке просто мнеяем use DBI на use myDBI и создание объекта. Всего 4 строчки.

В своём модуле уже проверять состояние линка каждый раз при вызове родной функции DBI, реконектиться по необходимости, обрабатывать ошибки.

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

А дальше уже можно добавить доп. логику. Ввести несколько механизмов поведения.

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

Для важных update и insert ввести проверку на выполнение
Там где проверка затруднена или требует много ресурсов научить при ошибке выходить, закрывая за собой всё что надо. Как вариант, не делать exit, а посылать самому себе сигнал kill, что бы его перехватил соответствующий блок основной программы и вышел как полагается.

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

P.S. Вопрос только в том, не буду ли я изобретать велосипед. И будет ли мой велосипед достойнее тех, что уже сделаны.

Это сообщение отредактировал(а) Secandr - 25.2.2015, 10:41

если ты собираешься делать все это :


то потянет на велик.   

Все что тебе требуется, в принципе, хорошо уложиться в новую функцию без создания своего класса, ну максимум две функции, если еще кошерное логирование прикрутить. 

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

Добавлено через 53 секунды
Ну можешь и по своей логике идти, только смысл переписывать ряд функций из DBI, которые и так хорошо работают!   

Ну вот когда у тебя несколько десятков тысяч строк и вдруг надо поменять DBI в этом всём на что-то другое начинается веселье.

Откровенно лень переписывать пучу кода. Да и опасно. Код-то не ради кода написан, код управляет оборудованием, а отказ в работе оборудования очень неприятен для предприятия...

Проще написать скрипт, который заменит DBI на myDBI и тут же наступит счастье 

Ну а myDBI будет делать так



Это сообщение отредактировал(а) Secandr - 25.2.2015, 11:40

Если в огромном коде, глобальный хендл к бд везде вызывается напрямую, без инкапсуляций или каких-то иных функций-оберток, то myDBI - возможно и самое оптимальное решение!   

Ну там подход немного другой. БД обёрнута и работа большей части библиотеки идёт не с БД напрямую а с сущностями более конкретными, которые описывают рабочее тело. И 80% кода, работающего с БД, лежит в отдельном классе большой библиотеки.

Но есть и печаль. Часть нетипичной работы с БД ведётся напрямую из софта, вызывающего библиотеку, причём не через библиотеку, а напрямую через DBI.

В целом же, проще всё же вынести функционал работы с БД в отдельный класс и уже с ним работать и из основной библиотеки и из софта.

Попутно перетащив часть рутинных операций в этот класс.

P.S. С каждым годом переписывать код становится всё тяжелее 

Хотите, чтобы иногда ->fetchall_arrayref вызывался по три раза? Ну, сделайте обёртку вида fetchall_arrayref_hard(dbh, ..., 3).

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

Ну и, конечно -- сделайте, наконец, так, чтобы mysql не дох. Я дажэ не предлагаю перейти на postgres (хотя это, конечно, стоило бы сделать, но не по этой причине) -- но, знаете, почему-то у сотен тысяч человек mysql работает и не дохнет.

Приношу извинения что не про перл, но почему бы в данном случае не воспользоваться mysql-proxy?

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

По поводу "что бы mySQL не дох" могу сказать следующее. Проект управляет сетью размером в 3 города, не считая мелких узлов по области и в столице. Есть несколько серверных ферм. Есть исторически сложившаяся инфраструктура: системы учёта сети, система электронного документооборота, системы мониторинга, технического аудита,... Каждая из систем работает со своей БД. Это и mySQL и postgresql и mssql и тот же битрикс на файликах.

Мой софт работает с этим со всем, собирает данные, анализирует это всё и по заданному шаблону применяет настройки к железу.

Задача - добиться стабильной и предсказуемой работы софта в аварийные периоды. С одной стороны - обеспечить адекватность при потере большей части инфраструктуры. В этом случае лучше умереть и ничего не делать. С другой стороны обеспечить надёжность при мелких авариях. Софт должен подождать спада пиковой нагрузки на сервере БД или спокойно перенести его перезагрузку. Иначе будет большой лаг от желания изменить настройки оборудования до их применения.

Сумасшедший, в свете вышеперечисленого mysql-proxy - дополнительная точка отказа. Мы сейчас кластеры стали делать из mysql и postgresql во избежание.

https://metacpan.org/pod/DBD::mysql#mysql_auto_reconnect
Ну а ошибки обрабатывать естественно надо. Я обычно устанавливаю RaiseError =>1, PrintError => 0 и ловлю ошибки через eval.

Натыкался в документации на такое, попробую на днях.

Не успел ничего путного сделать за неделю.
Добавил 

Не помогло.
Теперь вылетает без ошибок :(

простенький пример из жизни:



Т.е. суть работы - обернуть обращение к бд в один метод и вызывать его из всех своих скриптов. А в самом методе проверять подключение, делать реконнект и пр.

noize, пока всё проще. Я забыл в продакшен выложить скрипты с изменениями 

я предпочитаю с подобными делами(база, кеш) всегда работать через методы. Так у вас всегда имеется единственная точка входа и если надо поменять логику работы с базой, то достаточно изменить только один метод и всё заработает.

noize я начал этот проект 7 лет назад со скриптов на bash, лет 6 назад перешёл на перл, лет 5 назад переписал всё в функциональном стиле. 3 года назад перешёл на ООП. Полтора года назад провёл рефакторинг бибилиотеки, поскольку не совсем понял парадигму ООП с первого раза.

Если бы я был программистом, было бы проще 

А не

?

А где ты здесь увидел программистов??   

Лично я сколько не пытался писать проекты в ООП стиле - честно говоря, ничем хорошим это так и не заканчивалось!   

P.S. хотя я кстати-таки дипломированный программист!   

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

Вот только отсутствие опыта иногда сильно затрудняет разработку.



Pfailed, noize, спасибо, будут допиливать SQL.

Кстати, трое суток, полёт нормальный, похоже просто по таймауту дох коннект.

Сделал так:



Заменил в основном коде DBI на noDB. Убрал do и execute.

В продакшен пока выкладывать не буду.

Это сообщение отредактировал(а) Secandr - 13.3.2015, 16:58

Да, там нужно условие '&&' вместо '||', пардон. Написал в спешке)

Добавлено через 8 минут и 49 секунд
Secandr, советую используйте прагмы 'strict' и 'warnings' везде, где это возможно.
Это позвлит кардинально сократить количество возможных ошибок.

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

noize, а разве use не наследуются через "use base qw(noNull);" ?

У нас с программистами всё гораздо проще. Они на perl не пишут. Я по своему софту делаю ТЗ, сдаю им на разработку, свой софт по окончанию разработки уьиваю.
А сам пишу софт только в том случае, когда быстрее написать софт, чем ТЗ.

Secandr, strict и warnings не наследуются, они включают своё действие только в области где были заuseны

Добавлено через 2 минуты и 55 секунд
Либо в noNull надо создать метод import и в нём сделать вот так https://metacpan.org/source/SRI/Mojolicious...ojo/Base.pm#L42
Тогда и в noDB будут действовать strict и warnings.

Pfailed, Спасибо. А я-то думал, что наследуются...

Скучные у вас какие-то программисты...   

Bulat, инженеры у нас обычно знают 1-2 языка программирования и пишут на чём умеют. Я в том числе пишу на perl, просто потому что его выучил ещё 10 лет назад.

А программисты используют тот язык который будет удобнее для проекта. И обычно это что-то с хорошим ООП: Java, фреймворки php, C#. Да и проекты программистов несколько отличаются от поделок инженеров масштабами.

Ну и есть замечательное разделение софта. Программисты не лезут в недософт инженеров, а инженеры не лезут в софт программистов. Если недософт инженеры не успевают поддерживать, его переписывают программисты.

Я только в страшном сне могу представить систему управления предприятием написанную на perl или биллинг, к примеру 

Так что да. У нас скучные программисты 


По теме топика: неделя прошла - полёт нормальный.
Видимо mySQL скидывал демона по timeout`у. Демон засыпает на несколько секунд, если нет работы, что бы не отъедать load на стареньком сервере.

Я вполне видел биллинг на perl. Ну, большынство поделок на C# и Delphi -- хужэ.

Secandr, это уже холивар и оффтоп, поэтому лучше не оффтопить! Скажу в завершении - если вы чего-то не умеете, то это не повод говорить - кошмар, в страшном сне, а хороший повод расти дальше!   


А я не то, что видел, но еще и дописывал новые модули для новых сервисов!   Дабы не нарушать общую архитектуру!   

Пол дня потратил на то что бы скрипт запустился после 'strict'. Была пара мест забавных, где стояли просто символы, видимо нечаянно введённые при скролле. Было пару грубых ошибок в бизнеслогике. Поражаюсь как оно вообще работало 

Правда теперь на одно моё сообщение в логах десяток от 'warnings' :(


Bulat, я сам snmpd переписывал на перл. Работает гораздо шустрее родного, порядка на 2. И биллинг видел на perl, самолично интегрировал такой.

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

И тут уже выясняется, что быстрее дешевле и надёжнее купить коробку с биллингом или взять open source решение и допилить силами средненького админа или интегратора.

Это сообщение отредактировал(а) Secandr - 17.3.2015, 16:47

Думаю, меньшэ чем если писать на питоне или php.



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



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

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

Вот, кстати, ещё один интересный момент. Уже в другом софте пригодилось сделать вот так:



Перехватил и сохранил warning;
Перехватил die и отправил на почту все сообщения warning, die и дамп важных переменных.
Перехватил все сигналы, какие знаю, и так же выслал отладочную информацию на почту.

Особенно интересно смотреть почему сдохли дети порождённые в eval.
eval избавил меня от подыхания всего софта, но перехватить причину гибели потомка я не смог. А парсить многотонные логи ежедневно очень тоскливо...

Нашёл ещё несколько забавных ошибок таким способом...

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

Вот.

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

Это сообщение отредактировал(а) Secandr - 24.3.2015, 16:59