Debian 9

How did you compile it?
And check if you are running with the correct binary.

I used the Debian package released by MariaDB.org as shown in the logs above.

MariaDB 10.2.21 seems to be affected as well.

OS: Linux Debian-93-stretch-64-minimal 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64

MariaDB: 10.2.21-MariaDB-10.2.21+maria~stretch-log / mariadb.org binary distribution

show global status like '%have%';

ldd /usr/sbin/mysqld | grep lz4
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f0c70b75000)

ls -l /usr/lib/x86_64-linux-gnu/liblz4.so.1
lrwxrwxrwx 1 root root 15 Feb 17 2016 /usr/lib/x86_64-linux-gnu/liblz4.so.1 -> liblz4.so.1.7.1

I think it would be great to be able to use newer compression algos in MariaDB InnoDB as well as RocksDB.

centos packages supports lz4 but debian packages not - it would be great if we do not need to recompile mariadb because of much needed lz4

As the documentation says, "on many distributions, the standard MariaDB builds do not support all InnoDB page compression algorithms by default".

With that, I will redirect the request to marko for an expert opinion on whether we should add any specific compression algorithms to our builds by default.

Following up on this matter: I have installed the new release 10.5.4 on
Ubuntu 20.04 and I am glad to see LZ4 is now available. Unfortunately, the
binaries lack support for ZSTD which is a pity because it would mean a
great improvement over Zlib. I have not managed to compile 10.5.4 from
source though I followed the instructions for Ubuntu as provided on
mariadb.org.

Suggestion: the available compression algos should be treated as key
features of MariaDB, as they have a huge impact on IO, CPU and space
consumption. I would be very glad if the dev team puts an emphasis on
trying to make available the best compression algos in the binaries, at
least for those environments, where it is possible without too much
overhead.

Am So., 5. Apr. 2020 um 14:19 Uhr schrieb Elena Stepanova (Jira) <

I think that we should make a decision regarding this in MDEV-11068.

Personally, as noted in MDEV-22839, I would tend to agree with the 2015 blog post Wanted: a file system on which InnoDB transparent page compression works . Random-access page I/O does not feel like a good match for compression. Large sequential files (such as the LSM trees of MyRocks) should be better.

illuusio, can you check whether and how MDEV-12933 addressed this?

I've check this and if you have liblz4-1 installed MariaDB 10.3 will show list like this (same goes with rest of compressions if you have library they will be enabled):

MariaDB [(none)]> show global status like '%have%';

+------------------------+-------+

| Variable_name          | Value |

+------------------------+-------+

| Innodb_have_lz4        | ON    |

| Innodb_have_lzo        | OFF   |

| Innodb_have_lzma       | OFF   |

| Innodb_have_bzip2      | OFF   |

| Innodb_have_snappy     | OFF   |

| Innodb_have_punch_hole | ON    |

+------------------------+-------+

6 rows in set (0.003 sec)

MariaDB [(none)]> set global innodb_compression_algorithm='lz4';

Query OK, 0 rows affected (0.000 sec)

In MariaDB 10.3 compression libraries are not installed as preset. They are done from MariaDB 10.7 when you install correct compression plugin beides mariadb-server. As MariaDB will EOL after next release I doubt this won't be changed.

illuusio, what I mainly wanted to know is whether this bug was fixed on newer Debian, for Debian’s own packages of MariaDB Server. You seem to confirm that for MariaDB’s Debian packages, it was likely fixed in MariaDB Server 10.7 (which already reached EOL). Has this been fixed in the most recent Debian’s package of MariaDB Server 10.11? (10.11 is the first long-term-support release after 10.6.)

I don't know is there anything to be done with this? marko or danblack?

illuusio, if all compression libraries are available in Debian 12 out of the box, I would close this as fixed in MariaDB 10.11 or something.

As said if you install MariaDB 10.7 or 10.11 for example on any supported Debian with correct compression plugin I think this is fixed.