[arch-general] maria update to 10.4.6 breaks akonadi's db
Oliver Jaksch
arch-general at com-in.de
Fri Jun 28 08:12:36 UTC 2019
Little progress...
The man of mysql_upgrade states it:
--datadir=path
Old option accepted for backward compatibility but ignored
So I did a fresh login and let akonadi/mariadb starts. I then stopped akonadi
and re-used it's socket:
# mysqld --defaults-file=$HOME/.local/share/akonadi/mysql.conf --
datadir=$HOME/.local/share/akonadi/db_data/ --socket=/tmp/akonadi-XXX.n8sdoz/
mysql.socket --pid-file=/tmp/akonadi-XXX.n8sdoz/mysql.pid
I can connect to the mariadb instance now and let some commands fly, according
to https://mariadb.com/kb/en/library/mysql_upgrade/ :
# mysqlcheck --no-defaults --check-upgrade --auto-repair --all-databases --
socket=/tmp/akonadi-XXX.n8sdoz/mysql.socket
# mysqlcheck --no-defaults --all-databases --fix-db-names --fix-table-names --
write-binlog --socket=/tmp/akonadi-XXX.n8sdoz/mysql.socket
# mysqlcheck --no-defaults --check-upgrade --all-databases --auto-repair --
write-binlog --socket=/tmp/akonadi-XXX.n8sdoz/mysql.socket
The output is always
> akonadi.collectionattributetable OK
> akonadi.collectionmimetyperelation OK
> akonadi.collectionpimitemrelation OK
> akonadi.collectiontable OK
> akonadi.flagtable OK
> akonadi.mimetypetable OK
> akonadi.parttable OK
> akonadi.parttypetable OK
> akonadi.pimitemflagrelation OK
> akonadi.pimitemtable OK
> akonadi.pimitemtagrelation OK
> akonadi.relationtable OK
> akonadi.relationtypetable OK
> akonadi.resourcetable OK
> akonadi.schemaversiontable OK
> akonadi.tagattributetable OK
> akonadi.tagremoteidresourcerelationtable OK
> akonadi.tagtable OK
> akonadi.tagtypetable OK
But when ending this mariadb instance and restarting akonadi, the horror of
errors from post #1 starts all over again :(
On Friday, 28 June 2019, 08:55:24 CEST you wrote:
> On Friday, 28 June 2019, 07:49:16 CEST you wrote:
> > On Fri, 28 Jun 2019, at 07:41, Oliver Jaksch via arch-general wrote:
> > > Updated three of my KDE clients by terminal (not logged in by display
> > > manager/DM) and ran
> > >
> > > # systemctl restart mariadb.service && mariadb-upgrade -u root
> > > -p
> >
> > This doesn't affect akonadi's data since it is located someplace else at a
> >
> > non-system location:
> > /usr/bin/mysqld --defaults-file=$HOME/.local/share/akonadi/mysql.conf
> >
> > --datadir=$HOME/.local/share/akonadi/db_data/ --s
> > ocket=/tmp/akonadi-xxx.LdhzVw/mysql.socket
> > --pid-file=/tmp/akonadi-xxx.LdhzVw/mysql.pids
>
> Yes, I know that, but I thought that akonadi would run a similar upgrade by
> itself when started and necessary. Wasn't that the case in the past?
>
> > I suggest you look into actually upgrading akonadi's DB first. For that,
> > you probably can pass --defaults-file and --datadir as-is to
> > mariadb-upgrade (and the upgrade should be executed as the user akonadi
> > is running as, not root).
>
> Thanks for that good starting point. But, alas, it gives me a
> # mysql_upgrade: the '--datadir' option is always ignored
>
> ...but this gives me hope for further investigations (=search engine). Will
> try and report; chances are good as it's friday and it's quiet today :)
More information about the arch-general
mailing list