Zmieniłem TTL z 24 godzin na 5 minut. Czy muszę czekać 24 godziny przed zmianą zapisów?


37

Migruję naszą aplikację z serwera w chmurze na serwerze dedykowanym Rackspace ta.

Chcę wyłączyć aplikację na ~ 5 minut, aby skopiować dane z serwera w chmurze na serwer dedykowany, więc nie chcę, aby żądania były przesyłane do starego serwera po skopiowaniu danych.

Chcę wskazać nasz rekord DNS na nowym serwerze, ale TTL ustawiono na 24 godziny. Zmieniłem to na 300 sekund. Czy muszę czekać 24 godziny przed aktualizacją adresu IP wskazanego przez domenę / skopiowanie danych?


9
BTW, nawet jeśli poczekasz na TTL. Gorąco polecam edycję konfiguracji na starym serwerze, aby upewnić się, że żadne aktualizacje nie będą tam akceptowane. Nie wszystkie resolwery DNS faktycznie spełniają standardy.
Peter Green

5
To, co zrobiłem, przenosząc aplikację internetową od jednego dostawcy hostingu do drugiego, to skorzystanie z przekierowania portu ssh, aby wszyscy odwiedzający nadal korzystali ze starego adresu IP kierowanego na nowy serwer.
kasperd

Odpowiedzi:


58

Każdy, kto ma kopię rekordu domeny zapisaną w pamięci podręcznej, nie będzie się martwił aktualizacją go przez 24 godziny, więc tak, jeśli masz zamiar mieć co najwyżej 5-minutowe okno niedostępności, poczekaj, aż wszystkie zaległe pamięci podręczne nie zaktualizują się i nie będą już dostępne. niż 5 minut.


23
... przez 24 godziny since they last cached it. Może to być od 1 do 86399 sekund.
user9517 obsługuje GoFundMonica

6
@ Iain Musisz założyć najgorsze, ponieważ jeden lub wszystkie z nich mogły właśnie buforować go tuż przed zmianą.
Barmar

6
@Barmar Nie zakładaj niczego. Wielu dostawców usług internetowych po prostu ignoruje TTL.
user9517 obsługuje GoFundMonica

13
@Iain Pracowałem dla Akamai, sieci CDN, która często wykorzystuje krótkie TTL (jak 60 sekund) do równoważenia obciążenia. Pamiętam, że przeprowadziliśmy badanie i stwierdziliśmy, że większość dostawców usług internetowych przestrzegała naszych TTL.
Barmar

1
Pracuję dla firmy hostingowej, z naszego doświadczenia wynika, że ​​niskie TTL są bardziej prawdopodobne, że zostaną zignorowane niż wyższe.
Henrik - przestań krzywdzić Monikę

39

Jest (potencjalnie) jeszcze gorszy - musisz poczekać 24 godziny po aktualizacji wszystkich autorytatywnych serwerów. Normalnym sposobem dokonywania aktualizacji jest dokonanie zmiany strefy na serwerze głównym, a następnie każde z urządzeń pomocniczych przesyła nowe dane strefy, kiedy następnym razem będą się meldować przy użyciu serwera podstawowego. Częstotliwość sprawdzania kontrolowana jest przez interwał odświeżania w rekordzie SOA strefy. Dlatego w najgorszym przypadku musisz poczekać na interwał odświeżania strefy + TTL rekordu.

Można również trzeba czekać tak długo na rzeczywistych zmian płytowych. 5-minutowy czas TTL nie przyniesie wiele korzyści, jeśli pomocnicze urządzenia odświeżające będą odświeżane tylko co 6 godzin. Prawdopodobnie chcesz również skrócić interwał odświeżania w strefie dla okresu, w którym chcesz móc wprowadzać szybkie zmiany.

Pamiętaj, że to może nie dotyczyć twojej konfiguracji. Jeśli masz system, który aktualizuje wszystkie wiarygodne serwery razem, nie stanowi to problemu (i nie znam konfiguracji DNS Rackspace). Ale zalecam odpytanie wszystkich autorytatywnych serwerów indywidualnie ( dig server.example.com @secondaryserver.example.com), aby upewnić się, że mają nowe TTL przed rozpoczęciem 24-godzinnego odliczania.


1
To powinna być zaakceptowana odpowiedź.
dotancohen

4
Wygląda na to, że ignorujesz protokół DNS Notify, który informuje serwery podrzędne, aby odświeżyły się wkrótce po aktualizacji urządzenia głównego. Większość serwerów DNS korzysta z tej funkcji.
Barmar

@Barmar: To prawda, ale w tym samym czasie mistrz może zająć trochę czasu, aby aktualizować w zależności od dostawcy. (Na przykład niektórzy dostawcy odbudowują strefy z bazy danych co 5 lub 15 minut, chociaż
nowi

1
Mój komentarz dotyczył tylko problemu oczekiwania na interwał odświeżania, który jest obecnie w większości przestarzały. Oczekiwanie na aktualizację wzorca jest prawdą, chyba że używasz własnego wzorca. Ale myślę, że jest mało prawdopodobne, że będą musieli poradzić sobie z dokładnym czasem, kiedy wszystko stanie się bezpieczne do aktualizacji; Dodatkowe 5-15 minut nie powinno mieć większego znaczenia. Pierwotnym pytaniem jest to, czy muszą czekać cały dzień.
Barmar

1
@GordonDavisson: Jeśli nie ufasz - sprawdź. dig +nssearch example.comjest przydatnym narzędziem do szybkiego porównywania SOA na wszystkich serwerach; nsdiff pokazuje rzeczywiste różnice.
grawitacja

23

Tak, powinieneś poczekać. Nawet wtedy oczywiście nie ma gwarancji, że wszyscy będą szanować TTL.


6
+1 za to, że nie wszyscy przestrzegają TTL, widziałem maruderów przybywających w tydzień po wprowadzeniu zmiany DNS. Jednym ze sposobów, w jaki sobie z tym poradziłem w przeszłości, było skonfigurowanie nowej unikalnej nazwy jako aliasu w nowej witrynie i użycie przekierowania ze starej witryny w celu przekierowania użytkowników ze starej domeny do nowych, na przykład z www.mojafirma .com -> newsite.mycompany.com
Johnny

Tak, ale wiele osób słusznie gardzi pomysłem użycia nowej nazwy. Nazwy są markami. Działa to również tylko dla HTTP i praktycznie dla niczego innego.
Sven

8
Inną opcją jest skonfigurowanie starego serwera jako odwrotnego proxy do nowego serwera. Następnie możesz pozostawić to na około tydzień po przełączeniu i wyłączyć je, gdy nie ma ruchu ulicznego.
bdsl

1
Osoby, które mają dobrze zachowujące się serwery DNS przestrzegające TTL, nigdy nie zobaczą nowej domeny. I chociaż „tylko” działa z HTTP (S), myślę, że przekonasz się, że HTTP jest dość powszechnym protokołem w Internecie. Sugestia bdsl dotycząca utworzenia odwrotnego proxy jest jeszcze lepsza, ale to więcej pracy
Johnny

@Johnny Problem z nową domeną polega na tym, że ryzykujesz dodaniem zakładek do tej domeny przez ludzi. Chyba że planujesz pozostawić wspomnianą nową domenę dostępną na zawsze.
Bob

5

Łączenie różnych komentarzy i odpowiedzi w kompletną procedurę byłoby czymś w rodzaju.

  1. Upewnij się, że możesz zaktualizować swoje serwery autoryzacyjne w odpowiednim czasie.
  2. Zmniejsz TTL.
  3. Sprawdź, czy wszystkie autorytatywne serwery mają nowy ttl.
  4. Poczekaj na stary TTL, aby wartości w pamięci podręcznej ze starym TTL zostały (przeważnie) wyeliminowane z pamięci podręcznej (nie możesz zagwarantować, że znikną one z każdej pamięci podręcznej, ponieważ niektóre pamięci podręczne mogą ignorować standardy).
  5. Umieść witrynę na starym serwerze w trybie tylko do odczytu (lub jeśli nie możesz tego zrobić, zastąp ją stroną „jesteśmy gotowi na konserwację”).
  6. Wykonaj ostateczną kopię ze starego serwera na nowy serwer (co spowoduje utworzenie witryny tylko do odczytu na nowym serwerze).
  7. Zmień rekordy DNS.
  8. Upewnij się, że wszystkie serwery autoryzacyjne mają nowe rekordy DNS.
  9. Poczekaj na nowy ttl (możesz pominąć ten krok, jeśli nie martwisz się, że niektórzy użytkownicy będą mogli wnosić wkład do witryny, a inni użytkownicy nie zobaczą wyników tych wpisów).
  10. Przełącz witrynę na nowym serwerze do trybu odczytu / zapisu.
  11. Umieść na starym serwerze informację, że jest to przestarzała kopia tylko do odczytu i że użytkownik prawdopodobnie zepsuł DNS.
  12. Poczekaj, aż rekordy wypadną z niezgodnych pamięci podręcznych DNS.
  13. Wycofaj stary serwer.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.