A tárhelyváltás akkor sikerül, ha a látogató semmit nem vesz észre belőle. Ehhez nem erősebb szerver kell, hanem sorrend: mit csinálsz két nappal előtte, mit a váltás percében, és mit hagysz futni még egy hétig utána.
Érdemes az elején tisztázni, mit jelent a nulla állásidő. Nem azt, hogy a szerver egy pillanatra sem áll le, hanem azt, hogy a látogató mindig kap kiszolgálást, és semmilyen adat nem vész el útközben. A kettő nem ugyanaz, és a második a nehezebb feladat.
Miért időzítési, és nem technikai kockázat a tárhelyváltás?
A rövid válasz: a fájlok és az adatbázis átmásolása ma rutinművelet, a hibák viszont szinte kivétel nélkül abból az időablakból származnak, amikor két élő rendszer fogadja ugyanannak a domainnek a forgalmát.
Saját tapasztalat: költöztetéseknél a bejelentések nagy része nem „nem jön be az oldal” jellegű, hanem „megrendeltem, de nem kaptam visszaigazolást”, „kitöltöttem az űrlapot, de nem érkezett meg”, „a kollégám látja az új terméket, én nem”. Mind a három ugyanaz a jelenség: a DNS-váltás után a látogatók egy része még a régi IP-t kapja a saját szolgáltatójától, a másik része már az újat, és mindkét oldalon írható adatbázis van.
Hivatalosan igazolt: a DNS-válaszokat a feloldó szerverek a rekordhoz tartozó TTL (time to live) értékig gyorsítótárazzák, ez az RFC 1035 óta a protokoll része. Amíg a régi válasz a gyorsítótárban van, a látogató a régi szerverre megy akkor is, ha te már átírtad a rekordot.
Mennyivel a váltás előtt kell leszállítani a DNS TTL-t?
Rövid válasz: legalább a jelenlegi TTL-nyi idővel korábban, a gyakorlatban 24-48 órával a tervezett váltás előtt, 300 másodperces (5 perces) értékre.
A logika egyszerű. Ha a mai A-rekord TTL-je 3600 másodperc, akkor a most kiadott válaszok még egy óráig érvényben maradnak. Ha viszont a TTL 86400 (egy nap), akkor maga a leszállítás is egy napot késik, mert a feloldók a régi, hosszú értéket őrzik. Ezért a sorrend: először TTL le, aztán megvárod a régi TTL lejártát, és csak utána nyúlsz a tényleges rekordhoz.
Ellenőrizni így tudod:
dig +noall +answer example.hu A
dig +noall +answer @1.1.1.1 example.hu A
Az első a rendszered beállított feloldóját kérdezi, a második egy külső feloldót. A soron megjelenő szám a hátralévő TTL másodpercben, és minden ismételt lekérdezésnél csökken. Ha nullára fut, és a következő lekérdezés már az új, alacsony értéket mutatja, a leszállítás átment.
Fontos részlet: ha névszervert (NS) cserélsz, nem csak A-rekordot, akkor a TTL-t a domain regisztrátoránál lévő NS-rekordokra is nézni kell, azok pedig gyakran hosszabbak, és nem mindig szerkeszthetők. Szakmai feltételezés: ezért a legtöbb esetben nyugodtabb út az A-rekord (és a webes AAAA) cseréje a meglévő DNS-szolgáltatónál, a névszerver-váltást pedig külön, egy héttel későbbre időzíteni.
Mitől lesz teljes a másolat az új szerveren?
Rövid válasz: a fájlok és az adatbázis csak a felét adják, a másik fele a futtatókörnyezet és a háttérfolyamatok.
Ellenőrizd tételesen:
- fájlok a rejtett állományokkal együtt (
.htaccess,.env,.well-known), a jogosultságok megtartásával; - adatbázis teljes kiírása és visszatöltése karakterkészlettel együtt (
mysqldump --single-transaction --default-character-set=utf8mb4); - azonos vagy szándékosan újabb PHP-verzió, ugyanazokkal a kiterjesztésekkel (imagick, intl, zip, curl);
- ütemezett feladatok (cron), amelyeket a fájlmásolás nem visz át;
- a kimenő levelezés módja: helyi mail funkció vagy külső SMTP;
- SSL-tanúsítvány, lehetőleg még a DNS-váltás előtt kiállítva, DNS-alapú hitelesítéssel;
- IP-alapú engedélyezés a külső szolgáltatóknál (fizetési szolgáltató, számlázó, korlátozott API-kulcs), mert az új szerver IP-je más.
Saját tapasztalat: a felejtős tétel majdnem mindig a cron és az IP-korlátozás. A weboldal tökéletesen fut, két nappal később derül ki, hogy a napi szinkron áll, vagy hogy a fizetési szolgáltató visszahívása (webhook) az új IP-ről nem megy át.
Hogyan teszteled az új szervert a DNS-váltás előtt?
Rövid válasz: a saját géped hosts fájljával a saját forgalmadat átirányítod az új IP-re, miközben a világ többi része még a régi szervert használja.
Windowson a C:/Windows/System32/drivers/etc/hosts, macOS és Linux alatt a /etc/hosts fájlba veszed fel:
203.0.113.10 example.hu www.example.hu
Mentés után a böngésződ az új szervert látja a valódi domainnéven, tehát nem staging URL-en tesztelsz. Ez azért számít, mert a hibák jelentős része pont a domainhez kötődik: átirányítások, sütik, abszolút URL-ek, tanúsítvány, fizetési visszahívás.
Ha a hosts fájlhoz nem akarsz nyúlni, ugyanezt megteszi a curl:
curl -I --resolve example.hu:443:203.0.113.10 https://example.hu/
A teszt akkor ér valamit, ha végigmész a pénzt hozó útvonalakon: főoldal, kategória, terméklap, kosár, pénztár egészen a fizetési átirányításig, kapcsolati űrlap valódi elküldéssel, bejelentkezés, adminfelület, keresés, egy képfeltöltés. A válaszkódokat is nézd, ne csak a képernyőt.
Mi történik az e-mailekkel a váltás közben?
Rövid válasz: az e-mail külön rekordokon (MX, SPF, DKIM, DMARC) fut, tehát önálló döntés, hogy költözik-e, és ez a döntés a leggyakoribb rejtett hibaforrás.
Három tipikus eset:
- A levelezés marad a régi helyen. Ilyenkor az MX-rekordhoz nem nyúlsz, csak a webes A-rekordhoz. Ez a legkisebb kockázat, de figyelj rá, hogy az új tárhely ne kezdje magát a domain levelezőjének tekinteni (helyi kézbesítés), mert akkor a saját címre küldött üzenetek el sem hagyják a szervert.
- A levelezés is költözik. A postafiókokat IMAP-szinkronnal előre átmásolod, majd a váltás után újra szinkronizálsz, hogy a köztes időben érkezett levelek is átjöjjenek. Az MX TTL-jét ugyanúgy le kell vinni előre.
- Csak a kimenő rendszerlevelek érintettek (visszaigazolás, jelszó-emlékeztető). Itt a legjobb, ha külső SMTP-szolgáltatót használsz, mert az független a tárhelytől.
Hivatalosan igazolt: az SPF-rekord a küldésre jogosult IP-ket sorolja fel. Ha az oldal már az új szerverről küld, de az SPF csak a régi IP-t engedi, a fogadó oldal elutasíthatja vagy spamnek jelölheti a levelet. Az SPF bővítését az új IP-vel a váltás előtt végezd el, mert az a régi működést nem rontja el.
Mi lesz a váltás alatt beérkező rendelésekkel, és hogyan kerülöd el a kettéhasadt adatbázist?
Rövid válasz: úgy, hogy a propagáció ideje alatt csak egyetlen adatbázisba lehessen írni, a másik oldal pedig karbantartás alatt áll.
A kettéhasadt adatbázis (split brain) így keletkezik: a látogató a régi szerverre fut be, és lead egy rendelést 1042-es sorszámmal. Egy másik látogató ugyanabban a percben már az új szervert éri el, és ott is 1042-es sorszámot kap, mert az adatbázis másolata ugyanott tartott. A két adatsort utólag nem lehet tisztán egyesíteni, mert ütköznek az azonosítók.
A gyakorlatban bevált megoldás:
- a váltást alacsony forgalmú időszakra tedd (webshopnál jellemzően hajnalra), és tervezz 15-30 perces írási szünetet;
- a szünet elején a régi oldalt kapcsold karbantartási módba, hogy új rendelés ne induljon: WordPress esetében elég egy
.maintenancefájl a gyökérben, vagy egy 503-as válasz a.htaccessszintjén; - a karbantartás bekapcsolása UTÁN készítsd el a végleges adatbázis-mentést, és azt töltsd vissza (a korábbi másolat csak a tesztre volt jó);
- a DNS átírása után a régi szerveren hagyd bent a karbantartási módot, vagy irányítsd át a kéréseket az új IP-re, hogy a régi választ őrző látogató is az új rendszerben kössön ki;
- a régi tárhelyet ne mondd le legalább 7-14 napig, mert a hosszú TTL-t őrző feloldók még napokig küldhetnek oda forgalmat.
Az űrlapoknál ugyanez a szabály: ha a kitöltés csak adatbázisba megy, a régi szerveren ragadt űrlap elveszik. Ezért érdemes a költözés hetére bekapcsolni, hogy az űrlap e-mailt is küldjön.
Hogyan néz ki a percre bontott ellenőrzőlista?
Rövid válasz: a munka nagyobb része a váltás előtti napokra esik, a kritikus ablak maga jellemzően fél óra.
T-48 óra
- A, AAAA, MX, CNAME TTL leszállítása 300 másodpercre, az SPF kiegészítése az új IP-vel.
- Teljes fájl- és adatbázis-másolat, PHP-verzió és kiterjesztések beállítása.
T-24 óra
- SSL kiállítása az új szerveren, DNS-alapú hitelesítéssel.
- Hosts fájlos teljes teszt: pénztár, űrlap, bejelentkezés, feltöltés, keresés.
- Cron átvitele (egyelőre kikapcsolva), az új IP engedélyezése a külső szolgáltatóknál.
T-0 perc
- A régi oldal karbantartási módba, 503-as válasszal és
Retry-Afterfejléccel. - Végleges adatbázis-mentés, és a köztes időben módosult feltöltések újraszinkronizálása.
T+10 perc
- Visszatöltés az új szerverre, gyors ellenőrzés hosts fájllal, cron bekapcsolása.
- Az A-rekord átírása az új IP-re.
T+15 perc
- A régi szerveren marad a karbantartás, vagy átirányítás az új IP-re.
- Ellenőrzés külső feloldókon:
dig @8.8.8.8 example.hu Aésdig @1.1.1.1 example.hu A.
T+60 perc és T+24 óra
- Naplók átnézése hibakódokra, próbarendelés, próba-űrlap, levélküldés tesztje.
- Ha minden rendben, a TTL visszaemelése 3600 másodpercre.
- A régi tárhely megtartása még legalább egy hétig, majd egy utolsó ellenőrzés, érkezik-e még oda kérés.
Mi a visszaállítási terv, ha az új szerveren elszáll valami?
Rövid válasz: a visszalépés nehéz része nem a DNS visszaírása, hanem annak eldöntése, hogy a közben keletkezett adatot melyik rendszerben tartod meg.
Írd le előre a következőket:
- A visszalépés kiváltó oka. Például: az oldal 10 percnél tovább hibás, vagy a pénztár nem működik. Enélkül a döntést a stressz hozza meg, rosszul.
- A technikai lépés. A-rekord vissza a régi IP-re. Mivel a TTL 300 másodperc, ez percek alatt hat, ezért a váltás előtt nem szabad visszaemelni a TTL-t.
- Az adat sorsa. Ha az új szerveren már születtek rendelések, a visszalépés azokat láthatatlanná teszi. Vagy exportálod és kézzel viszed vissza őket, vagy visszalépés helyett előre javítasz. Ezt előre kell eldönteni.
- Aki dönt. Egy ember, névvel, ne bizottság hajnali kettőkor.
Saját tapasztalat: ha a karbantartási módot a régi szerveren végig fenntartod, a visszaállítás sokkal egyszerűbb, mert a régi rendszerben nem keletkezett új adat, tehát csak az egyik oldallal kell foglalkozni.
Mit érdemes a váltás után megnézni a keresők miatt?
Rövid válasz: a szerverváltás önmagában nem SEO-esemény, a mellette elkövetett hibák viszont azok.
Hivatalosan igazolt: a Google dokumentációja szerint az IP-cím változása önmagában nem befolyásolja a rangsorolást, a lassú válaszidő, a tömeges 5xx hiba és a véletlenül kint maradt noindex vagy tiltó robots.txt viszont igen. Nézd meg tehát a robots.txt tartalmát, néhány oldal forrásában a robots meta címkét, a Search Console szerveroldali hibáit és a válaszidőket. Szakmai feltételezés: a nyelvi modellek tartalomgyűjtő robotjai hasonlóan viselkednek, így egy több napos hibás állapot ott is kieséssel járhat, de erről nyilvános, mért adat alig áll rendelkezésre.
Források és további olvasnivalók
- Google Search Central: Site moves with URL changes, illetve Site moves without URL changes
- Google Search Central: robots.txt specifikáció és a noindex szabályok
- IETF RFC 1034 és RFC 1035: Domain Names, Concepts and Facilities, valamint Implementation and Specification
- IETF RFC 7208: Sender Policy Framework (SPF)
- IETF RFC 7489: Domain-based Message Authentication, Reporting and Conformance (DMARC)
- MySQL Reference Manual: mysqldump
- WordPress Developer Resources: Migrating WordPress
- A TTL-t 24-48 órával a váltás előtt vidd le 300 másodpercre, különben a régi, hosszú TTL miatt maga a leszállítás is késik.
- A hosts fájlos teszt az egyetlen mód, hogy a valódi domainnéven próbáld ki az új szervert, mielőtt a világ ránézne.
- Az e-mail külön rekordokon fut (MX, SPF, DKIM, DMARC), ezért önálló döntés, hogy költözik-e, és külön ellenőrzést kíván.
- A kettéhasadt adatbázist az előzi meg, ha a váltás ablakában csak egy rendszer fogad írást, a másik karbantartás alatt van.
- A visszaállítási terv nehéz része nem a DNS visszaírása, hanem annak eldöntése, mi legyen a közben keletkezett adattal.
Gyakori kérdések
Mennyi ideig tart a DNS-propagáció valójában?
Ha a váltás előtt leszállítottad a TTL-t 300 másodpercre, a feloldók többsége percek alatt átáll. A gyakorlatban mégis érdemes 24-72 órát számolni, mert egyes szolgáltatói feloldók a megadott TTL-nél tovább őrzik a válaszokat. Ezért kell a régi tárhelyet még legalább egy-két hétig fenntartani.
Elveszhet-e rendelés vagy űrlapkitöltés a váltás alatt?
Elveszhet, ha mindkét szerver egyszerre fogad írást, mert a régi adatbázisba került rekordok nem kerülnek át az újba. Ezt egy rövid, tervezett írási szünettel és a régi oldal karbantartási módba kapcsolásával lehet megelőzni. Az űrlapoknál a költözés hetére érdemes e-mail-értesítést is bekapcsolni tartaléknak.
Muszáj a levelezést is költöztetni a weboldallal együtt?
Nem, a kettő külön DNS-rekordokon fut. Ha az MX-rekordhoz nem nyúlsz, a levelezés a régi helyén marad, és a webes költözés nem érinti. Ilyenkor arra kell figyelni, hogy az új tárhely ne kezelje magát a domain levelezőjének, és hogy az SPF-rekord tartalmazza az új szerver IP-jét, ha onnan mennek ki a rendszerlevelek.
Hogyan tesztelhetem az új szervert anélkül, hogy bárki más látná?
A saját géped hosts fájljába felveszed az új IP-t a domainnel, így csak a te böngésződ megy az új szerverre. Ez azért jobb a staging URL-nél, mert a valódi domainnéven teszteled az átirányításokat, a sütiket, a tanúsítványt és a fizetési visszahívást. Ugyanez elérhető a curl --resolve kapcsolójával is.
Rontja-e a keresőoptimalizálást a tárhelyváltás?
A szerver vagy az IP megváltozása önmagában nem rontja a láthatóságot, ha az URL-ek változatlanok maradnak. A kockázat a mellékhatásokban van: hosszú válaszidő, tömeges szerverhiba, kint felejtett tiltó robots.txt vagy noindex. Ezek javítása után a helyzet jó eséllyel rendeződik, de ez nem előre kiszámítható.
Mikor emeljem vissza a TTL-t az eredeti értékre?
Akkor, amikor már biztos vagy benne, hogy nem lépsz vissza, jellemzően 24-48 órával a váltás után. Addig az alacsony TTL a visszaállítási terv része, mert vele percek alatt vissza tudsz állni a régi IP-re. A visszaemelés csökkenti a DNS-kiszolgálók terhelését is.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.