RGJ
2024 年 9 月 13 日午後 5:30
1
私たちのフォーラムでは、user_auth_token_logs に 6100 万行 (増加中) があります。
user_auth_tokens は 25,000 しかありません。
6100 万行のうち、5400 万行はもはや存在しない user_auth_token を参照しています (つまり、データベースの整合性の問題です)。また、6100 万行のうち、約 5800 万行は 2 か月以上前のものです (つまり、明らかに不要ですか?)。
質問:
これをさらに整合性の問題を引き起こすリスクなしにクリーンアップできますか?
これを自動的にクリーンアップするジョブを設けるのはどうでしょうか?
db=# select count(*) from user_auth_tokens;
count
-------
25648
db=# select count(*) from user_auth_token_logs;
count
----------
61415352
db=# select count(*) from user_auth_token_logs where user_auth_token_id not in (select id from user_auth_tokens);
count
----------
54558442
db=# select count(*) from user_auth_token_logs where created_at < '2024-07-13';
count
----------
58565943
「いいね！」 4
pmusaraj
2024 年 9 月 13 日午後 6:22
3
はい、user_auth_token_logs はデバッグ目的でのみ存在します。すべての行を空にしても、デバッグ用のログがなくなるという結果になるだけです。
これは以下でカバーされるはずです。
https://github.com/discourse/discourse/blob/main/app/jobs/scheduled/weekly.rb#L13
「いいね！」 2
RGJ
2024 年 9 月 13 日午後 7:07
5
それをありがとうございます。私はそれがそこにあることに気づきませんでした。
したがって、verbose_auth_token_logging が true（このインスタンスではそうではありません）の場合にのみ、クリーンアップが実行される のですか？
しかし、非冗長ログは設定に関係なく常に発生します
8fb823c による
これを Bug
「いいね！」 4
pmusaraj
2024 年 9 月 13 日午後 7:45
6
ああ、よく気がつきましたね。lines 214 to 217 も修正が必要なようです。
一定期間経過後に全体的なクリーンアップを行うことに抵抗はありません。@osama （上記のコミットの作成者であるあなた）、これらのログをすべて一定期間後にクリーンアップすることは可能でしょうか（可能であれば、どのくらいの期間後でしょうか）？ 不審なログインを検出するために、いくつか保持する必要があるようです。
「いいね！」 4
RGJ
2024 年 9 月 13 日午後 10:16
7
なぜ修正が必要なのですか？ UserAuthToken をクリーンアップするためのものではありませんか？
更新：SiteSetting.verbose_auth_token_logging を有効にし、週次ジョブを実行して VACUUM FULL user_auth_token_logs を実行した後、テーブルは 16GB から 687MB になりました
今日は木を節約しました
「いいね！」 3
Osama
2024 年 9 月 16 日午後 8:15
8
はい、ほとんどのログはクリーンアップできると思いますが、いくつか残す必要があります。具体的には、suspicious、generate、またはrotateをアクションとするレコードは、不審なログインの検出やレポートの生成に使用されるため、保持する必要があると思います。
title: I18n.t("reports.suspicious_logins.labels.login_time"),
},
]
report.data = []
sql = <<~SQL
SELECT u.id user_id, u.username, u.uploaded_avatar_id, t.client_ip, t.user_agent, t.created_at login_time
FROM user_auth_token_logs t
JOIN users u ON u.id = t.user_id
WHERE t.action = 'suspicious'
AND t.created_at >= :start_date
AND t.created_at <= :end_date
ORDER BY t.created_at DESC
SQL
DB
.query(sql, start_date: report.start_date, end_date: report.end_date)
.each do |row|
data = {}
Math.sin((lat2_rad - lat1_rad) / 2)**2 +
Math.cos(lat1_rad) * Math.cos(lat2_rad) * Math.sin((lon2_rad - lon1_rad) / 2)**2
c = 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1 - a))
c * EARTH_RADIUS_KM
end
def self.is_suspicious(user_id, user_ip)
return false unless User.find_by(id: user_id)&.staff?
ips = UserAuthTokenLog.where(user_id: user_id).pluck(:client_ip)
ips.delete_at(ips.index(user_ip) || ips.length) # delete one occurrence (current)
ips.uniq!
return false if ips.empty? # first login is never suspicious
if user_location = login_location(user_ip)
ips.none? do |ip|
if location = login_location(ip)
distance(user_location, location) < SiteSetting.max_suspicious_distance_km
end
end
「いいね！」 3
フォーラムでこのバグが修正されていないのを見かけました
「いいね！」 2
RGJ
2025 年 8 月 8 日午後 4:31
13
上記の議論も理解できません。
バグは非常に単純です。モードが冗長でない場合、UserAuthTokenLog のクリーンアップはまったく実行されません。if を削除する必要があります。
元の実装では、SiteSetting.verbose_auth_token_logging が true の場合にのみログが記録されていました。これは、無効にした後でも、最も最近残っているログはそのまま残るという問題がありましたが、それは些細なことです。
しかし、この変更 により、ログ記録は無条件になりました（「* generate、rotate、suspicious の認証トークンログは、verbose_auth_token_logging 設定に関係なく常にログに記録されるようになりました*」）。
TLDR; その変更では、削除も無条件にすることを忘れていました。
「いいね！」 3
sam
2025 年 8 月 11 日午前 2:47
14
かしこまりました。今後数週間で解決いたします。お急ぎの場合は、プルリクエスト（テスト済みで期待どおりに動作することを確認したもの）をお送りください。
「いいね！」 1
RGJ
2025 年 8 月 13 日午前 10:05
17
pmusaraj
2025 年 8 月 14 日午後 5:13
20
はい、そのPRは@Osamaのおかげでマージされました。user_auth_token_logsのほとんどのタイプに対応していますが、すべてではありません。近日中にgenerateエントリの修正を行う予定です。（詳細については、上記のPRリンクでの議論を参照してください）。
フォローアップに対応している間、このトピックは開いたままにしておきます。
「いいね！」 4
そのコードはログレコードに関するものではなく、ローテーションされた 
