Sakai 22.5 + MariaDB 11.4

[Austin]

Hello Sakai Devs,

I'm trying to switch our Sakai 22.5 from MySQL to MariaDB 11.4.  I know that the 23+ nightly servers are running on MariaDB and past messages in this forum have said that it should work with 22.   Does anyone have any hints on how to make the change to MariaDB?

I'm using config

Sakai 22.5

MariaDB 11.4.8
mariadb-java-client-2.7.4.jar (also fails with mariadb-java-client-3.5.6.jar)

## MySQL settings
ven...@org.sakaiproject.db.api.SqlService=mariadb
driverC...@javax.sql.BaseDataSource=org.mariadb.jdbc.Driver
hibernate.dialect=org.hibernate.dialect.MariaDBDialect
u...@javax.sql.BaseDataSource=jdbc:mariadb://<server>/sakai?useUnicode=true&characterEncoding=UTF-8
validat...@javax.sql.BaseDataSource=select 1 from DUAL
defaultTransacti...@javax.sql.BaseDataSource=TRANSACTION_READ_COMMITTED

However I'm getting the following error in catalina.out

"No translator for this database type: MARIADB"

Thanks,

Austin

[Sam Ottenhoff]

Please show the actual stack trace.

--Sam

--
You received this message because you are subscribed to the Google Groups "Sakai Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sakai-dev+...@apereo.org.
To view this discussion visit https://groups.google.com/a/apereo.org/d/msgid/sakai-dev/CAKL84%3DkxpMFXf%3D3Vq-7NdxpEhj8YuPiJji58FMPFkbJKPUXc2g%40mail.gmail.com.

[Austin]

stacktrace attached

[Matthew Jones]

Nightly is just using mysql as the vendor. I also don't know if we had Maria on 22, or just added to 23.

# MariaDB settings
ven...@org.sakaiproject.db.api.SqlService=mysql
driverC...@javax.sql.BaseDataSource=org.mariadb.jdbc.Driver
hibernate.dialect=org.hibernate.dialect.MariaDB103Dialect

To view this discussion visit https://groups.google.com/a/apereo.org/d/msgid/sakai-dev/CAKL84%3DnG%2BaOnkY-FHofxbkkryNPtp3G1kSOANu3FkuWoiQd6bg%40mail.gmail.com.

[Sam Ottenhoff]

I don't think Sakai has ever supported mariadb as an eligible vendor. It should be "mysql" in 22,23,25+

[Austin]

Thanks Matthew and Sam!

That got me past the error "No translator for this database type: MARIADB"

It looks like the app is connecting to the database (when viewing connected users via db client)

However, I'm seeing a different startup error now, 

29-Oct-2025 14:26:40.123 WARN [main] o.s.u.BaseDbDualSingleStorage.readResource readResource():
org.sakaiproject.entity.api.serialize.EntityParseException: Failed to parse entity
at org.sakaiproject.content.impl.serialize.impl.Type1BaseContentCollectionSerializer.parse(Type1BaseContentCollectionSerializer.java:186) ~[?:?]
at org.sakaiproject.content.impl.BaseContentService$CollectionStorageUser.parse(BaseContentService.java:1122) ~[?:?]
at org.sakaiproject.util.EntityReaderAdapter.parse(EntityReaderAdapter.java:138) ~[?:?]

.

.

.

see attachments for full stacktrace.  I see that the nightlies are on MariaDB 10.6.7.  I'm using version 11.4.8.  Could that be a problem?

Thanks,

Austin

--------------

Sakai 22.5

MariaDB 11.4.8
mariadb-java-client-2.7.4.jar (also fails with mariadb-java-client-3.5.6.jar)

## MySQL settings

ven...@org.sakaiproject.db.api.SqlService=mysql
driverC...@javax.sql.BaseDataSource=org.mariadb.jdbc.Driver
hibernate.dialect=org.hibernate.dialect.MariaDB103Dialect

u...@javax.sql.BaseDataSource=jdbc:mariadb://<server>/sakai?useUnicode=true&characterEncoding=UTF-8
validat...@javax.sql.BaseDataSource=select 1 from DUAL
defaultTransacti...@javax.sql.BaseDataSource=TRANSACTION_READ_COMMITTED

## SITESTATS
sitestats.db=external
sitestats.externalDb.name=sakai_sitestats
sitestats.externalDb.driverClassName=org.mariadb.jdbc.Driver
sitestats.externalDb.hibernate.dialect=org.hibernate.dialect.MariaDB103Dialect
sitestats.externalDb.jdbcUrl=jdbc:mariadb://<server>/sakai_sitestats?useUnicode=true&characterEncoding=UTF-8&sessionVariables=sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION'

[Matthew Jones]

Right, Nightly is still on 10.6 LTS and I've locally tested only up to 10.11 LTS, but I haven't tried 11 yet. It could be related to that. Not sure if anyone else is running MariaDB 11 and haven't recently kept up with what's changed. 

I don't see anything else that might be causing an issue here. There error is from here https://github.com/sakaiproject/sakai/blob/3eff622eccd2afe99181d40f82d82ad713eccce2/kernel/kernel-impl/src/main/java/org/sakaiproject/content/impl/serialize/impl/Type1BaseContentCollectionSerializer.java#L186 and this file hasn't really changed much since 22.

So something seems to be going wrong parsing the binary data. 

I might try to update the driver and see if that helps. It looks like the one currently bundled is 3.5.6 and you have 2.7.4. That's possibly the easiest thing you could try. Be nice if it's a configuration error or something else easy! 

[James Scoble]

Good day

I've recently gotten Sakai 25.x to work on Mariadb, just a few changes needed.

In sakai.properties, where mysqld needs:

hibernate.dialect=org.hibernate.dialect.MySQL5InnoDBDialect

for mariadb you put:

hibernate.dialect=org.hibernate.dialect.MariaDB103Dialect

then further down:

u...@javax.sql.BaseDataSource=jdbc:mariadb:

in place of

u...@javax.sql.BaseDataSource=jdbc:mysql:

And it works. :-)

kind regards

James Scoble

To view this discussion visit https://groups.google.com/a/apereo.org/d/msgid/sakai-dev/CAJEDiB5or8S8ASBdAGLkkJskDF0bRQb1JcfjiCPqYWi3NKw49g%40mail.gmail.com.

Disclaimer - This e-mail is subject to UWC policies and e-mail disclaimer published on our website at: https://www.uwc.ac.za/disclaimer

[Austin]

Thanks Matthew,

I did some debugging and the latest error is throwing an EOFexception on line

https://github.com/sakaiproject/sakai/blob/2c4a54c7707a316a3dc293d3b54cc990ce3250a7/kernel/kernel-impl/src/main/java/org/sakaiproject/content/impl/serialize/impl/Type1BaseContentCollectionSerializer.java#L252

Here are some of the values of the (DataStream) 'ds' variable at that point.  Is my data corrupt?

bytearr = [105, 110, 104, 101, 114, 105, 116, 101, 100, 112, 114, 111, 106, 101, 99, 116, 46, 99, 111, 110, 116, 101, 110, 116, 46, 116, 121, 112, 101, 115, 46, 102, 111, 108, 100, 101, 114, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

chararr = [i, n, h, e, r, i, t, e, d, p, r, o, j, e, c, t, ., c, o, n, t, e, n, t, ., t, y, p, e, s, ., f, o, l, d, e, r, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �, �]

[Matthew Jones]

So I've never seen this but you say this started when converting from MySQL to Maria? I've certainly never tried this and always started with a fresh database.

Which version of MySQL? I was chatting with ChatGPT about this and it thinks that can happen if you did a mysqldump on MySQL and tried to import. I'm just going to dump these suggestions because I think they might be applicable but only you would know and they seem reasonable.

Do you still have the MySQL database? Can you compare the lengths and types? I think it's the XML column.

SELECT id, LENGTH(xml) FROM content_resource ORDER BY LENGTH(xml) DESC LIMIT 5;

 Common Causes

1️⃣ The column type silently changed

MySQL sometimes stored serialized data in longtext or mediumtext instead of blob.
When migrated, MariaDB 11 defaults to utf8mb4 text encoding — which can reinterpret some byte sequences as invalid UTF-8 and truncate or pad them.

Check this:

SHOW COLUMNS FROM content_resource LIKE 'xml';

or whatever your serialized column is called.

If you see:

Type: longtext
Collation: utf8mb4_general_ci

then Sakai thinks it’s reading a binary blob, but MariaDB is feeding it UTF-8 text.
That will destroy binary serialization.

✅ Fix:
Convert the column explicitly back to binary:

ALTER TABLE content_resource MODIFY xml LONGBLOB;

---

2️⃣ The dump/restore re-encoded binary data

If the migration was done like:

mysqldump --default-character-set=utf8 > dump.sql
mysql < dump.sql

then binary content in TEXT columns was re-encoded as UTF-8 text, corrupting the byte stream (e.g., replacing 0x00 or 0xC0 bytes).

✅ Fix:
Re-dump using:

mysqldump --hex-blob --routines --triggers --events

That keeps binary fields intact and hex-encoded.

[Austin]

Hello Matthew,

Good call.  It looks like the xml (longtext) columns in content_resource and content_collection got truncated when we imported the data into MariaDB 11.  Quite a few tables use longtext.  I only checked a couple (announcements) and they seemed ok, so maybe the truncating issue would only affect longtext with hex or binary data?

We'll look into your other suggestions.

Thanks,

Austin

[Matthew Jones]

I'd think only he content ones (and the content backup) would be affected by this, as they store the data in the special binary format.