FS#75033 - [mariadb] Version 10.8.3-1 breaks Akonadi

Attached to Project: Arch Linux
Opened by Marius (Martchus) - Saturday, 11 June 2022, 11:22 GMT
Last edited by Antonio Rojas (arojas) - Wednesday, 15 June 2022, 18:48 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
Akonadi does not start after upgrading mariadb to 10.8.3-1 because it cannot start mysqld anymore. Maybe I'm missing a migration step here. If that's the case, it would be nice to add a notice to https://archlinux.org/news.

Steps to reproduce:
Try to start akonadi, e.g. in a shell via `akonadictl start`. It'll log that it failed to start mysqld and the command it has been using. When invoking the command manually with `--verbose` one can get further details, e.g. on my system it looks like this:

```
/usr/bin/mysqld --verbose --defaults-file=/home/martchus/.local/share/akonadi/mysql.conf --datadir=/home/martchus/.local/share/akonadi/db_data/ --socket=/run/user/1000/akonadi/mysql.socket --pid-file=/run/user/1000/akonadi/mysql.pid
2022-06-11 13:06:14 0 [Note] /usr/bin/mysqld (server 10.8.3-MariaDB) starting as process 3420 ...
2022-06-11 13:06:14 0 [Note] InnoDB: Compressed tables use zlib 1.2.12
2022-06-11 13:06:14 0 [Note] InnoDB: Number of transaction pools: 1
2022-06-11 13:06:14 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2022-06-11 13:06:14 0 [Note] InnoDB: Using Linux native AIO
2022-06-11 13:06:14 0 [Note] InnoDB: Initializing buffer pool, total size = 128.000MiB, chunk size = 2.000MiB
2022-06-11 13:06:14 0 [Note] InnoDB: Completed initialization of buffer pool
2022-06-11 13:06:14 0 [ERROR] InnoDB: File ./ib_logfile0 was not found
2022-06-11 13:06:14 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2022-06-11 13:06:14 0 [Note] InnoDB: Starting shutdown...
2022-06-11 13:06:14 0 [ERROR] Plugin 'InnoDB' init function returned error.
2022-06-11 13:06:14 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2022-06-11 13:06:14 0 [ERROR] /usr/bin/mysqld: unknown variable 'defaults-file=/home/martchus/.local/share/akonadi/mysql.conf'
2022-06-11 13:06:14 0 [ERROR] Aborting
```

When removing the argument `--defaults-file` the error looks similar. Not sure where `./ib_logfile0` is supposed to come from or what it is used for.

Workaround:
Downgrading mariadb, mariadb-clients and mariadb-libs from 10.8.3-1 to 10.7.4-1 helps. I suppose switching to the PostgreSQL backend would also help but I haven't tried that.
This task depends upon

Closed by  Antonio Rojas (arojas)
Wednesday, 15 June 2022, 18:48 GMT
Reason for closing:  Fixed
Additional comments about closing:  akonadi 22.04.2-2
Comment by Antonio Rojas (arojas) - Saturday, 11 June 2022, 11:49 GMT
touch ~/.local/share/akonadi/db_data/ib_logfile0
Comment by Marius (Martchus) - Saturday, 11 June 2022, 11:57 GMT
@arojas Thanks, it worked. Now I feel stupid for not trying that. Maybe it is still worth a notice in the news and it'll be obviously nice if MariaDB would be able to create the file on its own.
Comment by Martin Schnitkemper (Martin-MS) - Monday, 13 June 2022, 07:41 GMT
As I already stated in the upstream bug report https://bugs.kde.org/show_bug.cgi?id=454948 it was for me not a proper solution to create an empty file by touching "ib_logfile0", since it throws thousands of entries in mysql.err like

| [ERROR] InnoDB: Page [page id: space=0, page number=7] log sequence number 1447482201 is in the future! Current system log sequence number 1378510903.
| [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.

after the second launch of the akonadi server. I cannot see any malfunction, but I don't really trust a system that reports a corrupt database.

Instead of I suggest to back up the file before an update or restore it from a current backup. If it has already happened then it also helps to delete (or rename) the "db_data" folder and start new with a

| mariadb-install-db --datadir=$HOME/.local/share/akonadi/db_data --basedir= /usr

@Marius: This is an intentional behavior of MariaDB that a log file is no longer created if it is missing: https://jira.mariadb.org/browse/MDEV-27199

In my opinion it's not a problem with MariaDB; the akonadi developers should investigate why akonadi drop the logfile since the last update of the application upon its first launch.
Comment by Steven McFeely (smcfeely) - Wednesday, 15 June 2022, 17:47 GMT
@Martin-MS

No, the database is almost certainly not corrupt. The error message says MariaDB throws that error when either the database is corrupt *or* the InnoDB log files are missing. Since you created the file ib_logfile0 through the touch command, and it is therefore blank, MariaDB thinks you moved the database but forgot to move the log files. That is also why after subsequent launches of the akonadi server there is no error. The log file ib_logfile0 is no longer blank as it has been written to.

If you are really worried that the db is corrupt, you should be able to delete it (I recommend moving it to another location just in case) and let akonadi create a brand new db. Then the data just has to be resynchronized. I would guess this will all happen automatically but I have never needed to do it so I cannot say for certain.

I otherwise agree that the devs need to figure out why the log file was dropped. It is possible, that the akonadi devs relied on MariaDB to always generate a new log file to prevent the log from growing to an absurd size. The log file likely is not particularly meaningful to save between reboots as the akonadi db just acts as a local cache - it does not permanently store any of your actual data.

Loading...