ฉันเปลี่ยน TTL ของฉันจาก 24 ชั่วโมงเป็น 5 นาที ฉันต้องรอ 24 ชั่วโมงก่อนเปลี่ยนบันทึกหรือไม่

37

ฉันกำลังย้ายแอพของเราจากคลาวด์เซิร์ฟเวอร์ที่เซิร์ฟเวอร์เฉพาะ Rackspace

ฉันต้องการให้แอปพลิเคชันหยุดทำงานเป็นเวลาประมาณ 5 นาทีเพื่อคัดลอกข้อมูลจากคลาวด์เซิร์ฟเวอร์ไปยังเซิร์ฟเวอร์เฉพาะดังนั้นฉันไม่ต้องการให้คำขอไปยังเซิร์ฟเวอร์เก่าหลังจากคัดลอกข้อมูลแล้ว

ฉันต้องการชี้ระเบียน DNS ของเราที่เซิร์ฟเวอร์ใหม่ แต่ TTL ตั้งค่าเป็น 24 ชั่วโมง ฉันเปลี่ยนเป็น 300 วินาที ฉันต้องรอ 24 ชั่วโมงก่อนอัปเดต IP ที่โดเมนชี้ไปที่ / คัดลอกข้อมูลหรือไม่

domain-name-system  rackspace  ttl 
— wobbily_col
แหล่งที่มา
9
BTW แม้ว่าคุณจะรอ TTL ฉันขอแนะนำให้คุณแก้ไขการกำหนดค่าบนเซิร์ฟเวอร์เก่าเพื่อให้แน่ใจว่าจะไม่ยอมรับการอัปเดตอีกต่อไป ตัวแก้ไข DNS บางตัวเท่านั้นที่ปฏิบัติตามมาตรฐาน
— ปีเตอร์กรีน
5
สิ่งที่ฉันทำเมื่อย้ายแอปพลิเคชันเว็บจากผู้ให้บริการโฮสติ้งรายหนึ่งไปยังอีกรายหนึ่งคือการใช้พอร์ตการส่งต่อ ssh เพื่อให้ผู้เยี่ยมชมยังคงใช้ IP เก่าที่ส่งไปยังเซิร์ฟเวอร์ใหม่
— kasperd

คำตอบ:

58

ทุกคนที่มีสำเนาระเบียนโดเมนจะไม่ทำการอัปเดตตลอด 24 ชั่วโมงดังนั้นถ้าคุณตั้งใจที่จะมีหน้าต่างไม่พร้อมใช้งานนานสุด 5 นาทีคุณควรรอจนกว่าแคชที่ค้างอยู่ทั้งหมดจะอัปเดตเป็นไม่มาก กว่า 5 นาที

— Jeff Meden
แหล่งที่มา
23
... มันเป็นเวลา 24 since they last cached itชั่วโมง สิ่งนี้อาจเป็นอะไรก็ได้ตั้งแต่ 1 ถึง 86399 วินาที
— user9517 รองรับ GoFundMonica
6
@Iain คุณต้องถือว่าแย่ที่สุดเพราะพวกเขาคนใดคนหนึ่งหรือทุกคนมีเพียงแคชไว้ก่อนการเปลี่ยนแปลง
— Barmar
6
@Barmar อย่าคิดอะไรเลย ISP จำนวนมากเพียง แต่เพิกเฉยต่อ TTL
— user9517 รองรับ GoFundMonica
13
@ ฉันเคยทำงานกับ Akamai ซึ่งเป็น CDN ที่ใช้ TTL สั้น (เช่น 60 วินาที) ในการโหลดบาลานซ์ ฉันจำได้ว่าเราทำการศึกษาและพบว่า ISP ส่วนใหญ่ทำตาม TTL ของเรา
— Barmar
1
ฉันทำงานให้กับ บริษัท เว็บโฮสติ้งประสบการณ์ของเราคือ TTL ต่ำมีแนวโน้มที่จะถูกเพิกเฉยมากกว่าที่สูงกว่า
— Henrik
39

มันอาจยิ่งแย่ไปกว่านั้นคุณต้องรอ 24 ชั่วโมงหลังจากเซิร์ฟเวอร์ที่เชื่อถือได้ทั้งหมดของคุณได้รับการปรับปรุง วิธีปกติสำหรับการอัปเดตที่จะเกิดขึ้นคือคุณทำการเปลี่ยนแปลงไปยังโซนบนเซิร์ฟเวอร์หลักจากนั้นแต่ละวินาทีจะถ่ายโอนข้อมูลโซนใหม่ในครั้งถัดไปที่พวกเขาเกิดขึ้นเพื่อเช็คอินกับหลัก ความถี่ในการเช็คอินถูกควบคุมโดยช่วงเวลาการรีเฟรชในบันทึก SOA ของโซน ดังนั้นในกรณีที่เลวร้ายที่สุดคุณต้องรอช่วงเวลารีเฟรชของโซน + TTL ของเรคคอร์ด

คุณอาจจะยังต้องรอนานนี้สำหรับบันทึกการเปลี่ยนแปลงที่เกิดขึ้นจริง TTL 5 นาทีจะไม่ทำอะไรได้มากนักถ้าหากมือใหม่รีเฟรชทุก ๆ 6 ชั่วโมงเท่านั้น ดังนั้นคุณอาจต้องการลดช่วงเวลาการรีเฟรชในโซนเช่นกันสำหรับช่วงเวลาที่คุณต้องการเปลี่ยนแปลงอย่างรวดเร็ว

โปรดทราบว่าสิ่งนี้อาจใช้ไม่ได้กับการตั้งค่าของคุณ หากคุณมีระบบที่อัพเดทเซิร์ฟเวอร์ที่มีสิทธิ์ทั้งหมดเข้าด้วยกันนี่ไม่ใช่ปัญหา (และฉันไม่คุ้นเคยกับการตั้งค่า DNS ของ Rackspace) แต่ฉันขอแนะนำให้สอบถามเซิร์ฟเวอร์ที่มีสิทธิ์ทั้งหมดของคุณทีละรายการ ( dig server.example.com @secondaryserver.example.com) เพื่อให้แน่ใจว่าพวกเขามี TTL ใหม่ก่อนเริ่มนับถอยหลัง 24 ชั่วโมง

— Gordon Davisson
แหล่งที่มา
1
นี่ควรเป็นคำตอบที่ยอมรับได้
— dotancohen
4
ดูเหมือนว่าคุณจะเพิกเฉยต่อโปรโตคอล DNS Notify ซึ่งบอกให้เซิร์ฟเวอร์ทาสรีเฟรชในไม่ช้าหลังจากที่มีการอัปเดตต้นแบบ เซิร์ฟเวอร์ DNS ส่วนใหญ่ใช้คุณสมบัตินี้
— Barmar
@Barmar: นั่นเป็นเรื่องจริง แต่ในเวลาเดียวกันต้นแบบอาจใช้เวลาสักครู่ในการอัปเดตขึ้นอยู่กับผู้ให้บริการ (ตัวอย่างเช่นผู้ให้บริการบางรายจะสร้างโซนใหม่จากฐานข้อมูลทุก ๆ 5 หรือ 15 นาทีถึงแม้ว่าจะเป็นโซนที่ทันสมัยทำทันที)
— grawity
1
ความคิดเห็นของฉันเป็นเพียงการจัดการปัญหาของการรอช่วงเวลารีเฟรชซึ่งส่วนใหญ่ล้าสมัยในวันนี้ การรอให้ต้นแบบอัปเดตเป็นจริงเว้นแต่ว่าคุณจะใช้งานต้นแบบของคุณเอง แต่ฉันคิดว่ามันไม่น่าเป็นไปได้ที่พวกเขาจะต้องจัดการกับเวลาที่แน่นอนเมื่อทุกอย่างปลอดภัยอัปเดต พิเศษ 5-15 นาทีไม่ควรสร้างความแตกต่าง ประเด็นของคำถามเดิมคือพวกเขาต้องรอทั้งวันหรือไม่
— Barmar
1
@GordonDavisson: หากคุณไม่เชื่อถือ - ยืนยัน dig +nssearch example.comเป็นเครื่องมือที่มีประโยชน์สำหรับการเปรียบเทียบ SOA อย่างรวดเร็วในเซิร์ฟเวอร์ทั้งหมด nsdiffแสดงความแตกต่างที่แท้จริง
— grawity
23

ใช่คุณควรรอ ถึงแม้ว่าจะไม่ได้รับประกันว่าทุกคนจะเคารพ TTL

— สเวน
แหล่งที่มา
6
+1 สำหรับทุกคนที่ไม่ปฏิบัติตาม TTL ฉันได้เห็นคนหลงทางมาในอีกหนึ่งสัปดาห์หลังจากทำการเปลี่ยนแปลง DNS วิธีหนึ่งที่ฉันเคยจัดการในอดีตคือการตั้งชื่อที่ไม่ซ้ำใหม่เป็นชื่อแทนในเว็บไซต์ใหม่และใช้การเปลี่ยนเส้นทางจากเว็บไซต์เก่าเพื่อเปลี่ยนเส้นทางผู้ใช้จากโดเมนเก่าไปยังชื่อใหม่เช่นจากwww.mycompany .com -> newsite.mycompany.com
— Johnny
ใช่ แต่หลายคนจะดูถูกความคิดที่ถูกต้องว่าต้องใช้ชื่อใหม่ ชื่อเป็นยี่ห้อ นอกจากนี้ยังใช้งานได้กับ HTTP เท่านั้นและไม่มีอะไรอื่นมากนัก
— สเวน
8
อีกทางเลือกหนึ่งคือการกำหนดค่าเซิร์ฟเวอร์เก่าเป็นพร็อกซีย้อนกลับไปยังเซิร์ฟเวอร์ใหม่ จากนั้นคุณสามารถปล่อยทิ้งไว้เป็นเวลาหนึ่งสัปดาห์หลังจากผ่านสวิตช์แล้วปิดเครื่องเมื่อไม่มีการจราจรติดขัด
— bdsl
1
ผู้ที่ทำหน้าที่ DNS เซิร์ฟเวอร์ที่เชื่อฟัง TTL จะไม่เห็นโดเมนใหม่ และแม้ว่าจะใช้งานได้กับ "HTTP" เท่านั้นฉันคิดว่าคุณจะพบว่า HTTP เป็นโปรโตคอลที่ใช้กันทั่วไปในอินเทอร์เน็ต คำแนะนำของ bdsl ในการตั้งค่า reverse proxy นั้นดีกว่า แต่ก็ใช้ได้มากกว่า
— Johnny
@Johnny ปัญหาเกี่ยวกับโดเมนใหม่คือคุณเสี่ยงต่อการที่คนคั่นหน้าโดเมนนั้น ยกเว้นว่าคุณวางแผนที่จะออกจากที่กล่าวว่าโดเมนใหม่สามารถเข้าถึงได้ตลอดไป
— บ๊อบ
5

การดึงความคิดเห็นและคำตอบต่าง ๆ เข้าด้วยกันกระบวนการที่สมบูรณ์จะเป็นอย่างไร

  1. ตรวจสอบให้แน่ใจว่าคุณสามารถอัปเดตเซิร์ฟเวอร์เผด็จการได้ทันเวลา
  2. ลด TTL
  3. ตรวจสอบเซิร์ฟเวอร์ Authoratatitive ทั้งหมดมี ttl ใหม่
  4. รอ TTL เก่าเพื่อให้ค่าที่แคชกับ TTL เก่า (ส่วนใหญ่) ถูกลบออกจากแคช (คุณไม่สามารถรับประกันได้ว่าพวกเขาจะหายไปจากทุกแคชเพราะบางแคชอาจเพิกเฉยต่อมาตรฐาน)
  5. วางไซต์บนเซิร์ฟเวอร์เก่าให้อยู่ในโหมดอ่านอย่างเดียว (หรือถ้าคุณไม่สามารถทำเช่นนั้นได้ให้แทนที่ด้วยหน้า "เราพร้อมสำหรับการบำรุงรักษา")
  6. ทำสำเนาสุดท้ายจากเซิร์ฟเวอร์เก่าไปยังเซิร์ฟเวอร์ใหม่ (ทำให้ไซต์อ่านอย่างเดียวบนเซิร์ฟเวอร์ใหม่)
  7. เปลี่ยนระเบียน DNS
  8. ตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์เผด็จการมีระเบียน DNS ใหม่
  9. รอ ttl ใหม่ (คุณสามารถข้ามขั้นตอนนี้หากคุณไม่สนใจผู้ใช้บางคนที่สามารถมีส่วนร่วมในเว็บไซต์และผู้ใช้รายอื่นที่ไม่เห็นผลลัพธ์ของการมีส่วนร่วมเหล่านั้น)
  10. วางไซต์บนเซิร์ฟเวอร์ใหม่เข้าสู่โหมดอ่าน / เขียน
  11. วางการแจ้งเตือนบนเซิร์ฟเวอร์เก่าว่าเป็นสำเนาแบบอ่านอย่างเดียวที่ล้าสมัยและผู้ใช้น่าจะมี DNS ที่เสียหาย
  12. รอสักครู่เพื่อให้ระเบียนเลื่อนออกจากแคช DNS ที่ไม่สอดคล้อง
  13. การรื้อถอนเซิร์ฟเวอร์เก่า
— ปีเตอร์กรีน
แหล่งที่มา
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.