มีความเสี่ยงที่จะเริ่ม NTP บนเซิร์ฟเวอร์ฐานข้อมูลหรือไม่

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

ฉันมีเซิร์ฟเวอร์ Postgres 9.3 ที่ใช้งานจริงผลิตบนโฮสต์ Debian Wheezy และเวลาปิดลง 367 วินาที ฉันสามารถเรียกใช้ntpdateหรือเริ่ม openntp ขณะที่ Postgres ทำงานอยู่หรือมีแนวโน้มที่จะทำให้เกิดปัญหาหรือไม่ ถ้าเป็นเช่นนั้นวิธีที่ปลอดภัยกว่าในการแก้ไขเวลาคืออะไร

มีบริการอื่น ๆ ที่ไวต่อการเปลี่ยนแปลงเวลาของระบบหรือไม่ อาจเป็นเซิร์ฟเวอร์เมล (exim, sendmail, etc) หรือคิวข้อความ (activemq, rabbitmq, zeromq ฯลฯ )?

ฐานข้อมูลไม่ชอบขั้นตอนย้อนหลังดังนั้นคุณไม่ต้องการเริ่มต้นด้วยพฤติกรรมเริ่มต้นของการกระโดดเวลา การเพิ่ม-xตัวเลือกในบรรทัดคำสั่งจะเป็นการฆ่าเวลาหากออฟเซ็ตน้อยกว่า 600 วินาที (10 นาที) อัตราการฆ่าสูงสุดจะใช้เวลาประมาณหนึ่งวันครึ่งในการปรับนาฬิกาเป็นนาที นี่เป็นวิธีที่ช้า แต่ปลอดภัยในการปรับเวลา

ก่อนที่จะทำงานntpเพื่อปรับเวลาคุณอาจต้องการเริ่มต้นntpด้วยตัวเลือกที่ต้องการ-g 2ตรวจสอบว่ามีการตรวจจับออฟเซ็ตขนาดใหญ่เพียงใด วิธีนี้จะตั้งค่าความตื่นตระหนกเป็น 2 วินาทีซึ่งน่าจะปลอดภัย

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

ตัวเลือกทั่วไปคือการปิดเซิร์ฟเวอร์นานพอที่จะไม่มีการเคลื่อนไหวย้อนหลังของนาฬิกา ntpหรือntpdateสามารถกำหนดค่าให้ข้ามนาฬิกาไปยังเวลาที่ถูกต้องเมื่อเริ่มต้นขึ้น สิ่งนี้ควรทำก่อนที่ฐานข้อมูลจะเริ่มต้น

ฐานข้อมูลอาจมีความเสี่ยงต่อการเปลี่ยนแปลงเวลาของระบบโดยเฉพาะอย่างยิ่งหากมีการใช้งานมากและมีการประทับเวลาในบันทึกภายใน โดยทั่วไปหากคุณมีเวลาเหลือคุณจะมีปัญหาน้อยลงหากคุณกระโดดไปข้างหน้าอย่างรวดเร็วกว่าที่อยู่ข้างหน้าและกระโดดไปข้างหลังทันที

Joffrey ชี้ว่า - บ่อยครั้งที่แอปพลิเคชั่นที่มีปัญหาเกี่ยวกับการข้ามเวลาอย่างฉับพลันมากกว่าฐานข้อมูลเอง วิธีที่ปลอดภัยที่สุดในการแก้ไขเวลาคือปิดแอปพลิเคชันเป็นเวลา N + 1 นาที (โดยที่ N คือจำนวนนาทีที่นาฬิการะบบของคุณอยู่ข้างหน้า) จากนั้นซิงค์เวลาเริ่ม NTP แล้วรีสตาร์ทแอปพลิเคชัน หากคุณไม่สามารถหยุดทำงานได้ในแอพพลิเคชั่นฉันสามารถแนะนำให้คุณทำการสำรองข้อมูลของฐานข้อมูลก่อนที่จะทำการซิงค์จากนั้นให้กระรอกตายไปยังคอมพิวเตอร์ของคุณแล้วดึงไกปืน ตกลงฉันเป็นคนขี้กลัวเล็กน้อย แต่ฉันไม่สามารถคิดถึงวิธี "ปลอดภัย" อื่นใดนอกเหนือจากการหยุดทำงานของแอปพลิเคชัน

มักจะไม่ใช่เซิร์ฟเวอร์ฐานข้อมูลที่เสี่ยงต่อการเกิดข้อผิดพลาดเมื่อมีการกระโดดข้ามเวลาทันที: แอปพลิเคชันที่ใช้เวลา

โดยทั่วไปมีสองวิธีในการติดตามเวลา: การติดตามเวลาของตัวเองหรือการเปรียบเทียบเวลาของระบบ ทั้งสองมีการแลกเปลี่ยนเชิงบวกและลบ

ติดตามเวลาของตัวเอง

ฉันเห็นสิ่งนี้ใช้ในการเขียนโปรแกรมและระบบฝังตัวบางตัวซึ่งการกำหนดเวลาที่แน่นอนไม่ใช่สิ่งสำคัญ ในแอปพลิเคชันหลักจะมีการติดตามวิธีการ 'ติ๊ก' นี่อาจเป็นสัญญาณเตือนที่กำหนดโดยเคอร์เนล, สลีปหรือตัวเลือกที่แสดงถึงเวลาที่ผ่านไป เมื่อคุณรู้ว่าเวลาใดผ่านไปแล้วคุณจะรู้ว่าคุณสามารถเพิ่มหรือลบเวลานี้กับตัวนับ ตัวนับนี้เป็นสิ่งที่ทำให้แอปพลิเคชันกำหนดเวลาของคุณเกิดขึ้น ตัวอย่างเช่นหากตัวนับสูงกว่า 10 วินาทีคุณสามารถทิ้งบางสิ่งบางอย่างหรือคุณต้องทำบางสิ่งบางอย่าง

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

มือโปร:

• ไม่ขึ้นอยู่กับนาฬิกาของระบบ
• จะไม่แตกหักเป็นครั้งใหญ่
• ไม่มีการเรียกระบบที่มีราคาแพง
• เคาน์เตอร์ขนาดเล็กจะมีค่าใช้จ่ายหน่วยความจำน้อยกว่าการประทับเวลาเต็ม

Con:

• เวลาไม่แม่นยำมาก
• การเปลี่ยนเวลาของระบบอาจทำให้คลาดเคลื่อนมากขึ้น
• การกำหนดเวลาสัมพันธ์กับการเรียกใช้แอปพลิเคชันไม่คงอยู่

เปรียบเทียบเวลาของระบบ

นี่คือระบบที่ใช้บ่อยกว่า: เก็บการประทับเวลาและเปรียบเทียบกับการประทับเวลาโดยใช้การเรียกเวลาของระบบ การบิดเบือนครั้งใหญ่ในเวลาระบบอาจคุกคามความสมบูรณ์ของแอปพลิเคชันของคุณงานที่ใช้เวลาสองสามวินาทีอาจใช้เวลาหลายชั่วโมงหรือสิ้นสุดทันทีขึ้นอยู่กับทิศทางของนาฬิกา

มือโปร:

• การเปรียบเทียบเวลาที่แม่นยำ
• ยังคงมีมากกว่าการเริ่มต้นใหม่และการหยุดทำงานนาน

Con:

• ใช้การเรียกของระบบเพื่อรับการประทับเวลาใหม่เพื่อเปรียบเทียบกับการประทับเวลาอื่น ๆ
• แอปพลิเคชั่นต้องระวังการบิดหรือแตก

ระบบที่ได้รับผลกระทบ

แอปพลิเคชั่นส่วนใหญ่จะใช้การประทับเวลาเปรียบเทียบกับกำหนดเวลางาน สำหรับระบบฐานข้อมูลที่อาจเป็นการล้างแคช

แอปพลิเคชันทั้งหมดที่ใช้ฐานข้อมูลและฟังก์ชั่นเวลาโทรในภาษาแบบสอบถามจะได้รับผลกระทบจากการเบ้หากแอปพลิเคชันไม่ตรวจจับและจัดการตามลำดับ แอปพลิเคชันไม่สามารถหยุดการทำงานหรืออนุญาตช่วงเวลาการล็อกอินที่ไม่ จำกัด โดยขึ้นอยู่กับวัตถุประสงค์ของมัน

ระบบเมลจะใช้การประทับเวลาและ / หรือหมดเวลาสำหรับการจัดการอีเมลที่ค้างหรือไม่ได้ส่งมอบ นาฬิกาเอียงอาจส่งผลกระทบต่อสิ่งนั้น แต่มีผลกระทบน้อยกว่ามาก ตัวจับเวลา Back-off ที่เกี่ยวกับการเชื่อมต่อกับเซิร์ฟเวอร์อาจพลาดได้

ฉันไม่คิดว่า (ไม่ได้วิจัย) ว่าสัญญาณเตือนเคอร์เนลจะดับลงเมื่อเปลี่ยนเวลาของระบบ ระบบที่ใช้สิ่งเหล่านี้อาจปลอดภัย

โซลูชั่น

ค่อยๆขยับเวลา สามารถดูได้ในเอกสารของการแก้ไขเวลาที่คุณชื่นชอบ