У liquibase есть неприятный баг: иногда при рестарте приложения оно может просто ничего не делать. Происходит это из-за того, что liquibase при применении своих изменений выставляет лок. И если приложение падает во время этого процесса, то этот лок никто не снимет, и перезапущенное приложение будет ждать его освобождения вечно. Эдакий deadlock с самим собой.

Решается симптом проблемы очень просто — удалением лока:

UPDATE DATABASECHANGELOGLOCK SET LOCKED=FALSE, LOCKGRANTED=null, LOCKEDBY=null where ID=1;

Мораль сей басни очевидна: вечные локи до добра не доводят.

P.S. “Обожаю” мажорные баги, которые могут не править больше 5 лет (а судя по SO, существует этот баг уже лет 7 минимум).

Как переиндексировать документы, например из-за смены типа поля, желательно “на живую”? На мой взгляд, неплохой вариант выглядит примерно так:

1. Создать новый индекс, переиндексировать туда данные по запросу “все, что было проиндексировано раньше текущего времени”.
2. За время переиндексации появятся новые документы — можно повторить эту процедуру, сокращая “лаг” до приемлемого количества. Обычно 2-3 подходов хватает, но это легко автоматизируется.
3. Переключаем альяс со старого индекса на новый.
4. Делаем еще одну итерацию по переиндексации, чтобы переиндексировать оставшиеся документы из старого индекса.
5. Удалить старый индекс.

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

Но что делать, если в индексе нет даты индексации? И никакого поля, которое можно было бы использовать таким образом? Есть альтернативный подход:

1. Создать новый индекс.
2. Переключить на него альяс для записи — все новые документы попадают теперь туда.
3. Сделать реиндекс. Поскольку в старый индекс уже ничего не пишется, никаких запросов не нужно, все делается за 1 раз.
4. Переключить альяс для чтения на новый индекс.
5. Удалить старый индекс.

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

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

Годная статья про всякие штуки в СУБД, о которых обычно не задумаешься, а стоило бы.

Things I Wished More Developers Knew About Databases

Не все понимают, что означает этот флаг в эластике: довольно много тикетов в гите эластика на то, что получен false на успешно выполненную операцию.

Если вкратце — "acknowledged": true означает, что операция применилась ко всем нодам, то есть кластер в синхронизированном состоянии после выполнении операции.

Если false — значит не все шарды успели выполнить операцию в пределах отведенного таймаута. Но это не означает, что операция не была выполнена совсем или что выполнена частично: просто не все ноды успели отрапортовать, смогли ли ее выполнить или нет.

Think of “acknowledged” = true as an equivalent to “not_timed_out” = true.

При обновлении системы может случиться такое, что systemd не видит новых изменений (новые динамические библиотеки, например). Семь бед — один ресет, рестартнуть systemd можно через systemctl daemon-reexec.

Но самое важное — это конечно догадаться, в чем дело.

В продолжение темы поведения СУБД в нестандартных ситуациях — исследовательский проект по тестированию уровней изоляции в базах данных. На практике применить эти знания тяжеловато, но если это станет нужно, то хотя бы будет откуда начать.

Статья-справочник по способам организации веток в коде.

Читать целиком за раз ее вряд ли стоит, для просвещения я рекомендую ознакомится с разделом Looking at some branching policies и заключением, а потом уже углубиться, если в чем-то не разобрались.

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

Подробнейшая статья про технологии вызова нативных библиотек в Java: JNI, JNR и про то, что нас ждет в будущем — Project Panama: https://habr.com/ru/company/leader-id/blog/505072/

Я надеюсь, что доказывать пользу атомарных коммитов не нужно. Можно почитать немного про это, а заодно про сообщение коммита в wiki OpenStack.

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

Если у вас есть большая пачка изменений с рефакторингами и изменениями в бизнес-логике вперемешку, то разбить ее на атомарные коммиты поможет частичный коммит. Ну и stash/shelve, но про них как-нибудь в другой раз.

В mercurial для этого есть просто великолепный интерактивный режим (hg commit -i), который раньше был расширением Crecord. В Intellij поддержки частичного коммита нет, но есть тикет. Шансы на то, что его исправят близки к нулю — “кто же использует mercurial в 2020?”, считает большая часть индустрии.

В git для этого есть механизм patch (git add -p <filename>), который работает, мягко говоря, отвратительно. Там даже нельзя выбрать отдельную строчку. Stage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? звучит особенно по гитовски — миллион опций, запомнить которые невозможно. В Intellij уже два года как есть поддержка частичного коммита, который является надстройкой над этим механизмом, и закоммитить отдельные строчки через нее тоже пока нельзя.

Но не стоит унывать, потому что для git тоже есть расширение Crecord. sudo apt-get install git-crecord, и после этого доступна команда git crecord, которая окунет вас в такой же отличный интерактивный режим, как и в mercurial.

Про хорошие СУБД обычно думаешь как о сервисе, не вдаваясь в подробности, как они работают. До тех пор, пока не случится какая-нибудь фигня.

Jepsen — это классный проект, направленный на проверку поведения распределенных систем (баз данных, шин данных и т.п.) в нештатных ситуациях вроде потери пакетов или split-brain. Фактически Aphyr ломает системы, создавая внешние условия, в которых нарушается консистентность. К сожалению, готовых анализов не так много. Про какой-нибудь Elasticsearch там всего лишь статья 2015 года про древнюю версию 1.5.0. Однако в блоге достаточно высокий технический уровень и детальность проработки, и из него можно почерпнуть много знаний про внутренние механизмы работы и типовые проблемы распределенных систем.

Кстати, недавно на HN наделала шуму статья про то, что несмотря на попытки Mongo улучшить работу с транзакционностью, консистентностью и всем таким, у нее все еще есть проблемы.