Я змінив 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 майже в реальному часі.