MariaDB JIRA is moving
The MariaDB JIRA instance that currently is in use for project and issue tracking will change. The current instance is hosted in Atlassian’s cloud and it has worked well, but we have hit the maximum user limit of 2000 users. It’s fantastic to see how many of you actually report bugs and other issues in the MariaDB project!
To hit that limit also means that we have to migrate over to a self-hosted instance of JIRA. Below are important details about that change.
When will the switch happen:
Sat 27th of Feb
What is the impact for me as a user of MariaDB’s JIRA:
1. URL change – The current instance is hosted in Atalassian’s cloud and has the URL mariadb.atlassian.net. The new one will be found at jira.mariadb.org starting from 28th of Feb.
2. RSS feeds – If you have been using JIRA’s RSS feeds, you’ll need to set up them again since the URL is changing
What will happen to old JIRA:
The mariadb.atlassian.net JIRA instance will be put into read-only mode and a banner will be visible on each page telling the URL of the new MariaDB JIRA instance. It will remain this way for some time since it has been referenced quite heavily from other sites.
Atlassian hasn’t publicly supported their products running on MariaDB yet, does this mean they’ll now give it their blessing?
@Craig: this move from Atlassian hosted to self-hosted was due to the fact that our Jira instance user count grew over 2000, which was the upper limit for the Atlassian hosted edition. The Jira is simply now so big that we must self-host it now. It is not related to Atlassians support for MariaDB, that has been good all the time.
We prefer to use MariaDB instead of MySQL. However Atlassian states: ‘Neither MariaDB nor PerconaDB are supported. Both are proven to cause problems with JIRA applications’ (reference: https://confluence.atlassian.com/adminjiraserver070/supported-platforms-749382629.html). There is a change request for this also: https://jira.atlassian.com/browse/JRA-32347.
However I can confirm we run JIRA with MariaDB without any problems for more than a year now. See also: https://mariadb.org/eating-dog-food-running-jira-mariadb/
I tried to install Jira Software 7.5.0 into a docker container based on debian 8 with mariadb 10.1 and it fails.
The error happens when creating the schema inside a predefined database.:
One typical command that fails:
CREATE TABLE cwd_directory_attribute (directory_id DECIMAL(18,0) NOT NULL, attribute_name VARCHAR(255) NOT NULL, attribute_value VARCHAR(255), CONSTRAINT PK_cwd_directory_attribute PRIMARY KEY (directory_id, attribute_name));
You get this error:
ERROR 1709 (HY000): Index column size too large. The maximum column size is 767 bytes.
I found a workaround (adding ROW_FORMAT=DYNAMIC) but the origin schema can’t be modified. And as mariadb 10.1 doesn’t support a global option for row_format, I’m stuck.
So either I install mysql and give it a try (after all, it’s supported!), or I try to upgrade to mariadb 10.2 and use a global option for ROW_FORMAT.
I’m not even sure if it will work with mysql…
Debian 10.1 has utf8mb4 as a default character set, ,which causes the index columns to be too long in this case. See https://mariadb.com/kb/en/library/differences-in-mariadb-in-debian-and-ubuntu/ You can either change the character set, or preferable is to set innodb_large_prefix to ON, which overcomes this limit. See https://mariadb.com/kb/en/library/xtradbinnodb-server-system-variables/#innodb_large_prefix
Actually, that won’t work in 10.1, as that also requires dynamic, which can only be set as default from 10.2 ( https://mariadb.com/kb/en/library/xtradbinnodb-server-system-variables/#innodb_default_row_format ) So solutions are probably down to upgrading to 10.2 or changing the character set.