Add support for MariaDB to Stash

iT Vissim,

This issue is already closed as fixed, and Bitbucket Server, formerly Stash, has supported MariaDB since 3.6.0, released in January of 2015.

Are you perhaps looking for support in another product?

Best regards,
Bryan Turner
Atlassian Bitbucket

+1 for MariaDB - it is replacement of MySQL that was bought by Oracle and doesn't comply with GPL2 licence anymore - like MariaDB does. Many linux distributions switching to MariaDB - Debian, RedHat, ...

I see this as a must for Atlassian to add support for MariaDB

jvaughn Stash 3.6.0 supports MariaDB as mentioned on the Support Platforms page. No need to wait for the 3.6.1

Should we wait until 3.6.1 or whatever is next, or are we good to use MariaDB on 3.6?

Starting from 3.6, Stash now includes MariaDB 5.5 in its test matrix. This means all subsequent releases of Stash will be continuously verified against MariaDB 5.5, and we now consider it a supported platform.

I have manually verified MariaDB 10.0.15, the current GA release from the 10.0 branch, and Stash's tests also pass on that version. However, MariaDB 10.0 will not be considered supported until it's added to our test matrix. I'll update this issue again when that work is complete.

MariaDB 10.1 is currently an alpha release, and is not supported. Both SkySQL Ab and Atlassian discourage customers running 10.1 alpha releases in production, and we will not be able to provide any support should running MariaDB 10.1 eat your baby children.

Best regards,
Bryan Turner
Atlassian Stash

Edit: One further note. Both MySQL and MariaDB remain unsupported for Stash Data Center. Data Center customers should use Oracle, PostgreSQL or SQL Server instead.

For anyone attempting to use the MariaDB Java Client instead of MySQL Connector/J, this is not curently possible. It turns out the MariaDB connector fails when used with Stash because of a bug in the connector (not in Stash). Specifically, the tinyInt1isBit flag (which is on by default) is not correctly applied in the MariaDB connector, which claims to support it, but it is correctly applied in the Oracle MySQL connector.

In the MariaDB driver, org.mariadb.jdbc.MySQLDatabaseMetaData.getColumns(String, String, String, String) does not apply tinyInt1isBit translation when it retrieves column types. It looks like a bug in dataTypeClause(String) at line 99 in the 1.1.5 (current) version of the driver. The line after it, for year, applies the yearIsDateType flag, and it seems like the "tinyint" WHEN entry should be doing something similar.

Because of this, when using the MariaDB driver, Hibernate fails to validate the schema:

Caused by: org.hibernate.HibernateException: Wrong column type in stash.plugin_state for column enabled. Found: tinyint, expected: bit
	at org.hibernate.mapping.Table.validateColumns(Table.java:373) ~[hibernate-core-4.2.5.Final.jar:4.2.5.Final]

I've opened CONJ-72 in their issue tracker, with a proposed fix.

Best regards,
Bryan Turner
Atlassian Stash

MariaDB [(none)]> show global variables like 'innodb_file_format%';
+--------------------------+----------+
| Variable_name            | Value    |
+--------------------------+----------+
| innodb_file_format       | Antelope |
| innodb_file_format_check | ON       |
| innodb_file_format_max   | Antelope |
+--------------------------+----------+

But yes, i didn't notice the 1 warning, and forgot to do show warnings, thanks that propably why it works via mysql commandline and didn't work by git
anyway, now when i see that warning, i can investigate it more, will let you know. thanks

Marek,

It's likely that 1 warning part is the culprit. The JDBC driver probably doesn't differentiate between warnings and errors, so either is probably treated as the SQL statement failing. Again, just a guess.

Best regards,
Bryan Turner
Atlassian Stash

Marek,

We actively test Stash against standard MySQL 5.1 and 5.5, and the schema works correctly on both. We do not test variants, though, so I can't really provide much insight as to why they would fail; innodb_large_prefix was just a best guess based on previous issues customers have run into.

Two more settings you may consider are innodb_file_format and innodb_file_format_max:

mysql> show global variables like 'innodb_file_format%';
+--------------------------+----------+
| Variable_name            | Value    |
+--------------------------+----------+
| innodb_file_format       | Antelope |
| innodb_file_format_check | ON       |
| innodb_file_format_max   | Antelope |
+--------------------------+----------+
3 rows in set (0.00 sec)

innodb_file_format_check is likely not important, but the other two may be. Again, the settings above are from a standard MySQL 5.5 installation. It's possible just switching to Barracuda format may reproduce the issue you're seeing.

You can turn on SQL logging for Stash by adding the following to stash-config.properties in your STASH_HOME directory:

#hibernate.show_sql=true #You probably don't need to add this one
logging.logger.net.java.ao.sql=DEBUG

Branch permissions use ActiveObjects to access the database, since they are implemented as a plugin (That said, it's likely your log files already contain the exact SQL the system was trying to run when it got the error above, without needing to enable SQL logging). Core code uses Hibernate. I have already modified the core schema to use prefix indexes on MySQL (STASH-3133), which is why you don't see any errors starting Stash. I don't have as much control over ActiveObjects, which is a cross-product plugin used by all Atlassian products, however.

Note that, if you don't care about branch permissions, you may be able to disable that plugin to work around this issue. Under Administration > Manage Add-ons, you can select "System" from the filter drop-down and disable "Atlassian Stash Branch Permissions Plugin". However, disabling this plugin will disable a few others as well.

Best regards,
Bryan Turner
Atlassian Stash

Funny thing, now it imported all right, but i predict more errors, as when i go to stash repo by webpage i got error and need to do on database:

CREATE INDEX index_ao_02a6c0_rej1887153917 ON AO_02A6C0_REJECTED_REF(REF_ID)

Anyway, that's just test instance so i will play a little with that, and maybe later if any problems will move it to normal mysql 5.5

anyway case can be closed, maybe someone will like my workaround
the query i got i have from the log after turning on debugging/profiling