mastodon.zunda.ninja is one of the many independent Mastodon servers you can use to participate in the fediverse.
Zundon is a single user instance as home of @zundan as well as a test bed for changes of the code.

Administered by:

Server stats:

1
active users

Mastodon 3.3.0rc1、リリースノートに直接的には書かれてませんけど docker-compose run --rm web tootctl maintenance fix-duplicates の実行がほぼ必須らしい。

db:migrate が警告を出すのです。
"Your database collation is susceptible to index corruption.
  (This warning does not indicate that index corruption has occured and can be ignored)
  (To learn more, visit: docs.joinmastodon.org/admin/tr)"

"データベースの照合順序は、インデックスの破損の影響を受けやすくなっています。
  (この警告は、インデックスの破損が発生したことを示すものではなく、無視できます)
  (詳細については、docs.joinmastodon.org/admin/tr にアクセスしてください)"

docs.joinmastodon.orgDatabase index corruption - Mastodon documentationHow to recover from database index corruption.
zunda

@tateisu glibc 2.28でUnicode文字列の順番が変更になったので、MastodonのPostgreSQLをこのバージョンを越えて更新する場合にインデックスが破損してしまうという問題のようです。PostgreSQLのOSの更新をせずアプリのコードの更新だけをする場合には気にしないで良さそうです。

@zundan うちはDocker構成なんでDBコンテナのalpineにはglibc入ってないまであるのですが、まあいつのまにか重複データが混ざってたとかもありうるので…

@tateisu なるほど〜。Dockerだとホストのglibcが透けてきたりするんですね。確かにいつのまにか重複データができちゃったりしてそうです。僕もやっておこうかな…。

@zundan @tateisu その警告メッセージ怖すぎるので緩和しようぜ・なくそうぜとか、いやあった方がいい、とか話がありました(私は乗り遅れたのでかんでない)

実際には、アップデートしようとして、インデックスに更新が掛かるマイグレーションがあったときに重複レコードのせいでコケて発覚するパターンになりがちなので、できれば事前検出して対処したいところです……。

@noellabo @tateisu 事前検出…どれくらい素早くできるかに依りますよね (よく知らない←

@noellabo @zundan OSやコンテナ上のロケールデータが変わったタイミングで事故が起きるやつなので怖いですね…。まあデータなんていつのまにか壊れてるものなので、結局は定期的にこのコマンドを実行することになるのでしょうけど。

@zundan alpineでは glibc 互換の musl-libc が使われてますね。コチラに同様の問題があるのかは分かりません。

@tateisu なるほど!! musl-libcがどれくらいglibcとの互換性を保とうとしてるかに依りそうですね