Rủi ro bắt đầu NTP trên máy chủ cơ sở dữ liệu?

Tôi đã nghe tin đồn về những điều tồi tệ xảy ra với cơ sở dữ liệu và máy chủ thư nếu bạn thay đổi thời gian hệ thống trong khi chúng đang chạy. Tuy nhiên, tôi đang gặp khó khăn trong việc tìm kiếm bất kỳ thông tin cụ thể nào về rủi ro thực tế.

Tôi có một máy chủ Postgres 9.3 sản xuất đang chạy trên máy chủ Debian Wheezy và thời gian tắt là 367 giây. Tôi chỉ có thể chạy ntpdatehoặc bắt đầu openntp trong khi Postgres đang chạy, hoặc điều đó có khả năng gây ra sự cố không? Nếu vậy, một phương pháp an toàn hơn để sửa thời gian là gì?

Có dịch vụ nào khác nhạy cảm hơn với sự thay đổi trong thời gian hệ thống không? Có thể các máy chủ thư (exim, sendmail, v.v.) hoặc hàng đợi tin nhắn (activemq, rabbitmq, zeromq, v.v.)?

Cơ sở dữ liệu không thích các bước lùi theo thời gian, vì vậy bạn không muốn bắt đầu với hành vi mặc định là nhảy thời gian. Thêm -xtùy chọn vào dòng lệnh sẽ xoay thời gian nếu độ lệch nhỏ hơn 600 giây (10 phút). Ở tốc độ xoay tối đa, sẽ mất khoảng một ngày rưỡi để điều chỉnh đồng hồ trong một phút. Đây là một cách chậm nhưng an toàn để điều chỉnh thời gian.

Trước khi chạy ntpđể điều chỉnh thời gian, bạn có thể muốn bắt đầu ntpvới một tùy chọn như -g 2để xác minh mức độ bù mà nó đang phát hiện. Điều này sẽ đặt bù trừ hoảng loạn thành 2 giây, tương đối an toàn.

Một tùy chọn thay thế mà tôi đã sử dụng trước khi tùy chọn này có sẵn là viết một vòng lặp đặt lại phần đồng hồ trở lại của giây mỗi phút hoặc lâu hơn. Nếu bạn kiểm tra để đảm bảo thiết lập lại sẽ không thay đổi lần thứ hai thì điều này có khả năng an toàn. Nếu bạn sử dụng dấu thời gian nhiều, bạn có thể đã hết các bản ghi trình tự.

Một tùy chọn phổ biến là tắt máy chủ đủ lâu để không có chuyển động lùi của đồng hồ. ntphoặc ntpdatecó thể được cấu hình để nhảy đồng hồ đến đúng thời điểm khi khởi động. Điều này nên được thực hiện trước khi cơ sở dữ liệu được bắt đầu.

Cơ sở dữ liệu có thể đặc biệt dễ bị tổn thương khi thay đổi thời gian hệ thống nếu chúng rất tích cực và có dấu thời gian trong hồ sơ nội bộ. Nói chung, nếu thời gian của bạn ở phía sau, bạn sẽ gặp ít vấn đề hơn nếu bạn đột nhiên nhảy về phía trước so với khi bạn đi trước và đột nhiên nhảy lùi lại.

Như Joffrey chỉ ra - đó thường là ứng dụng có vấn đề với thời gian nhảy đột ngột so với chính cơ sở dữ liệu. Cách an toàn nhất để sửa thời gian là tắt ứng dụng trong N + 1 phút (trong đó N là số phút đồng hồ hệ thống của bạn ở phía trước) và sau đó đồng bộ hóa thời gian, khởi động NTP và khởi động lại ứng dụng. Nếu bạn không thể sử dụng quá nhiều thời gian chết trong ứng dụng, tôi chỉ có thể đề nghị bạn sao lưu cơ sở dữ liệu trước khi đồng bộ hóa thời gian, sau đó cung cấp một con sóc chết cho goda của computerdom và chỉ cần bóp cò. Ok, tôi hơi khó tính, nhưng tôi không thể nghĩ ra bất kỳ cách "an toàn" nào khác ngoài việc ngừng hoạt động ứng dụng.

Nó thường không phải là máy chủ cơ sở dữ liệu dễ bị lỗi khi xảy ra bước nhảy vọt tức thời: đó là các ứng dụng sử dụng thời gian đó.

Nhìn chung có hai cách theo dõi thời gian: theo dõi thời gian riêng hoặc so sánh thời gian hệ thống. Cả hai đều có một số sự đánh đổi tích cực và tiêu cực.

Theo dõi thời gian riêng

Tôi thấy điều này được sử dụng trong một số hệ thống và lập trình nhúng trong đó thời gian chính xác không phải là vấn đề quan trọng. Trong một vòng lặp ứng dụng chính, một cách theo dõi 'đánh dấu' được quan tâm. Đây có thể là một báo động được đưa ra bởi kernel, ngủ hoặc chọn đưa ra dấu hiệu về thời gian trôi qua. Khi bạn biết thời gian đã trôi qua, bạn biết bạn có thể thêm hoặc bớt thời gian này vào một bộ đếm. Bộ đếm này là những gì làm cho ứng dụng thời gian của bạn xảy ra. Ví dụ: nếu bộ đếm cao hơn 10 giây, bạn có thể loại bỏ thứ gì đó hoặc bạn cần phải làm gì đó.

Nếu ứng dụng không theo dõi thời gian, bộ đếm sẽ không thay đổi. Điều này có thể được mong muốn tùy thuộc vào thiết kế ứng dụng của bạn. Ví dụ, theo dõi thời gian một quá trình dài đang thực hiện một cái gì đó được xử lý dễ dàng hơn với một bộ đếm so với danh sách các dấu thời gian bắt đầu / dừng.

Chuyên nghiệp:

• Không phụ thuộc vào đồng hồ hệ thống
• Sẽ không phá vỡ một thời gian lớn
• Không có cuộc gọi hệ thống tốn kém
• Bộ đếm nhỏ sẽ tốn ít bộ nhớ hơn so với dấu thời gian đầy đủ

Con:

• Thời gian không chính xác lắm
• Thay đổi thời gian hệ thống có thể làm cho nó thậm chí không chính xác hơn
• Thời gian liên quan đến việc chạy ứng dụng, không tồn tại

So sánh thời gian hệ thống

Đây là hệ thống được sử dụng thường xuyên hơn: lưu trữ dấu thời gian và so sánh nó với dấu thời gian bằng cách sử dụng cuộc gọi thời gian hệ thống. Những sai lệch lớn trong thời gian hệ thống có thể đe dọa tính toàn vẹn của ứng dụng của bạn, một nhiệm vụ trong vài giây có thể mất hàng giờ hoặc kết thúc ngay lập tức tùy thuộc vào hướng của đồng hồ.

Chuyên nghiệp:

• So sánh thời gian chính xác
• Tiếp tục khởi động lại và mất điện kéo dài

Con:

• Thực hiện cuộc gọi hệ thống để có dấu thời gian mới để so sánh với các dấu thời gian khác
• Ứng dụng cần phải nhận thức được các xiên hoặc có thể phá vỡ

Hệ thống bị ảnh hưởng

Hầu hết các ứng dụng sẽ sử dụng dấu thời gian so với lịch trình tác vụ. Đối với các hệ thống cơ sở dữ liệu có thể là dọn dẹp bộ đệm.

Tất cả các ứng dụng sử dụng cơ sở dữ liệu và chức năng gọi thời gian trong ngôn ngữ truy vấn sẽ bị ảnh hưởng bởi các xiên nếu ứng dụng không phát hiện và xử lý tương ứng. Các ứng dụng không bao giờ có thể ngừng chạy hoặc cho phép thời gian đăng nhập không xác định tùy thuộc vào mục đích của nó.

Hệ thống thư sẽ sử dụng dấu thời gian và / hoặc thời gian chờ để xử lý thư cũ hoặc không gửi được. Một xiên đồng hồ có thể ảnh hưởng đến điều đó nhưng với tác động ít hơn nhiều. Bộ đếm thời gian dự phòng liên quan đến việc kết nối lại với máy chủ có thể bị bỏ lỡ dẫn đến hình phạt trên máy chủ kết nối.

Tôi không nghĩ (chưa nghiên cứu) rằng các báo động kernel sẽ tắt khi thay đổi thời gian hệ thống. Các hệ thống sử dụng chúng có thể an toàn.

Các giải pháp

Nhẹ nhàng di chuyển thời gian. Điều này có thể được tìm thấy trong tài liệu của giải pháp thời gian yêu thích của bạn.