Открыть список
Как стать автором
Обновить

Комментарии 22

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

Откуда такая информация?
Это пишет сам Atlassian. И у меня есть опыт падений H2. Причем она падает так, что восстановить можно только из бэкапа.
Статья, достойная поста в личном бложике.
То, что можно загуглить в официальной базе знаний или на SO — очевидно, не самая подходящая тема для статьи, в том числе по объёму.
Загуглить можно практически все. Я столкнулся с тем, что многие не знают, что есть H2 manager в установленных Jira и Confluence. Да, это написано. Но это не означает, что все это знают. Я хотел это подсветить.
Вы пишете, что не предполагаете использование в продакшене. Тогда где и зачем, позвольте поинтересоваться? Для личных нужд или проекта выходного дня? — смотрите комментарий про личный бложек.

Любая продукционная инсталляция джиры/конфлюенса, если местный сисадмин не совсем наркоман, будет использоваться с нормальной СУБД.
Я написал — при миграциях. Когда делаешь миграции, то не предполагается работа более одного пользователя на временном инстансе, который нужен для того, чтобы исправить ошибки или внести некоторые корректировки для того, чтобы миграция прошла успешно.
Извините, я всё равно не очень понимаю. Внутри моей головы миграция может быть чего-то, уже работающего — и в случае джиры, если это что-то представляет собой важную часть процессов предприятия, то оно работает на нормальном железе, стабильной ОС и СУБД, регулярно бэкапится и т. д. И ничего из этого ни при миграции, ни при обновлении версии не меняется. И простора для внезапного появления откуда-то «изкоробочной» Н2 я тут не вижу.
Хорошо. Как Вы будете делать миграцию двух Jira Server на новый сервер (Вам нужно сначала сделать тестовую миграцию)? Или нужно мигрировать данные из Jira Server в уже существующий Jira Cloud?
А проблема-то в чём? Да, это довольно геморройная задача, но вполне решаемая и задокументированная в KB. До сих пор не вижу, зачем при этом менять нормальную СУБД на что-то другое.
Нет никаких проблем. Просто я это делаю через atlassian sdk. Поднимаю инстанс любой версии и дальше устанавливаю туда бэкап. Это занимает минуты.
Можно, конечно, иметь докеры с постгрес и джирой. Их поднимать. Но это требует гораздо больше ресурсов и знаний для подготовки таких докеров, нежели использовать поднятие инстанса из SDK и дальше все делать. А мне кажется, что свое время нужно экономить и решать задачи эффективно. В данном случае postgres не нужен, это лишнее.
И часто, позвольте поинтересоваться, у вас происходит слияние нескольких джир или другие операции, требующие восстановления из бэкапа? И если часто — почему вы не в курсе админского пароля? :)
Да, я этим постоянно занимаюсь. И не спрашиваю пароли админов у клиентов. Мне это не нужно и им спится спокойнее.
Все как правило начинают со встроенной бд и это проблема при переходе на прод, если продукт хотят купить. Потом эти вопросы идут в саппорт
Я, видимо, какой-то очень упоротый фанат постгреса и внедрения атлассиановских продуктов, раз даже при демонстрации сразу поставил это на нормально настроенную базу — чтобы у пользователей не возникло подсознательного ощущения, что это ПО подтормажвает, даже будучи ещё не нагруженным.
В документации есть правильное решение по смене пароля администратора. Для этого в строку запуска JIRA нужно добавить ключик запуска в однопользовательском режиме. Запускаете, меняете пароль, останавливаете, убираете ключ и запустеете снова.
И как правильно выше написали Вам: в продакшене НЕЛЬЗЯ использовать базу H2! Неужели трудно поставить PostgreSQL или на крайний случай MySQL. В любом дистрибутиве Linux они есть.
Потому что доверия к H2 нет! Это СУБД живет в памяти. В различных исключительных ситуациях данные из памяти теряются не сохраняясь на диск. Для продашена это не допустимо! У меня несколько раз такое было на тестовых экземплярах JIRA. Хорошо что это были тестовые инстансы. А нормальные СУБД такого не допускают.
я пишу не про продакшн. Плохо понимаю в чем спор. Не хотите использовать H2, не используйте…
И про то, что эта СУБД живет в памяти это не совсем так.
НЛО прилетело и опубликовало эту надпись здесь
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.