Nur als Info für alle: Versucht dieses Upgrade nicht zur Hauptverkehrszeit.
Das Upgrade auf 2.6.0b2 läuft auf unserem Server bereits seit weit über 40 Minuten, obwohl es normalerweise nur ein paar Minuten dauert und meist schon abgeschlossen ist, bevor man wieder nachschaut. Ich war besorgt, es könnte kaputt sein, aber beim Einloggen in Postgres sehe ich, dass eine riesige Aktualisierung läuft. Es scheint, als würde die Suchdaten für private Nachrichten aktualisiert.
Hoffentlich ist es nicht kaputt. Ich werde es wohl herausfinden. Ich will es auf keinen Fall abbrechen oder den Container während des Upgrades neu starten.
Ausgeführte Abfrage:
postgres=# SELECT pid, age(clock_timestamp(), query_start), usename, query
FROM pg_stat_activity
WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;
pid | age | usename | query
-------+-----------------+-----------+---------------------------------------------------------------------------
-------------------
698 | | |
701 | | postgres |
699 | | |
697 | | |
696 | | |
14572 | 00:10:31.484201 | discourse | UPDATE post_search_data
+
| | | SET private_message = X.private_message
+
| | | FROM
+
| | | (
+
| | | SELECT post_id,
+
| | | CASE WHEN t.archetype = 'private_message' THEN TRUE ELSE FALSE END pri
vate_message +
| | | FROM posts p
+
| | | JOIN post_search_data pd ON pd.post_id = p.id
+
| | | JOIN topics t ON t.id = p.topic_id
+
| | | WHERE pd.private_message IS NULL OR
+
| | | pd.private_message <> CASE WHEN t.archetype = 'private_message' THEN T
RUE ELSE FALSE END+
| | | LIMIT 3000000
+
| | | ) X
+
| | | WHERE X.post_id = post_search_data.post_id
+
| | |
14573 | 00:47:02.814489 | discourse | SELECT pg_try_advisory_lock(2859260972035668690)
(7 rows)
Das Upgrade war auch auf schneller, colokierter Hardware für mich ziemlich langsam. Ich bin mir nicht ganz sicher, warum, aber es ist definitiv etwas, das man beachten sollte.
Ja, ich schlage vor, im Changelog einen Hinweis zu hinterlassen, der warnt, dass dieses Update wahrscheinlich viel länger als die meisten anderen dauern wird, und dass man es nicht abbrechen oder drastische Maßnahmen ergreifen sollte, da dies erwartet wird.
Meine lokale Site hatte nicht so viele Beiträge und war dennoch ziemlich langsam. Nicht 40 Minuten langsam, aber merklich langsamer als bei früheren Upgrades, vielleicht um das 3- bis 4-fache?
Danke @Wingtip, ich dachte, das passiert nur bei uns!
Eigentlich musste ich den Neuaufbau abbrechen und die App neu starten, weil ich dachte, sie sei bei der von dir erwähnten Abfrage hängengeblieben. Wir haben 6 Millionen Beiträge, und nach etwa 45 Minuten war der Vorgang immer noch nicht abgeschlossen. Ich werde also wohl für mindestens eine Stunde Neuaufbau Zeit einplanen und unsere Nutzer vorher warnen müssen.
Ich habe gerade eine Stoppuhr gezückt und einen Neuaufbau getestet (eine Site mit etwa 1 Million Beiträgen) von 2.6.0b1 auf b2; von Anfang bis Ende dauerte es 170 Sekunden.
Ich benutze den Docker-Manager ebenfalls nicht und bevorzuge das Neuaufbauen über die Kommandozeile. So kann man im Fehlerfall besser die Protokolle einsehen. Ich finde es auch schneller.
Ich habe (in meinem Irrtum) über die Webkonsole aktualisiert, sodass ich die ganze Zeit kein aktuelles Log hatte. Das werde ich mir zum letzten Mal als Fehler anrechnen.
Ich hatte eine große Site, die wiederholt beim Bootstrapping gescheitert ist. Es handelt sich um eine Installation mit zwei Containern, sodass der alte Container weiterlief, während das Bootstrap die Migration durchführte. Schließlich habe ich das Problem gelöst, indem ich SKIP_POST_DEPLOYMENT_MIGRATIONS=1 für das Bootstrap aktiviert und die Migrationen erst ausgeführt habe, nachdem der neue Container hochgefahren war. Mit SKIP_POST_DEPLOYMENT_MIGRATIONS=1 im ENV-Abschnitt war die Migration sehr schnell, und die Site konnte während der Migration (die, glaube ich, über 20 Minuten dauerte) normal funktionieren, wenn auch möglicherweise etwas langsamer.
Ich denke, habe es aber noch nicht getestet, dass derselbe Trick auch die Ausfallzeit bei einer Installation mit einem einzigen Container minimieren würde. Wenn ich recht habe, würde man folgendermaßen vorgehen:
SKIP_POST_DEPLOYMENT_MIGRATIONS=1 in deine app.yml einfügen
Die Änderung in app.yml rückgängig machen, es sei denn, du planst, nach jedem Upgrade die Migrationen manuell durchzuführen
Vielleicht erneut neu aufbauen, um sicherzustellen, dass du keine Probleme hast, solange du noch weißt, was deine Site beschädigt haben könnte. Denn wenn du es erst in vier Monaten wieder versuchst, wirst du keine Ahnung haben, und es wird für jeden schwer sein, das Problem zu erraten.
Wenn es eine Möglichkeit gäbe, ./launcher so zu konfigurieren, dass es SKIP_POST_DEPLOYMENT_MIGRATIONS=1 an die entsprechenden Prozesse übergibt, ohne eine Änderung an der app.yml vorzunehmen, wäre das für diejenigen, die mit Editoren Schwierigkeiten haben, weniger umständlich.
Wenn ich es schaffe, die Arbeit daran zu erledigen, die ich vorhatte, werde ich ein neues Thema erstellen und berichten, was ich herausgefunden habe. Der Rauch hat mich jedoch in einen Raum eingesperrt, in dem ich meinen großen Monitor nicht habe. (Die Pandemie reichte also nicht? Wir müssen auch noch Rauch ertragen? Und ich bin dem verdammten Feuer nicht einmal besonders nahe.)
Das sind fantastische Neuigkeiten! (Zwei andere Projekte haben mir heute in die Quere gekommen und irgendwie funktioniert meine Multisite-Instanz nicht mehr richtig mit S3 zusammen. ) Vielen Dank!
Gibt es einen technischen Grund, warum Datenbankänderungen nach dem Upgrade standardmäßig blockierend sein müssen? Gibt es eine Möglichkeit, dieses Verhalten so zu ändern, dass der Server nach zukünftigen Upgrades schnell wieder verfügbar ist und die nachgelagerten Schritte im Hintergrund ausgeführt werden?
Meiner Meinung nach sollten alle für die Funktionsfähigkeit der aktualisierten Anwendung essenziellen Änderungen, wie z. B. DDL, direkt Teil des Upgrades selbst sein und nicht in nachgelagerten Skripten stehen.
Edit: Inzwischen habe ich den Prozess beendet, damit die Seite wieder für unsere Nutzer verfügbar ist. Aber es muss einen besseren Weg geben, dieses Update durchzuführen.
) Vielen Dank!