Hola Comunidad,
Estamos utilizando la API de Discourse en una instalación autoalojada. Nuestro caso de uso es bastante intensivo en términos de concurrencia, con alrededor de 100 solicitudes de API por segundo en promedio. También estamos utilizando PostgreSQL+Patroni+HAProxy para proporcionar una configuración de base de datos de alta disponibilidad. Ocasionalmente, nuestro PostgreSQL se bloquea y Patroni reinicia el nodo maestro.
Hemos implementado un trabajo cron para verificar las transacciones bloqueadas y, cada vez que ocurre este problema, encontramos el mismo tipo de operaciones:
blocked_pid | blocked_user | blocking_pid | blocking_user | blocked_statement | current_statement_in_blocking_process
-------------+--------------+--------------+---------------+------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------
297904 | discourse | 293083 | discourse | UPDATE "api_keys" SET "last_used_at" = '2024-07-16 16:38:16.822352' WHERE "api_keys"."id" = 21 | UPDATE "api_keys" SET "last_used_at" = '2024-07-16 16:34:48.163449' WHERE "api_keys"."id" = 21
296718 | discourse | 293083 | discourse | UPDATE "api_keys" SET "last_used_at" = '2024-07-16 16:34:50.900480' WHERE "api_keys"."id" = 21 | UPDATE "api_keys" SET "last_used_at" = '2024-07-16 16:34:48.163449' WHERE "api_keys"."id" = 21
293101 | discourse | 293083 | discourse | UPDATE "api_keys" SET "last_used_at" = '2024-07-16 16:34:49.485074' WHERE "api_keys"."id" = 21 | UPDATE "api_keys" SET "last_used_at" = '2024-07-16 16:34:48.163449' WHERE "api_keys"."id" = 21
Como pueden ver, muchas solicitudes intentan actualizar la hora de la última 사용 (uso) de la misma clave de API.
Por ahora, hemos aumentado el número de claves de API que nuestra aplicación está utilizando para reducir la probabilidad de colisión. Noté que hay código implementado que verifica si la clave de API se modificó en el último minuto para evitar una actualización. Sin embargo, supongo que, dado que estamos usando más de un pod para procesar las solicitudes, esta protección no es efectiva.
No estoy seguro de si deberíamos informar esto como un error o si hay algún parámetro para evitar este tipo de colisión (ya sea en Discourse o PostgreSQL). Tengan en cuenta que para nosotros, la información relacionada con la última 사용 (uso) es relevante, pero una resolución de 1 día sería suficiente.
También me gustaría saber cuál es el enfoque preferido para gestionar la alta disponibilidad de PostgreSQL con recuperación automática.
Gracias