Kaydın TTL değeri neyi belirler; GTM'de nasıl seçilmelidir?
Kısa cevap
Kaydın TTL değeri, DNS Service'in verdiği cevabın resolver'larda ve istemcilerde en fazla kaç saniye önbellekte tutulabileceğini bildirir; varsayılan 3600, aralık 0–31.536.000 saniyedir. GTM bir adresi cevaptan çıkardığında ya da DR DC'ye geçtiğinde yeni cevap birkaç saniye içinde verilir, ama eski cevabı önbelleğe almış istemciler TTL dolana kadar eski adresi kullanır. Bu yüzden bir arızanın istemcilere yansıması, en kötü durumda arızanın health check ile fark edilme süresi ile TTL'in toplamı kadar sürer. Health check'e bağlı adresi, Disaster Recovery ya da Datacenter seçimi olan kayıtlarda kısa TTL (ör. 60–300 saniye), adresi değişmeyen kayıtlarda daha uzun TTL seçilir.
Nasıl Çalışır?
Bir adresin arızalanmasından istemcinin yeni adrese gitmesine kadar üç süre art arda geçer:
- Fark etme: Health check, hedefi Period aralığıyla dener ve ardışık Required Failures başarısızlıktan sonra Error olur. Uzak veri merkezinin otomatik health check'lerinde bu süre Access Period ve Required Failure ile belirlenir.
- Cevabın değişmesi: Health Scenario kararı değişince kayıt yeniden değerlendirilir ve DNS Service yeni cevabı verir.
- Önbelleğin boşalması: Eski cevabı tutan resolver ve istemciler TTL dolunca yeniden sorar ve yeni cevabı alır.
TTL 0 cevabın önbelleğe alınmaması gerektiğini bildirir (RFC 1035); bu değerde aynı ad her gerektiğinde yeniden sorgulanır ve GTM'e gelen sorgu sayısı artar.
TR7'de TTL
- Nerede: Kayıt formundaki TTL alanı, saniye cinsinden; kutunun yanında kısaltılmış karşılığı (ör.
1h) görünür. Records listesinde TTL sütununda izlenir. - Kapsam: TTL kayıt başınadır; kaydın bütün cevapları (Main DC, DR DC, seçilen veri merkezleri ya da Fail-Safe Records) aynı TTL ile döner.
- Zone transfer: Zone Transfer ile yeni oluşturulan kayıtlar kaynaktaki TTL'i alır.
- Cache TTL ile farkı: DNS Service'teki Cache TTL istemcilere bildirilmez; servisin kendi önbelleğinin süresidir (TTL nedir; TR7'de hangi ekranlarda, hangi anlamda geçer?).
| Kayıt | Önerilen yaklaşım |
|---|---|
| Health scenario'ya bağlı adresi olan, Disaster Recovery ya da Datacenter modundaki A / AAAA / CNAME kayıtları | Kısa TTL (ör. 60–300 saniye); geçişin hızı önemlidir. |
| Adresi sabit kayıtlar (NS, MX, TXT gibi) | Daha uzun TTL; sorgu yükü azalır. |
| Planlı adres değişikliği | Değişiklikten en az eski TTL süresi kadar önce TTL düşürülür. |
Sık Karıştırılan Noktalar
- "GTM geçiş yapınca bütün istemciler hemen yeni adrese gider." Yeni cevap birkaç saniye içinde verilir; önbellekte eski cevabı olan istemciler TTL dolana kadar eski adresi kullanır (DNS tabanlı yönlendirmenin sınırları nelerdir; TTL ve resolver cache kararı nasıl etkiler?).
- "Kısa TTL tek başına hızlı failover sağlar." Arızanın fark edilme süresi de toplam süreye eklenir; health check Period ve Required Failures değerleri TTL ile birlikte düşünülür.
- "DR ya da fail-safe cevapları ayrı bir TTL ile döner." Kaydın tek bir TTL'i vardır; hangi gruptan cevap verilirse verilsin aynı TTL kullanılır.
- "TTL ne kadar kısa olursa o kadar iyidir." TTL kısaldıkça aynı ad için gelen sorgu sayısı artar; TTL, geçiş hızı ihtiyacı ile sorgu yükü arasında seçilir.
Dokümantasyonda nasıl yapılır
İlgili sorular
- TTL nedir; TR7'de hangi ekranlarda, hangi anlamda geçer?
- DNS tabanlı yönlendirmenin sınırları nelerdir; TTL ve resolver cache kararı nasıl etkiler?
- Disaster Recovery modunda ana ve yedek veri merkezi arasında geçiş nasıl olur?
- Veri merkezleri arası yedeklilik için Load Balancer mı, GTM mi kullanmalıyım?
