Назад | Перейти на главную страницу

Я изменил свой TTL с 24 часов на 5 минут. Нужно ли мне ждать 24 часа, прежде чем менять записи?

Я переношу наше приложение с облачного сервера в Rackspace на выделенный сервер.

Я хочу отключить приложение на ~ 5 минут, чтобы скопировать данные с облачного сервера на выделенный сервер, поэтому я не хочу, чтобы запросы отправлялись на старый сервер после того, как я скопировал данные.

Я хочу указать нашу DNS-запись на новом сервере, но TTL был установлен на 24 часа. Я изменил его на 300 секунд. Нужно ли мне ждать 24 часа перед обновлением IP-адреса, на который указывает домен / копированием данных?

Любой, у кого есть кешированная копия записи домена, не будет беспокоиться об обновлении ее в течение 24 часов, так что да, если вы намереваетесь иметь не более 5-минутное окно недоступности, вам следует подождать, пока все незавершенные кеши обновятся, чтобы больше не жить чем 5 минут.

Это (потенциально) даже хуже - вам нужно подождать 24 часа после все ваших официальных серверов обновились. Обычно обновления происходят так, что вы вносите изменения в зону на первичном сервере, а затем каждый из вторичных серверов передает новые данные зоны в следующий раз, когда они будут регистрироваться на первичном сервере. Частота регистрации контролируется интервалом обновления в записи SOA зоны. Таким образом, в худшем случае придется подождать интервал обновления зоны + TTL записи.

Ты можешь также придется так долго ждать фактических изменений записи. 5-минутный TTL не принесет много пользы, если вторичные компоненты будут обновляться только каждые 6 часов. Таким образом, вы, вероятно, захотите уменьшить интервал обновления в зоне на период, когда вы хотите иметь возможность вносить быстрые изменения.

Имейте в виду, это может не относиться к вашей настройке. Если у вас есть система, которая обновляет все авторитетные серверы вместе, это не проблема (и я не знаком с настройкой DNS Rackspace). Но я бы порекомендовал запросить все ваших авторитетных серверов индивидуально (dig server.example.com @secondaryserver.example.com), чтобы убедиться, что у них новый TTL, прежде чем начать 24-часовой обратный отсчет.

Да, тебе стоит подождать. Но даже тогда, конечно, не гарантируется, что все будут уважать TTL.

Собрав воедино различные комментарии и ответы, вся процедура будет примерно такой.

  1. Убедитесь, что вы можете своевременно обновлять свои авторские серверы.
  2. Уменьшите TTL.
  3. Убедитесь, что на всех авторизованных серверах установлен новый ttl.
  4. Дождитесь старого TTL, чтобы кешированные значения со старым TTL (в основном) были удалены из кешей (вы не можете гарантировать, что они исчезнут из каждого кеша, потому что некоторые кеши могут игнорировать стандарты).
  5. Переведите сайт на старом сервере в режим только для чтения (или, если вы не можете этого сделать, замените его страницей «Мы не работаем для обслуживания»).
  6. Выполните окончательное копирование со старого сервера на новый сервер (в результате сайт будет доступен только для чтения на новом сервере).
  7. Измените записи DNS.
  8. Убедитесь, что на всех авторизационных серверах есть новые записи DNS.
  9. Подождите, пока не появится новый ttl (вы можете пропустить этот шаг, если вас не волнует, что некоторые пользователи могут вносить свой вклад в сайт, а другие пользователи не видят результатов этих вкладов).
  10. Переведите сайт на новом сервере в режим чтения / записи.
  11. Поместите на старый сервер уведомление о том, что это устаревшая копия, доступная только для чтения, и что пользователь, вероятно, сломал DNS.
  12. Подождите, пока записи не выпадут из кэшей несовместимых DNS.
  13. Выведите из эксплуатации старый сервер.

В дополнение к другим ответам вы можете использовать https://www.whatsmydns.net/ чтобы проверить, как ваша запись DNS распространяется практически в реальном времени.