Tenemos un foro donde user_auth_token_logs tiene 61 millones de filas (y creciendo).
Solo hay 25k user_auth_tokens.
De las 61 millones de filas, 54 millones de filas se refieren a un user_auth_token que ya no existe (es decir, un problema de integridad de la base de datos). Y de las 61 millones de filas, alrededor de 58 millones tienen más de 2 meses (es decir, ¿aparentemente inútiles?).
Preguntas:
¿Podríamos simplemente limpiar esto sin arriesgarnos a más problemas de integridad?
¿Sería una buena idea tener un trabajo que limpie esto automáticamente?
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 están ahí solo para fines de depuración. Se pueden vaciar todas las filas, la única consecuencia será que no tendrás registros para depurar.
Ah sí, bien visto. Parece que las líneas 214 a 217 también necesitan arreglarse.
Estaría cómodo con una limpieza global después de un cierto período de tiempo. @osama (ya que eres el autor del commit enlazado arriba), ¿crees que podemos limpiar todos estos registros después de un tiempo (y si es así, después de cuánto)? Suena a que necesitamos conservar algunos de ellos para detectar inicios de sesión sospechosos.
¿Por qué necesita arreglarse? Ese fragmento de código trata sobre la limpieza de UserAuthToken rotados, ¿no sobre los registros del log?
Actualización: después de habilitar SiteSetting.verbose_auth_token_logging, activar el trabajo semanal y ejecutar VACUUM FULL user_auth_token_logs, la tabla pasó de 16 GB a 687 MB
Sí, creo que podemos limpiar la mayoría de los registros, pero algunos deben permanecer. Específicamente, creo que cualquier registro que tenga suspicious, generate o rotate como acción deberá conservarse porque se utilizan para detectar e generar informes de inicios de sesión sospechosos.
Veo en mi foro que este error nunca se corrigió :ojos:
El informe de inicios de sesión sospechosos parece aplicarse solo a los miembros del personal, ¿hay alguna razón por la que estos registros deban conservarse para los no administradores?
Para que el informe funcione, ¿necesita datos desde el principio del historial de la cuenta? ¿Se puede acortar el registro a algo como los últimos 6 meses?
En este momento no hay ninguna limpieza, lo que es una preocupación de privacidad.
Tampoco entiendo la discusión anterior.
El error es muy simple: si el modo no es detallado, entonces no se realiza ninguna limpieza de UserAuthTokenLog, nunca. El if debe desaparecer.
La implementación original solo registraba cuando SiteSetting.verbose_auth_token_logging era verdadero. Lo cual todavía tenía el problema de que después de deshabilitarlo, los registros restantes más recientes permanecerían, pero eso es algo pequeño.
Pero este cambio hizo que el registro fuera incondicional (“Los registros de tokens de autenticación generate, rotate y suspicious ahora se registran siempre independientemente de la configuración verbose_auth_token_logging”).
En resumen; ese cambio olvidó hacer que la eliminación también fuera incondicional.
Claro, lo resolveremos en las próximas semanas. Si hay prisa, no dude en enviar una solicitud de extracción (que esté probada y confirme que funciona como se espera).
De hecho, esa PR ahora está fusionada gracias a @Osama. Aborda la mayoría de los tipos de user_auth_token_logs, pero no todos, haremos un seguimiento con una solución para las entradas de generate en breve. (Ver la discusión en el enlace de la PR anterior para más contexto).
Mantendré este tema abierto mientras abordamos el seguimiento.
Ese fragmento de código trata sobre la limpieza de 
