nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

For a very small team, why shouldn't I use built in H2 with JIRA?

Paul Thordarson1

I work with JIRA here at Draper and love it. I would like to install JIRA on a Raspberry PI 3 at home running headlessly (with the $10 minimum license). I think my overall system footprint would be reduced by running H2 and the traffic would be light. What is the main risk of using H2?

Part 2: I am assuming that if I get convinced not to run H2, that the data base should be installed on another PI for best performance. Is that a correct assumption?

Accepted answers

Nic Brough -Adaptavist-

Catastrophic failure is the short answer. It's rare (and even more rare than the failures we've seen with the old HSQL option for JIRA 6 and below), but can still happen, and, like HSQL, if it does go, it's very unlikely you'll be able to recover it without resorting to backups.

It's hard to say it would change performance. The load is spread across two machines, so in theory, yes, more cpu time for both server and application = better performance. But then you have to allow for networking drag as packets have to go to other machines.

All comments

Paul Thordarson1

NOTE: I have received a satisfactory answer. However, stay tuned. I have seen enough hits on Google WRT interest in JIRA on the Raspberry PI that I will put out some notes on my success or failure when I actually try to set it up: question(s) on why if failure, blog post(s) if success.

Jonas Andersson

H2 is a memory based database which means that if the server were to die you might lose quite a lot of data, just like HSQL did. For all i know a in-memory will always be faster while consuming more ram and lacking writes to disk, in very short.

P2: a small mysql deployment on another PI3 could be a solution.

Nic Brough -Adaptavist-

Paul Thordarson1

Part 1: I thought H2 was wrote to disk with in memory being an option.

Part 2: That was exactly what I was thinking if H2 is risky.

Thanks.

Paul Thordarson1

Okay, so the short answer is H2 is not ready for prime time?

On the performance question, I was not really concerned with the CPU consumed by both JIRA and an SQL db running on the same computer. I was more concerned with RAM: while 1 GB is a lot for a $35.00 computer, it goes pretty fast and swapping kills faster than lack of MIPS does.

Anyway, it sounds like the reliability is questionable enough that I will "byte" the bullet on an extra install and network node.

Thanks.

Paul Thordarson1

Also, I had accepted your answer but I thought Nic's was more to the point on the H2 question which I gave precedence to. And apparently, I can't accept more than one.

Thanks.

Nic Brough -Adaptavist-

Yes. H2 is a better in-memory solution than hsql, but it's still got the same flaws because of the very nature of what it's doing.

For what it's worth, I've got a test rig here that works fine for small usage:

Pi 2: running PostGres

Pi 3: running JIRA 7.2

Both with external usb drives. Both built with DietPi and not running anything else.

Paul Thordarson1

Original response to the above comment deleted: I misunderstood "built withDietPi" to refer to building an OS from make scripts, etc. DietPi looks pretty simple so if you already got the original comment, please ignore it

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software

jira-administration