?

Log in

No account? Create an account

Заповедник репрессивной психиатрии

Entries by category: происшествия

Репликация таблицы БД с помощью очередей
metaclass
Я тут, как обычно, подумываю, как бы заменить прямое обращение к БД из сервисов на хождение мессаг по очередям и посетила меня такая мысль: можно ли с помощью очереди, гарантирующей доставку "один раз или больше" реплицировать одну таблицу в БД, если у нее есть естественный ключ?

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

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

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

Обычно я делаю распределенную транзакцию с двухфазной фиксацией с двумя БД и передаю данные лога транзакций и изменений между БД, пока оно работает как положено, за исключением того, что это прибивает гвоздями решение к протоколу Firebird, в котором эти распределенные транзакции предусмотрены и, например, убрать прямое обращение к БД и гонять данные по http(s) между сервисами не получается. Было бы интересно, опять же, рассмотреть вариант репликации данных между разными СУБД.

Безумный день
metaclass
Все утро провел на совещании по поводу интеграции с SAP R/3.
Вечером чинил утечку памяти в udf для Firebird.
В процессе диагностики этой же утечки опять сдуру открыл у клиента на 2012 винде стек 32-битного процесса в Process Explorer, тем самым навернув в красный экран смерти этот несчастный сервер, после чего пришлось призывать Chief Reboot Officer для восстановления работоспособности.

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

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

Собрался проверить проблему с Process Explorer на виртуалке, потом обратил внимание, что у меня на рабочем ноуте Thunderbird жрет 100% проца и 3 гига памяти, и полез в него Process Explorer посмотреть "что жрет". 8 винда, x64, тот же просмотр стека - экран смерти винды, точно такой же. Второй раз в день(!), слава богу не на продакшене уже.

http://forum.sysinternals.com/bugcheck-in-process-explorer_topic28949.html

Назойливость, как ключевая бизнес-практика в России
metaclass
Originally posted by alexdjachenko at Назойливость, как ключевая бизнес-практика в России
Подавляющее большинство людей и компаний, с которыми Вы столкнётесь в России, как двухглавые орлы: птицы гордые, но бессмысленные и без смачного пендаля будут только задумчиво кивать, переминаясь с ноги на ногу и гадить.

Ваш подчиненный принял задачу? Коллега обещал посмотреть документ к четвергу? Поставщик - привезти товар в среду?
И Вы им поверили?
Ха! Сюрприз отечественного бизнеса - ни к указанной дате, ни через неделю, ни через месяц ничего сделано не будет. Вообще ничего! Даже не начнут! Даже не вспомнят.

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

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

Встречи
Назначенная встреча не состоится, если сразу после договорённости о ней, вы не отправите всем участникам письмо со временем и местом. Еще одно - в понедельник утром той недели, на который запланирована встреча. В конце предыдущего дня необходимо обзвонить всех участников встречи и поинтересоваться, в силе ли договоренность. Еще раз - за 3 часа до встречи. Ну и за 5 минут до начала встречи необходимо позвонить всем, кого еще нет в условленном месте.

Доставки
Если у вас приняли заказ, это не значит, что его собираются доставить. И уж совсем не значит, что его собираются доставить в назначенный срок. Чтобы увеличить вероятность этого, необходимо напомнить звонком трижды: один раз - когда формируются маршруты на день доставки. Один раз - в самом начале дня доставки, когда еще не поздно вписать в маршрутный лист ваш адрес, который забыли вписать вчера, ну и еще раз звоните в конце интервала времени, когда вам обещали доставку и никто не приехал.

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

Партнеры и клиенты
Я Вам сочувствую, правда, мне Вас искренне жаль, очень очень. Потому что если у вас нет под рукой вентиля, перекрывающего нужному человеку кислород, или кнопки активации штырей в сиденье его стула - ситуация почти безнадёжна.
Ругаться в этом случае никак нельзя, звоните на пределе вежливости. Описывайте, как вам плохо от того, что вы еще не получили никакого ответа, как Вас ругает ваш руководитель/клиенты/поставщики, какие кары Вам грозят. Вашему контрагенту это всё абсолютно неинтересно, поэтому рассказывайте как можно дольше и подробнее.
Всеми правдами или неправдами просите назвать дату. Если дату не назвали - звоните не реже раза в день. Старайтесь беседовать как можно дольше, спрашивайте, чем можете помочь, живопишите новости совместного проекта. Контрагенту должно быть быстрее и проще один раз выполнить требуемое, чем ежедневно с Вами беседовать. Главное - не бойтесь надоесть, если ТАКОЙ контрагент предпочтет отказаться от дальнейшего сотрудничества - он этим окажет Вам услугу.


А штыри в стуле были бы решением!

scala spray slick restful ад заборы коровники коворкинги хипстеры
metaclass
В целях недопущения упрощения жизни, а так же чтобы псить, при необходимости, со знанием дела, осиливаю скалу.
Причем начал практически с конца - клепаю RESTful сервис на основе spray с всякими json-маршалингами внутри через имплициты и прочую адову содомию.
При достаточном количестве type-level магии оно выглядит, конечно, так же просто, как какое-нибудь руби, или как лиспы без скобок и с инфиксной записью, но внутренняя сложность, по-моему, зашкаливает. "Импортируй себе немножечко имплиситов и получи на халяву сериализаторы в json для всего", "Оберни маршруты в директивы логгера" и прочее такое.

Сборку завел, сначала через sbt (простой способ), потом импортировал в IDEA (условно простой) и потом стырил у jdevelop конфигурацию для мавена (нормальный способ). Воедино надо это как-то свести, чтобы не редактировать при добавлении новых зависимостей все вручную. Плюс еще импорт sbt в IDEA выглядит как ад и смерть.

Завести то я это чюдо заведу, но вот что с ним дальше делать, не совсем понятно. На данный момент картина выглядит так: Clojure проще, но скобки и стектрейсы компилятора отпугнут новых пользователей, Scala дико сложнее, но поначалу она выглядит как "почти жаба", обработка ошибок более читабельна и есть шансы, что в эту западню попадутся и желающие новеньких языков и любители сойти с ума на почве вычислений на типах.
Tags: ,

Свежая смерть домосетям
metaclass
стр. 1
стр. 2

Вот же черви в госструктурах посели - сразу все выкладывают в инет.

(no subject)
metaclass
В районе 5 часов в русском ЖЖ начинается какое-то мертвое время. С работы ушли, домой не дошли - мало кто пишет.