risk of running on H2 database

[Dave Kitabjian]

A production jira server was recently rebuilt and put into service running on the the embedded H2 database by mistake. We are planning on migrating to PostgreSQL.

But meanwhile, the site is live on H2.  The support page shows:

"Jira ships with a built-in database (H2) which is for evaluation only."

https://confluence.atlassian.com/jirakb/jira-databases-compatibility-matrix-1223821024.html

Can someone please explain what risk we're in? Is it a performance/load limit? Data integrity/corruption risk?

Thanks,

DK

[Nic Brough -Adaptavist- · Accepted solution]

Welcome to the Atlassian Community!

The biggest risk is that you will lose absolutely everything right now.  I really do mean now, it could easily have failed why I am typing.

The damage tends to be catastrophic, not just integrity or corruption.   If you imagine a database as a single file, with issues first and config data at the end, imagine what happens if you only have the first 10% of that file after a failure.

The likelihood of a failure increases on a (gentle) exponential curve against the size of the data (10,000 issues is more likely to fail than 1,000 issues, but 20,000 issues is way more than twice as likely to fail as 10,000), and the most frequent trigger of a failure is not stopping Jira properly, but there are plenty of other things that can make it fail, and many other factors that can increase the chances of failure (apps, heavy usage, trying to integrate with other systems, and and and) many of which I've never bothered to get to the bottom of.

Get a backup of it immediately and shut it down while you set it up on a proper database.

[Matt Doar]

What Nic said. All the things that people are putting in Jira right now may be lost. Take it out of production fast

[Nic Brough -Adaptavist-]

If you absolutely must carry on using it while you plan and build your move to a supportable system, then tighten your backup cycles.

I remember one place where I ended up amending their backup scripts so that when the current backup finished, the next one started after a 10 second pause!

I should have said this earlier though - the problems you could have are very much database only.  Your Jira installation and your attachments will not be a problem. 

[Dave Kitabjian]

Okay, thanks for the reply. We have since migrated to MySQL8.

I will say that if H2 is truly a ticking time bomb, then I find it a poor product design choice even for evaluation purposes. Most people are not going to "test" Jira on H2 and then throw all their data out as junk, build the real-deal with MySQL, and then start using it. They are going to start using Jira/H2 and then find it useful in soft-production and then go live, and then eventually rebuild. So the move from "test mode" to "live mode" will be gradual, making the risk of using H2 go from low to high silently.

A database has very few jobs, and reliability is top of the list. Why use H2 at all if it's so lousy in that department? If it's because it's easier to deploy, note that people use sqlite as an alternative and find it much more reliable. It's also trivial to deploy.

I would never allow my software development projects to put customer data at risk by using a product known to explode unpredictably. Maybe 50 years ago when we didn't have excellent alternatives. But not today. And preventing people from driving off a cliff is 100x better than warning them not to.

[Nic Brough -Adaptavist-]

It's not a bad choice for evaluation or development - remember that an evaluation or development system is only ever going to be used very briefly, and with data you're going to discard.

Having to set up a proper database every time you need a quick throwaway system is a massive pain in the neck, and H2 means you don't need to. 

SQLite has the same problem as other databases, it's not quick enough to set up automatically (and it's not good as a database service for most Atlassian systems)

[Dave Kitabjian]

"remember that an evaluation or development system is only ever going to be used very briefly, and with data you're going to discard."

No, I just explained that that's not the case:

"Most people are not going to "test" Jira on H2 and then throw all their data out as junk, build the real-deal with MySQL, and then start using it. They are going to start using Jira/H2 and then find it useful in soft-production and then go live, and then eventually rebuild. So the move from "test mode" to "live mode" will be gradual, making the risk of using H2 go from low to high silently."

Regarding: "every time you need a quick throwaway system" - that's a problem I'm sure you face as Jira devs. Customers are not setting up throwaway jira systems every day. They will do it maybe ONCE.  You said yourself this is for customers to evaluate Jira. 

You have to think like a customer, not like a developer.

[Nic Brough -Adaptavist-]

I'm afraid that's not thinking like a customer.

Thinking like a customer means I would do a bit of an evaluation and pay attention to the constant warnings that I am not using a system that is not suitable for production.  If I put real data into it during an evaluation, then I would heed those warnings and move it to a supported database before rolling it out to everyone.

[Dave Kitabjian]

"Thinking like a customer means I would do a bit of an evaluation and pay attention to the constant warnings that I am not using a system that is not suitable for production. "

You're completely missing the point. When I tell you you need to think like a customer, it's in Atlassian's design choice to use H2 in the first place, and therefore in Atlassian's choice to put customers in this position at all.

[Nic Brough -Adaptavist-]

I am not missing the point, I think you are.  H2 was, and still is, a quick and easy choice for firing up throw-away systems where the customer is not going to use them in production.  Plus they're systems which repeatedly scream that they're not for production (you can't turn the warnings off without recompiling the code!)

It's also a moot point now.  Atlassian have ended all support for server systems, so the only customers who might have a use for a temporary install are

• Developers writing for Data Centre, who will be fully aware that H2 is not in use in production
• Evaluators and Demo providers looking at Data Center installs, which will be larger organisations who will automatically want to be running things on their preferred database systems (almost every large organisation will be running on Oracle, MS-SQL, Postgresql or MySQL)