Abbiamo un forum in cui user_auth_token_logs ha 61 milioni di righe (e in crescita).
Ci sono solo 25 mila user_auth_tokens.
Delle 61 milioni di righe, 54 milioni di righe si riferiscono a un user_auth_token che non esiste più (cioè un problema di integrità del database). E delle 61 milioni di righe, circa 58 milioni hanno più di 2 mesi (cioè apparentemente inutili?)
Domande:
Potremmo semplicemente ripulire questo senza rischiare ulteriori problemi di integrità?
Sarebbe un’idea avere un job che ripulisca automaticamente?
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
Sì, user_auth_token_logs sono lì solo a scopo di debug. Tutte le righe possono essere svuotate, l’unica conseguenza sarà che non avrai log da cui eseguire il debug.
Ah sì, buona osservazione. Sembra che anche le righe da 214 a 217 debbano essere corrette.
Sarei a mio agio con una pulizia globale dopo un certo periodo di tempo. @osama (dato che sei l’autore del commit collegato sopra), pensi che possiamo ripulire tutti questi log dopo un po’ di tempo (e se sì, dopo quanto)? Sembra che dobbiamo conservarne alcuni per rilevare accessi sospetti.
Perché deve essere corretto? Quel pezzo di codice riguarda la pulizia dei UserAuthToken ruotati, non i record di log?
Aggiornamento: dopo aver abilitato SiteSetting.verbose_auth_token_logging, aver attivato il job settimanale ed eseguito VACUUM FULL user_auth_token_logs, la tabella è passata da 16GB a 687MB
Sì, penso che possiamo ripulire la maggior parte dei log, ma alcuni devono rimanere. Nello specifico, penso che qualsiasi record che abbia suspicious, generate o rotate per azione dovrà essere conservato perché viene utilizzato per rilevare e generare report per accessi sospetti.
Sto vedendo sul mio forum che questo bug non è mai stato corretto :occhi:
Il report dei login sospetti sembra applicarsi solo ai membri dello staff, c’è un motivo per cui questi log devono essere conservati per i non amministratori?
Affinché il report funzioni, ha bisogno di dati dall’inizio della cronologia dell’account? Il log può essere abbreviato a qualcosa come gli ultimi 6 mesi?
Al momento non c’è alcuna pulizia, il che è una preoccupazione per la privacy.
Non capisco nemmeno io la discussione di cui sopra.
Il bug è molto semplice: se la modalità non è verbosa, non viene eseguita alcuna pulizia di UserAuthTokenLog, mai. L’if deve essere rimosso.
L’implementazione originale registrava solo quando SiteSetting.verbose_auth_token_logging era vero. Il che aveva ancora il problema che dopo averlo disabilitato, i log rimanenti più recenti sarebbero rimasti, ma è una piccola cosa.
Ma questa modifica ha reso la registrazione incondizionata (“I log dei token di autenticazione generate, rotate e suspicious vengono ora sempre registrati indipendentemente dall’impostazione verbose_auth_token_logging”).
TLDR; quella modifica ha dimenticato di rendere incondizionale anche la rimozione.
Certamente risolveremo il problema nelle prossime settimane, se c’è urgenza sentiti libero di inviare una pull request (che sia testata e confermi che funzioni come previsto).
In effetti, quella PR è ora unita grazie a @Osama. Affronta la maggior parte dei tipi di user_auth_token_logs, ma non tutti; seguirà presto una correzione per le voci generate. (Vedi la discussione nel link della PR sopra per maggiori dettagli).
Manterrò aperto questo argomento mentre affrontiamo il seguito.
Quel pezzo di codice riguarda la pulizia dei 
