יש לנו פורום שבו לטבלה user_auth_token_logs יש 61 מיליון רשומות (והיא גדלה).
יש רק 25 אלף user_auth_tokens.
מתוך 61 מיליון הרשומות, 54 מיליון רשומות מתייחסות ל-user_auth_token שכבר לא קיים (כלומר, בעיית שלמות נתונים). ומתוך 61 מיליון הרשומות, כ-58 מיליון הן בנות יותר מחודשיים (כלומר, חסרות תועלת לכאורה?)
שאלות:
האם נוכל פשוט לנקות את זה מבלי לסכן בעיות שלמות נוספות?
האם תהיה רעיון שיהיה תהליך שינקה את זה אוטומטית?
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
Yes, user_auth_token_logs are there only for debugging purposes. All rows can be emptied, the only consequence will be that you won’t have any logs to debug.
Ah yes, good catch. Looks like lines 214 to 217 need fixing as well.
I would be comfortable with a global cleanup after a certain timeframe. @osama (since you’re the author of the commit linked above), do you think we can clean up all of these logs after some time (and if so, after how long)? It sounds like we need to keep some of them for detecting suspicious logins.
Why does it need fixing? That piece of code is about cleaning up rotated UserAuthTokens, not about the log records?
Update: after enabling SiteSetting.verbose_auth_token_logging, triggering the weekly job and running VACUUM FULL user_auth_token_logs the table went from 16GB to 687MB
Yes, I think we can clean up most of the logs, but some of them have to stay. Specifically, I think any records that have suspicious, generate, or rotate for action will need to be kept around because they’re used for detecting and generating reports for suspicious logins.
The original implementation only logged when SiteSetting.verbose_auth_token_logging is true. Which still had the problem that after disabling it, the most recent remaining logs would stay, but that’s a small thing.
But this change made the logging unconditional (“The generate, rotate and suspicious auth token logs are now always logged regardless of the verbose_auth_token_logging setting”).
TLDR; That change forgot to make the removal unconditional as well.
אכן, אותו PR אושר כעת בזכות @Osama. הוא מטפל ברוב סוגי user_auth_token_logs, אך לא בכולם, אנו נמשיך עם תיקון עבור ערכי generate בקרוב. (ראה את הדיון בקישור ה-PR למעלה להקשר נוסף).