No se puede restaurar porque sidekiq no suelta

Tengo un sitio en ejecución en ECS con RDS. Estoy intentando restaurar la base de datos (como se describe aquí: Restore failed `entity2char already exists' RDS Postgres 13.7 - #7 by RGJ).

El problema en este punto es que la copia de seguridad no se inicia porque se está pausando esperando a sidekiq. Afirma que está esperando 60 segundos, pero he esperado 60 minutos y nunca dejó de esperar.

Entonces decidí que eliminaría, crearía y migraría la base de datos antes de la restauración (estoy bastante seguro de que eso es lo que funcionó la última vez), pero todavía no puedo eliminar la base de datos porque 6 tareas la tienen abierta.

SELECT application_name,client_addr FROM pg_stat_activity;

Muestra esto (y hay 6 sidekiqs con conexiones activas)

 psql                                  | 10.3.2.155
 PostgreSQL JDBC Driver                | 127.0.0.1
                                       | 127.0.0.1
 sidekiq 6.5.8 discourse [0 of 5 busy] | 10.3.2.155
 sidekiq 6.5.8 discourse [0 of 5 busy] | 10.x.2.155
 sidekiq 6.5.8 discourse [0 of 5 busy] | 10.x.2.34
 sidekiq 6.5.8 discourse [0 of 5 busy] | 10.x.2.155
 sidekiq 6.5.8 discourse [0 of 5 busy] | 10.x.2.155
 sidekiq 6.5.8 discourse [0 of 5 busy] | 10.x.2.34

Una de esas direcciones es el ECS, la otra es un contenedor que inicié en un EC2. En ambos contenedores hice un sv stop unicorn, lo que en otros contextos ha sido suficiente para poder eliminar la base de datos.

Oh. Y ahora he detenido el contenedor en el EC2, ¿así que esas conexiones deben estar simplemente colgadas ya que se apagó sin cerrarlas? Quizás necesite reiniciar la base de datos de nuevo. (Reiniciar la base de datos detuvo esas conexiones, y ahora solo muestra conexiones inactivas del unicorn apagado).

¿Qué hago para matar a sidekiq? ¿Voy a redis y borro todo? (He hecho eso antes y puedo buscar en Google para entenderlo de nuevo).

Solo necesitas detener todas las instancias (contenedores, unicornios) que tengan un sidekiq en ejecución en su interior.

Eso es lo que hubiera pensado, pero incluso después de detener el contenedor que ejecuta sidekiq, postgres todavía mostraba conexiones activas. De manera similar, había hecho un sv stop unicorn en la instancia de ECS, pero postgres todavía mostraba conexiones activas.

Reinicié el servidor RDS, arranqué el contenedor en EC2 (las instancias en ECS no tienen suficiente espacio en disco para una restauración), sv stop unicorn, luego elimino, creo, restauro la base de datos y ahora estoy intentando una restauración.

Muchas gracias por tu ayuda. ¡Lo aprecio mucho!

1 me gusta