今日は重複レコードの対処で終わってしまった……。まぁ、こういうのも大事なり。
たぶん、ThibGさんが安全な修復方法(重複アカウントのマージ)を提示してくれるはず……ぱたり。
主に、Fediverseへの関心に基づいた投稿を行うアカウントです。DTP・印刷に関する話をしたり、同人の話をしたり、カレーをブーストしたりします。
Mastodonのcollaborator(開発者の一員)です。また、独自機能を盛り込んだFedibirdを管理・開発しています!
Mastodonサーバ『fedibird.com』の管理者アカウントでもあります。ご連絡は当アカウントへ、サーバインフォメーションについては https://fedibird.com/about/more と @info を参照してください。
今日は重複レコードの対処で終わってしまった……。まぁ、こういうのも大事なり。
たぶん、ThibGさんが安全な修復方法(重複アカウントのマージ)を提示してくれるはず……ぱたり。
このアカウントは、notestockで公開設定になっていません。
これ、普通は発生しないんですが、Mastodonのデータベースから不用意にインデックスを削除したとか、何かそういう理由で、重複レコードが出来てしまうことがあります。
今回、Mastodon v3.2.0へのマイグレーションで、accountsテーブルのusernameとdomainを小文字に変換してユニーク制約のついたインデックスを張り直すっていうのがあるんですが、そこでいくつかの管理者がエラーになったようで、issueがあがっています。
https://github.com/tootsuite/mastodon/issues/14443
トラブルシューティングなので、マイグレーション書き換えたり、SQL飛ばしたり、rails console使ったり、色々やってます。状況としてはマジヤベーんですが、結構面白いですw
教訓としては、ユニークインデックス張る前に、チェックぐらいは入れた方がよさそう、というところです……。
Mastodon 腐った DB 矯正メモ (2020-05-05) by らりお
https://gist.github.com/lo48576/3fc718124de4e22b97d22568031f12dc
Mastodon の DB が腐っていたのを修正したメンテナンスのメモです。 #mastodon
cf.
https://mastodon.cardina1.red/@lo48576/104113951825779459
https://mastodon.cardina1.red/@lo48576/103974978595397759
https://mastodon.cardina1.red/@lo48576/103974987462202016
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Mastodonのサーバを管理されている方へ
PgHero(管理から入れるPostgreSQLのダッシュボード)で、Duplicate Indexesを指摘されたり、Space(テーブルやインデックスの使用容量の一覧)でインデックスにUNUSEDがついていたりすると思いますが、
_人人人人人人人人人_
> インデックスを <
> 削除しないで! <
 ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^ ̄
インデックスを含めたデータベースのスキーマは、Mastodon本体のソースコードの中で、RailsのActive Recordの仕組みを使って変更を管理しています。その管理されている状態と一致しなくなると、いずれかの時点でdb:migrateできなくなって詰みます。
また、インデックスは、データベースの検索を高速にするだけでなく、同じキーを持つデータが重複しないようにする役割もあります。
滅多に使われないインデックスでも、それが無くなるとデータベースの整合性が壊れます。
データベース構造の変更は、本家のGithubにissueをあげたり、pull-requestを経て行いましょう。
これ、普通は発生しないんですが、Mastodonのデータベースから不用意にインデックスを削除したとか、何かそういう理由で、重複レコードが出来てしまうことがあります。
今回、Mastodon v3.2.0へのマイグレーションで、accountsテーブルのusernameとdomainを小文字に変換してユニーク制約のついたインデックスを張り直すっていうのがあるんですが、そこでいくつかの管理者がエラーになったようで、issueがあがっています。
https://github.com/tootsuite/mastodon/issues/14443
トラブルシューティングなので、マイグレーション書き換えたり、SQL飛ばしたり、rails console使ったり、色々やってます。状況としてはマジヤベーんですが、結構面白いですw
教訓としては、ユニークインデックス張る前に、チェックぐらいは入れた方がよさそう、というところです……。
こちらの件、続報としましては、
https://fedibird.com/@noellabo/104586678477507551
同じ名前のアカウントが重複してしまって、整合性が破綻しているので、そのままでは修復不能になっていました。
そこで、主要開発者の一人(ThibGさん)が、おかしくなった状態を再統合するためのRubyのコードを書いて、論理的に修復を図る形でなんとか解決に向かっています。
怖いですねえ、恐ろしいですねえ
それではissueをご期待ください。さよなら、さよなら、さよなら・・・
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
いま問題が起きている人の全員が、手動でインデックスを削除しちゃったことが原因だったらいいんですが、
_人人人人人人人人人人人_
> なにもしてないのに <
> 壊れた <
 ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^ ̄
だとヤバイですよね……。
mastodon.cloudも、最初の管理者の手元の段階でデータベースぶっ壊れで、引き継ぐときに直すの大変だったって話。
masto.hostとかHostdonとか、自分で管理していたサーバのDBを預けて、管理してもらうスタートの仕方をする場合あるけど、壊れてるDB引き継いじゃうと大変だよね……。
・自鯖(サーバプロセス)
・自鯖(WebUI)
・他鯖のWeb
・リモートサーバ(連合先)
・クライアントアプリ
かな。
CORS意識するのはWebUIを表示するブラウザぐらいで、他はみてないと思う()
クライアントアプリは、他鯖の画像を自鯖から取得せずにリモートを直接みにいっちゃうものが結構ある(けどCORS……)。PleromaやMisskey、キャッシュしないで直接見に行かせちゃう場合あるんじゃないかな。
プロキシが間に入る場合は、S3のヘッダを隠して、プロキシがヘッダを付け直す感じ?
https://docs.joinmastodon.org/admin/optional/object-storage-proxy/
proxy_hide_header 'Access-Control-Allow-Origin';
proxy_hide_header 'Access-Control-Allow-Methods';
proxy_hide_header 'Access-Control-Allow-Headers';
add_header 'Access-Control-Allow-Origin' '*'
@kedama @zundan Mastodonは、人知れずMediaProxyのエントリがあって、再取得が必要なメディアのstatusではプロキシのURLを返しています。
ユーザーがプロキシにアクセスすると、RedownloadMediaWorkerを走らせて再取得を行って、本来のローカルURLにリダイレクトするという処理を行います。
この仕組みで、media removeで消しちゃったり、壊れている画像をクリックしても、ローカルのURLが返るようになっています。
クライアントアプリは、このへんを無視して、リモートを直接見に行くものがあります。
ユーザーとしては画像がちゃんと表示されて嬉しかったりするんですが、どんな画像を読まされるかわからないのと、トラッキング防止になりません。逆に、本体が対応していないメディア形式でも読めたりします。
@kunimi53chi mstdn.jpとtakumi.funはマルチポストだよね。 @itsumonotakumi だけフォローさせてもらってるけど。
@kunimi53chi Pawooもあったか、そういえば。
takumi.funって色々設定厳し目で運用してたと思うけど、実は弾かれてる?
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@sublimer Eugenさんが書いてくれた新しいドキュメントで https://docs.joinmastodon.org/admin/optional/object-storage-proxy/ が設定例ですが、
proxy_hide_header 'Access-Control-Allow-Origin';
proxy_hide_header 'Access-Control-Allow-Methods';
proxy_hide_header 'Access-Control-Allow-Headers';
という感じで、オブジェクトストレージ側の出力を隠した上で、
add_header 'Access-Control-Allow-Origin' '*';
としていますね。
このアカウントは、notestockで公開設定になっていません。
食べてたカレーはこれ(どうでもいい情報) ▶ 素材を生かしたカレー ジンジャードライキーマ 180g(1人前) 通販 | 無印良品 https://www.muji.com/jp/ja/store/cmdty/detail/4550002850050
RE: https://ms.kvche.ch/notes/8a9bksdr0q
このアカウントは、notestockで公開設定になっていません。
究極的には
・自分でノードを所有できる
・ソースコードを変更できる
ことが、Fediverseの強み。
それ以外のことは、比較してもあまり意味はないよ。
@aries いや、先頭から件数絞っているから、クライアントでは無理。
Elasticsearchのスコアリングで順番決める方向にしたんでしょう。
@yamo これ……www
@h3poteto この件、ご確認願います。
https://dtp-mstdn.jp/@yamo/104592000348566978