MySQL, MariaDB, Percona Serverで高速に全文検索するためのストレージエンジンMroongaのメンテナンスをしている堀本です。
Mroonga 15.21をリリースしました！ 直近のリリースが2025-09-30なので、2ヶ月ぶりのリリースです。
今回のリリースでは、Debian 13とMariaDB 11.8を新たにサポートしました。 Debian 13は2025-08-09に、MariaDB 11.8は2025-06-08にリリースされました。 Debian 13は数ヶ月、MariaDB 11.8に至ってはサポートに半年かかってしまいました。。。
がんばってサポートしたので、この記事では、Debian 13とMariaDB 11.8のサポートに時間がかかった理由を紹介しようと思います。
時間がかかった理由
なぜ、時間がかかったのかですが、Debian 13については簡単で、MariaDB 11.8の対応に時間がかかったからです。
Debian 13が提供するMariaDBのバージョンは11.8です。 そのため、MroongaがMariaDB 11.8で使えるようにならないと、Debian 13でMariaDB + Mroongaの組み合わせでMroongaを使えません。 よって、MariaDB 11.8をサポートすればDebian 13向けのパッケージもリリースできることになります。 しかし、MariaDB 11.8のサポートに時間がかかったため、Debian 13のサポートにも時間がかかったというわけです。
では、MariaDB 11.8のサポートに時間がかかった理由を見ていきましょう。
通常、新しいMariaDBがリリースされた時は、最新版のMariaDBを使ってMroongaをビルドし直すだけで、新しいバージョンのMariaDBに対応できます。 ただ、MariaDBはバージョンアップの際にストレージエンジンに提供しているAPIを変更することがあります。（結構、頻繁に変更します。） このAPIの変更に追従しないと、Mroongaのビルドに失敗しパッケージを作ることができず、リリースできなくなります。
そのため、新しいバージョンでAPIが変更された場合、その変更に追従するための改良をMroongaに入れることになりますが、 変更の内容によっては、原因を突き止めるのが難しい場合があり、そうなると対応するのに時間がかかります。
今回は、MariaDB 11.8の対応で複数の原因を突き止めるのが難しい変更が入っていたので、対応に半年かかりました。
具体的には以下の4つです。
解決に苦労した問題
GeoPoint型からWGS84GeoPoint型へのキャストに失敗する問題
該当のIssueは、https://github.com/mroonga/mroonga/issues/982 です。
HAVE_SPATIALというフラグがMariaDB 11.8では削除されていたのが原因でした。
以前はこのフラグでMariaDBは挙動を変化させていましたが、最近のバージョンでは使用されていなかったので、11.8では削除されたのだと思います。
Mroongaはこのフラグが定義されているかどうかで挙動を変更していました。
本来HAVE_SPATIALがONの状態で動くべきところが、HAVE_SPATIALが削除されたためHAVE_SPATIALがOFFの状態として動作しており、結果としてキャストに失敗するという現象となって現れました。
この問題は、https://github.com/mroonga/mroonga/pull/993 で修正しています。
Mroongaが最適化を行った回数が誤っている問題
該当のIssueは、https://github.com/mroonga/mroonga/issues/983 です。
最適化を行った回数をリセットできていなかったのが原因でした。
Mroongaはより速くレスポンスを返すためにいくつか最適化を行っています。 これらの最適化が使われたかどうかを確認するために、最適化が使われた回数を表示することができるのですが、その回数が誤っているというものです。
最適化の回数を確認するテストでは、個々のテスト開始時にFLUSH STATUSというコマンドを実行して最適化の回数をリセットしていました。
MariaDB 11.8で、FLUSH STATUSの挙動が変わったため、FLUSH STATUSを使っても最適化の回数がリセットされなくなっていました。
FLUSH GLOBAL STATUSを使うとリセットされるので、そっちを使うように改良しています。
この問題は、以下の2つの変更で修正しています。
between()関数を使用していると、キーのノーマライズに失敗する問題
該当のIssueは、https://github.com/mroonga/mroonga/issues/984 です。
between()関数をMroonga内で処理する時に文字エンコーディングを正しく設定していないことが原因でした。
詳細は割愛しますが、MariaDBには、condition push downという仕組みがあり(MySQLにもあります)、特定の条件でWHERE句の条件をストレージエンジン側で処理するようにできます。
ストレージエンジンで条件を処理したほうが高速化できることがあるからです。
今回の問題は、between()関数がこのcondition push downによってMroonga側で処理される時に文字エンコーディングを設定していないことで発生していました。
この問題が発生したテストでは、ノーマライズにgroonga-normalizer-mysqlが使われるのですが、groonga-normalizer-mysqlは文字エンコーディングがUTF-8であることを前提に動作します。 そのため、文字エンコーディングが正しく設定されてない場合、ノーマライズに失敗します。
push down時にMariaDB側から文字エンコーディングを渡してもらえるので、それを設定してbetween()関数を処理するように改良しました。
この問題は、https://github.com/mroonga/mroonga/pull/999 で修正しています。
ラッパーモードで全文検索を実行するとMariaDBが強制終了する問題
該当のIssueは、https://github.com/mroonga/mroonga/issues/996 です。
これは、理解するのにいくつか前提情報が必要で、きちんと説明すると長くなってしまうため、簡単に説明します。 難しい問題だったというのが伝われば十分です。
これは、ラッパーモード特有の問題でした。 Mroongaのラッパーモードは、SQLを処理するSQLハンドラーとInnoDBの間に入って処理します。 そのため、Mroonga内で処理が終わったあとにInnoDBに処理を戻します。
このInnoDBのハンドラを作る際に初期化される値が追加されたことが原因でした。
詳細は割愛しますが、WHERE_COSTという値が0に初期化されるようになり、別の関数を使ってデフォルト値(3.2-e05)をセットしてから使うようになっていました。
本来3.2-e05がセットされている値に0が設定されており、想定しない値がセットされたままInnoDBに処理が戻ってしまい、その後、強制終了するようになっていました。
デフォルト値をセットしてからInnoDBに処理を戻すように改良しました。
この問題は、https://github.com/mroonga/mroonga/pull/998 で修正しています。
以上が今回解決に苦労した問題でした。
まとめ
Mroonga側に機能を追加していなくても、今回のようにMariaDB側の変更によって様々な対応が必要になることがあります。 そういった問題も片付けつつ、新しいバージョンに対応し続けています。
リリースノートでは、「新規にMariaDB 11.8をサポートしました。」の一行で終わってしまうのですが、その一行の裏にはこのような作業が発生することがあるというのを紹介しました。
ということで、今回リリースしたMroonga 15.21はDebian 13でも使えますし、MariaDB 11.8もサポートしました。 是非、使ってみてください。 ただ、MariaDBが11.7からサポートしたVector TypeはまだMroongaでは使えないので、そこだけ注意してください。
お使いのMroongaで困ったことがあれば、クリアコードはサポートサービスを提供しているので、そちらを使うことをご検討ください。
また、毎月のリリース内容を自慢するリリース自慢会もYouTubeで配信しているので、興味があればそちらも見ていただければと思います。
