Hello Ondrej! I sent the below message on Oct 10th but I am not sure if you read it. The gist is:
> I recommend that you file a bug about this upstream, and try to attach > relevant info from the error log, maybe a strace output etc. Upstream > devs will guide you on what to debug next. The bug report https://jira.mariadb.org/browse/MDEV-265377 was investigated and fixed because the submitter provided a trace and core dump. If you are hitting a bug and you cannot provide steps to reproduce it, you should provide other data. Don't waste time on recompiling your own versions, that path won't lead to any fixes upstream or in Debian. If you represent an enterprise and are running MariaDB in a critical environment, you might want to consider to hire a consultant or get a support contract so somebody else can investigate database crashes/corruption for you. On Mon, Oct 11, 2021 at 12:58 AM Otto Kekäläinen <o...@debian.org> wrote: > > > The problem is in the ibdata1 file (about 450MB). Deleted other database > > directories and it still crashes, deleted ibdata1 and it runs. > > > > How to bisect mariadb from git? Tried: > > $ git bisect good mariadb-10.3.29 > > $ git bisect bad mariadb-10.3.31 > > the build process showed version 10.2 so I aborted it. > > > > Checked out mariadb-10.3.30 but dpkg-buildpackage failed with: > > dh_install: mariadb-plugin-cassandra missing files: > > etc/mysql/conf.d/cassandra.cnf > > Some dependency was missing and Cassandra was not built. Note that the > upstream repository is not identical to the one in Debian regarding > the contents of debian/ directory. MariaDB builds without a cache take > 30 mins each and there are all kinds of things going on. Doing bisect > (fully correctly) on MariaDB is hard even for experienced developers. > Your time is probably better spent doing some other kind of debugging. > > I recommend that you file a bug about this upstream, and try to attach > relevant info from the error log, maybe a strace output etc. Upstream > devs will guide you on what to debug next. > > One thing you could also try is to start the server with 10.3.29 and > ensure that you have a clean shutdown (SET GLOBAL > innodb_fast_shutdown=0; SHUTDOWN) and only after that start with the > new 10.3.31 binary. > > Ref > - https://mariadb.com/kb/en/shutdown/#see-also > - https://www.percona.com/blog/2020/05/07/prepare-mysql-for-a-safe-shutdown/
