# Updaten ohne Downtime



## ThiKool (29. April 2015)

Hallo Community,

ich habe folgendes Problem:
Da ich häufig neue Funktionen auf meiner Homepage migriere, muss ich oft meine functions.php neu hochladen, was zu folge hat, dass in den ca. 2 Sekunden des Uploads die functions.php nicht verfügbar ist und Fehler wirft.

Welche sinnvolle Vorgehensweise könnte ich einführen, dass ich während eines Uploads keine derartigen Fehler bekomme?

Ginge das mit z.B. zwei Ordnern auf dem Server die per .htaccess und der base url angepasst werden?

Also sprich live ist Ordner1 und Ordner2 wird geupdated. Nach erfolgreichen Update wird die Base auf Ordner2 geändert und Ordner1 geupdated.

Aber selbst dabei muss ja die .htaccess geändert werden, wodurch diese wieder kurz offline wäre oder?

Danke euch.


----------



## sheel (29. April 2015)

Hi

Wenn du wirklich so viel Besucher hast, dass das auffällt (sonst ist das zu viel Aufwand):

* zuerst alles auf einem Testsystem machen, um offensichtliche Fehler vor Veröffentlichung gleich auszubessern

* nicht die Datei beim Upload gleich ersetzen, sondern zuerst mit einem anderen Namen uploaden, dann ein Script schreiben das alle zu ersetztenden Dateien löscht und die Neuen passend umbenennt, um dann beim Ausführen alles innerhalb kürzester Zeit zu machen.

* Änderungen an der Website in wenig besuchte Zeiten verlagern, zB. 03:00-04:00
(bzw. dann das Script starten lassen...)

* Wenns noch mehr sein darf, den Loadbalancer zwischen den Servern so einstellen, dass jedes Gerät pro Tag einen gewissen Zeitraum nciht verwendet wird (natürlich verschiedene Zeiträume pro Gerät)


----------



## ThiKool (29. April 2015)

Ok vielen Dank dafür.

Könnte ich auch alle neuen Daten in ein extra Verzeichnis laden (mit richtigen Namen) und sobald alles oben ist, es per Script auf das Livesystem verschieben lassen oder hätte ich damit den selben (langsamen) Effekt wie beim direkten Upload?


----------



## sheel (29. April 2015)

Anderes Verzeichnis statt anderem Namen geht natürlich auch
(rein technisch ists das Selbe, solangs auf der selben Festplatte ist.
Pfad + Sichtbarer Name == Echter Name)

Bzw. anderes Verzeichnis ist eigentlich besser, weil das Script dann einfacher ist
(einfach ganzen Ordner syncen)


----------



## ThiKool (29. April 2015)

Also einfach per copy funktion und script überschreiben lassen, sobald alles hochgeladen wurde?

Das ist dann schneller als per Upload zu überschreiben, weil ja alle Dateien fas parallel oder zumindest ziemlich schnell per copy bearbeitet werden oder?


----------



## sheel (29. April 2015)

Eigentlich ist es ja nur Löschen + Verschieben bzw. Löschen + Umbenennen, kein Kopieren, und
je nach System involviert das nicht einmal die Festplatte (zumindest nicht sofort; Metadatencache)

Und ja. Natürlich wirds nicht "viel" Unterschied, aber 2sec ist auch nicht viel.
Wenn die einen stören bekommt man sicher eine deutliche Verbesserung.
(vorausgesetzt, der Server ist nicht uralt)


----------



## ThiKool (29. April 2015)

Naja die Sache ist eigentlich die, dass dort Scripte drauf laufen, die eigentlich gar nicht und zu keiner Zeit unterbrochen werden sollten - sprich wenn mal ein db eintrag nicht geschrieben werden kann und somit fehlt wäre das schon fatal.


----------



## sheel (29. April 2015)

Naja, das ist aber plötzlich ein ganz anderes Problem.

a) ist das ein gewaltiger Designfehler. (Was passiert bei einem Stromausfall? Festplattenschaden? usw.usw.)
b) sollte das Dateiersetzen wie oben beschrieben (auf einem Linuxserver) nichts stören.
Das alte Script kann weiterlaufen, bis es einmal beendet wird
(nocheinmal, wenn das nicht beendet werden darf stimmt da was nicht)


----------



## ThiKool (29. April 2015)

Da habe ich mich dann wohl etwas falsch ausgedrückt.

Ich verstehe dich jetzt so:
Das DB Script läuft und schreibt etwas in die DB - ist das geschehen, ist das Script beendet.

Mein update-Script wartet automatisch so lange bist das db script beendet ist und führt dann copy aus?!

Während dessen ist das DB script nicht verfügbar, da es ja gerade ersetzt wird oder? - Dieses Ersetzen per copy geht aber wiederum so schnell, dass dieser Fall (db script wird angefordert und nicht gefunden) nicht auftritt?

Oder nochmal anders gesagt: Was ist wenn die copy läuft und in dem Moment ein User das DB Script aufruft?


----------



## sheel (29. April 2015)

Also, wie schon geschrieben muss das Ersetzscript nicht warten,
solangs um ein Linux geht und die neue Datei auf der selben Partition ist.

Das Umbenennen (bzw. Verschieben, und inkludiert auch Entfernen der alten Datei)
kann ohne Probleme während der Nutzung (der alten Datei) erfolgen.
Die nutzenden Programme haben auch weiterhin die alte Datei, die ja eigentlich
nicht mehr vorhanden ist, und können weiterhin darauf lesen, bis die Datei geschlossen
wird (wenn das PHP-Programm beendet ist). Beim nächsten Öffnen bekommt man dann den neuen Inhalt.

Das geht wie gesagt nicht mit Kopieren, nur mit Verschieben.

Und zu dem Fall, dass das Programm grad in dem Moment gestartet werden soll, wo ersetzt wird:
Passiert nicht, weil bei Linux garantiert ist, dass Dateiumbenennungen atomic sind.
Bedeutet, der Kernel kümmert sich drum, dass Apache/PHP beim Öffnen der PHP-Datei
etc. solang warten müssen, während die Umbenennung läuft, ohne dass die Software
irgendwas selber machen muss. Aus Softwaresicht wird das gar nicht bemerkt.


----------



## ThiKool (29. April 2015)

Ok vielen vielen Dank, dass hat mir sehr geholfen.

Also lade ich jetzt alles in einen Upload Ordner was sich ändern soll, dann geht ein script mit der copy funktion drüber und ersetzt sozusagen die originaldateien in einem rutsch, ohne das der User davon etwas mitbekommt?


----------



## sheel (29. April 2015)

Nocheinmal: Nicht kopieren.

NICHT kopieren.

Umbenennen (egal ob im gleichen Ordner oder nicht, Umbenennen==Verschieben)


----------



## ThiKool (29. April 2015)

Ah ok also so oder?:


```
rename("deployment/index.php", "index.php");
```

danke für deine Geduld


----------



## sheel (29. April 2015)

Genau 

Das Problem mit dem Kopieren ist, dass da ja essentiell der gesamte Dateiinhalt
gelesen und in die neue Datei geschrieben wird,
also Öffnen, irgendwie lesen/schreiben und wieder schließen.

(na gut, abhängig vom Dateisystem gehts evt. besser, weil die zwei
Dateien ja bis auf Weiteres den selben Inhalt haben. Egal.),

Wenn der Kernel da andere Aktionen auf der Datei derweil anhalten würde...
kann gar nicht funktionieren, weil das Kopieren selber ja auch aus blockierbaren Aktionen besteht.
Würde sich selber blockieren (und zusätzlich alle anderen Dateioperationen)

Umbenennen selber ändert nur den gespeicherten Pfad und Namen zu einem Datending.
Und auf Linux ist das eben so gemacht, dass nichts anderes (außerhalb vom Kernel)
dazwischen kommen kann.


----------



## ThiKool (29. April 2015)

Ich nochmal  Was würde denn ein SVN Tool machen? Auch stumpf überschreiben wie ein FTP Upload oder?


----------



## sheel (29. April 2015)

Ja, aber mit SVN bekommst du sogar noch mehr Probleme 

SVN ist nicht zur allgemeinen Dateiverwaltung gedacht.
Wenn du vom gesamten Inhalt eine Menge alte Kopien speichern
willst und dir jederzeit die Änderungen von Datei X zwischen Datum
Y und Z anzeigen lassen willst, das klingt nach einer Aufgabe für SVN.
Aber sonst...

(SVN zur Verwaltung der PHP-Dateien lokal, gern.
Aber in den Ordner, woraus Apache/PHP die Dateien nehmen? ...)


----------



## ThiKool (29. April 2015)

Hmm ja das klingt logisch.

Ich suche jetzt nur noch nach einer automatischen Möglichkeit, dass mir nur die geänderten files auf den Server in den deployment Ordner geladen werden. Denn wenn ich z.B. eine Woche an einer neuen Funktion arbeite, kann es ja passieren, dass ich nicht mehr genau weiß, welche Dateien nun alles geändert wurden.

Desshalb dachte ich an die Markierungen von SVN (also Ausrufezeichen oder Haken)


----------



## sheel (29. April 2015)

ThiKool hat gesagt.:


> Denn wenn ich z.B. eine Woche an einer neuen Funktion arbeite, kann es ja passieren, dass ich nicht mehr genau weiß, welche Dateien nun alles geändert wurden.


Deswegen macht SVN bei deinen lokalen Entwicklungsdateien Sinn 
(und zB. auch, damit man leichter findet, welche Änderungen einen aktuellen Bug verursacht haben)


sheel hat gesagt.:


> SVN zur Verwaltung der PHP-Dateien lokal, gern.


----------

