Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Servermigration ist der Prozess, eine Anwendung, Website oder Datenbank auf neue Hardware, einen neuen Anbieter oder eine neue Cloud-Infrastruktur zu verschieben, und kann ohne sorgfältige Planung stundenlange Ausfallzeiten verursachen. Dieser Leitfaden erklärt DNS-TTL, Blue-Green-Deployment und Datenbankreplikation und führt Schritt für Schritt durch eine Migration mit nahezu null Ausfallzeit, vom Inventar bis zur endgültigen DNS-Umschaltung.
Ein ausfallfreier Umzug ist nur durch die richtige Kombination von vier Grundkonzepten möglich.
Die TTL bestimmt, wie lange ein DNS-Eintrag von Browsern und Resolvern zwischengespeichert wird; eine vor der Migration gesenkte TTL verkürzt die DNS-Ausbreitungszeit im Moment der Umschaltung.
Ein Deployment-Modell, bei dem die alte (Blue) und die neue (Green) Umgebung gleichzeitig laufen und der Traffic mit einer einzigen Änderung, DNS oder Load Balancer, auf die neue Umgebung umgeschaltet wird.
Eine kontinuierliche inkrementelle Synchronisierung von der Quelldatenbank zur Zieldatenbank sorgt dafür, dass im Moment der Umschaltung nur noch eine Differenz von wenigen Sekunden geschlossen werden muss.
In einem Wartungsfenster wird die Website vorübergehend schreibgeschützt oder nicht erreichbar gemacht; eine echte Null-Ausfallzeit-Migration läuft ununterbrochen weiter, einschließlich Schreibvorgängen, ohne dass Nutzer etwas bemerken.
Jede Minute Ausfallzeit während einer Migration führt zu direkt messbaren Kosten.
Bei E-Commerce- und SaaS-Anwendungen ist die Ausfallzeit direkt proportional zu entgangenen Bestellungen und Abonnementeinnahmen.
Wenn Suchmaschinen-Bots während der Migration nicht auf die Website zugreifen können oder Fehlerantworten erhalten, kann dies zu vorübergehenden oder dauerhaften Ranking-Verlusten führen.
Nutzer, die auf einen unerwarteten Serverfehler stoßen, verlieren schnell das Vertrauen in die Website und die Marke.
Bei einer ungeplanten Umschaltung können nicht synchronisierte Schreibvorgänge zwischen Quell- und Zieldatenbank zu Datenverlust oder Konflikten führen.
Eine Migration mit nahezu null Ausfallzeit ist nicht improvisiert; sie erfordert eine Abfolge von Schritten, die jeweils vorher getestet wurden.
Listen Sie alle Dateien, Datenbanken, Cronjobs, Umgebungsvariablen und Drittanbieter-Integrationen (Zahlungen, E-Mail, CDN) auf, die verschoben werden müssen.
Senken Sie die TTL mindestens 24-48 Stunden vor dem Umschaltungstermin auf 300 Sekunden oder weniger, damit die Ausbreitung im entscheidenden Moment schnell erfolgt.
Bereiten Sie die Anwendungsumgebung auf dem neuen Server vor und beginnen Sie, Dateien inkrementell mit rsync vom Quellserver zu kopieren.
Richten Sie eine Replikation ein (z. B. MySQL Master-Slave), die die Quelldatenbank kontinuierlich auf das Ziel spiegelt und die Differenz bei der Umschaltung auf Sekunden reduziert.
Überprüfen Sie, ohne das echte DNS zu ändern, über einen Hosts-Datei-Eintrag oder eine Testdomain, dass alle Funktionen auf dem neuen Server, etwa Formulare, Zahlungen und Login, korrekt funktionieren.
Synchronisieren Sie die letzten Unterschiede in einem kurzen Nur-Lese-Fenster, schalten Sie den DNS-Eintrag auf den neuen Server um, überwachen Sie Traffic und Fehlerraten genau; dank der niedrigen TTL können Sie bei Problemen schnell auf den alten Server zurückwechseln.
rsync -avz --delete -e ssh /var/www/site/ user@newserver:/var/www/site/
CHANGE MASTER TO MASTER_HOST='old-server-ip', MASTER_USER='repl_user', MASTER_PASSWORD='********', MASTER_LOG_FILE='mysql-bin.000123', MASTER_LOG_POS=4; START SLAVE;
SHOW SLAVE STATUS\G
dig +short yourdomain.com dig yourdomain.com | grep -i "ttl"
Türkei (Türkisch)
Germany (German)
Worldwide (English)
curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://yourdomain.com/healthrsync -avz --delete -e ssh /var/www/site/ user@newserver:/var/www/site/ mysqldump --single-transaction old_db | mysql -h newserver new_db
Für den Webserver und statische Dateien ist echte Null-Ausfallzeit erreichbar; eine schreibintensive Datenbank benötigt meist noch ein Nur-Lese-Fenster von wenigen Sekunden bis Minuten. Mit sorgfältiger Planung kann dieses Fenster so kurz gehalten werden, dass Nutzer es nie bemerken.
Senken Sie die TTL mindestens eine volle aktuelle TTL-Periode vor dem Umschaltungstermin, idealerweise 24-48 Stunden im Voraus, damit die meisten Resolver zum Umschaltungszeitpunkt bereits die kürzere TTL übernommen haben.
Wenn Sie ein CDN verwenden, müssen Sie überhaupt nicht auf die DNS-Ausbreitung warten: Der DNS-Eintrag zeigt bereits auf das CDN, Sie aktualisieren nur die Origin-Server-IP im CDN-Dashboard, und die Änderung verbreitet sich je nach CDN-Cache deutlich schneller.
Wenn Sie die TTL im Voraus gesenkt und den alten Server noch eine Weile laufen lassen haben, können Sie innerhalb von Minuten zurückwechseln, indem Sie den DNS-Eintrag wieder auf die IP des alten Servers zeigen lassen, weshalb Sie den alten Server nach der Umschaltung mindestens einige Tage nicht abschalten sollten.
Für leselastige Anwendungen ermöglicht Replikation eine nahezu nahtlose Umschaltung; um die Datenkonsistenz zu garantieren, ist ein kurzes Fenster, in dem die letzten Schreibvorgänge pausiert werden, jedoch meist der sicherste Ansatz.
Eine korrekt konfigurierte Migration, mit gleicher URL-Struktur, korrekten Weiterleitungen und ununterbrochenem Zugriff, sollte das SEO nicht beeinträchtigen; lange Ausfälle, defekte Links oder falsche Weiterleitungen können jedoch zu vorübergehenden oder dauerhaften Ranking-Verlusten führen.
Eine Referenz, die erklärt, was DNS-TTL ist und wie sie die Ausbreitungszeit beeinflusst.
Die offizielle Referenz für MySQL-Replikationsarchitektur und -konfiguration.
Die offizielle Dokumentation für alle Parameter des rsync-Befehls.
Entdecken Sie unsere Linux-VPS-Pakete mit NVMe-Speicher, hoher Bandbreite und sofortiger Einrichtung – bereit für Ihre Migration.