Deployment: Migrations pod wird lange nicht fertig

[amaierhofer]

Beim letzten Prod deployment hatte wir eine lange downtime (10 bis 15 minuten), da der Migrations pod nicht in den running state gewechselt hat. Siehe auch https://sentry.puzzle.ch/pitc/hitobito-backend/issues/73956/?environment=production

Wir nehmen an, dass es daran lag, dass gewisse queries, die Query, die der migrations pod absetzt blockiert haben. Anbei ein Auszug aus den queries, die die DB um den deployment Zeitpunkt herum gelogged hat Explore-logs-2025-01-03 15_09_26.json
(❯ cat ~/Downloads/Explore-logs-2025-01-03\ 15_09_26.json | jq '.[].fields | {session_start,timestamp,statement} ' | less)

Folgendes muss geklärt werden

• Ist dieses Problem SAC spezifischen oder sind anderen ebefalls betroffen
• Ist der aktuelle Approach (die search columns zu generieren) für Produktive Deployments der richtige
• Könnten die Migrations unabhängig vom deployment der Rails Applikation laufen (ev in rails deployment integrieren und rolling update machen)?

[amaierhofer]

Bester Anhaltspunkt scheinen die DB Connections zu sein, wo zum fraglichen Zeitpunkt keine idle connections mehr verfügbar waren

Aktuell ist wieder ein Mailinglist Export am laufen (seit 12:19) und zeigt im Grafana ein ähnliches Bild

eventuell sind mehrere Jobs mit lang laufenden queries zu diesem Zeitpunkt aktiv gewesen und das hat die anderen Queries, die abgesetzt werden wenn die Applikation startet blockiert.

Ein wichtiger Schritt wäre sicher, die lang laufenden Queries loszuwerden siehe dazu #1470

Des weiteren wurde geklärt, dass die Seach columns via rake im Anschluss an den wagon migrate task laufen

[kronn]

Die Migrations wurden bewusst in ein eigenes Deployment geschoben.

Damit wird vermieden, dass mehrere gleichzeitig startenden Pods sich gegenseitig blockieren (ansonsten bekommt man vermeidbare ActiveRecord::ConcurrentMigrationErrors). Das gleichzeitige Starten von Pods ist kein Ausnahmefall, sondern in Wartungsfenstern und grösseren Skalierungsänderunge normal.

Der Start des neuen Images wird durch einen InitContainer verzögert, bis alle benötigten Migrations geladen sind (rake bleib:wait_for_migrations).

Da das Erzeugen der SearchColumns nach den Migrations passiert, wird die App hiervon nicht zurückgehalten. Ähnliches gilt für die production-seeds, welche zwar im "Migrations"-Deployment laufen, aber die App nicht aufhalten. Wenn die Migrations im gleichen Pod wie die Rails-App als InitContainer laufen, dauert es also länger bis die App starten kann.

[amaierhofer]

Beim Release vom 13.12 ist das Problem erneu aufgetreten, Issue findet sich ebenfalls in Sentry https://sentry.puzzle.ch/pitc/hitobito-backend/issues/74115. Beobachtetes Verhalten war wieder analog, dh Migrations Pod braucht sehr lange, dazwischen starten rails und dj pods neu und hängen (bis migrations fertig sind). Mitunter ist der rails pod auch im Ready State aber beantwortetet die Requests scheinbar nicht richtig

Da das deployment lange gestanden ist, bin ich dann aktiv geworden, habe pods gelöscht und djs runter skaliert und am Ende auch lang laufenden queries auf der DB von hand gekilled. Dabei habe ich beobachtet, dass unmittelbar nach dem Killen der ersten query aus dem pending-group-queries.txt file das drop der group search column in der migration abschlossen werden konnte. Anschliessend sind pods normal hochgekommen gestartet.

Pattern bei den DB connections ist wieder das gleiche, es scheinen konstant (blockierende?) queries aktiv zu sein und dann kommt ein spike beim deployment (ca 12:00)

[amaierhofer]

Neuerliches Deployment heute abend lief problemlos, dabei wurden vorgängig die lang laufenden Subscription export queries gekilled

[amaierhofer]

Der performance für den SubscriptionsExport (#1470) wurde deployed, damit ist das Problem hoffentlich gelöst.