DEV Community

Michael
Michael

Posted on • Originally published at gbase8.cn

Replacing ntpdate with chronyc on Anolis OS for GBase 8a Cluster Time Sync

#gbase #database #数据库 #operations

When a gbase database cluster deployed on Anolis OS 8.9 is powered off for an extended period, the system clock can drift significantly. Since modern Anolis releases no longer ship ntpdate and cannot install the legacy NTP service, chronyc becomes the go‑to tool for time synchronization. This article demonstrates how to force a time sync, check the synchronization status, and inspect NTP sources using chronyc, ensuring your GBase 8a cluster's time‑dependent operations return to normal.

Verify the Operating System

This example runs on Anolis OS 8.9:

[root@vm151 ~]# cat /etc/os-release
NAME="Anolis OS"
VERSION="8.9"
ID="anolis"
ID_LIKE="rhel fedora centos"
VERSION_ID="8.9"
PLATFORM_ID="platform:an8"
PRETTY_NAME="Anolis OS 8.9"
ANSI_COLOR="0;31"
HOME_URL="https://openanolis.cn/"

[root@vm151 ~]# cat /etc/anolis-release
Anolis OS release 8.9
Enter fullscreen mode Exit fullscreen mode

Core Commands

1. Force Immediate Synchronization – chronyc makestep

This command immediately steps the system clock to the NTP time, which can cause a noticeable jump but is ideal when you need an instant correction.

[root@vm151 ~]# date
Tue Feb 24 23:56:04 CST 2026
[root@vm151 ~]# chronyc makestep
200 OK
[root@vm151 ~]# date
Wed Feb 25 08:56:36 CST 2026
Enter fullscreen mode Exit fullscreen mode

The output shows the clock jumped from late evening on Feb 24 to the morning of Feb 25, aligning with the NTP server.

2. Check Synchronization Status – chronyc tracking

This provides a snapshot of the chronyd synchronization state: the remote server, stratum, and the time offset. When System time is near zero and Leap status is Normal, your clock is properly synced.

Before synchronization (offset roughly 32 414 seconds):

[root@vm151 ~]# chronyc tracking
Reference ID    : CB6B0658 (203.107.6.88)
Stratum         : 3
Ref time (UTC)  : Wed Feb 25 00:50:13 2026
System time     : 32414.154296875 seconds slow of NTP time
Last offset     : -0.000094009 seconds
RMS offset      : 3076.199462891 seconds
Frequency       : 6.521 ppm slow
Residual freq   : -0.006 ppm
Skew            : 2.104 ppm
Root delay      : 0.038376234 seconds
Root dispersion : 0.003302030 seconds
Update interval : 515.2 seconds
Leap status     : Normal
Enter fullscreen mode Exit fullscreen mode

After synchronization (offset virtually zero):

[root@vm151 ~]# chronyc tracking
Reference ID    : CB6B0658 (203.107.6.88)
Stratum         : 3
Ref time (UTC)  : Wed Feb 25 01:07:00 2026
System time     : 0.000000001 seconds slow of NTP time
Last offset     : -0.000908873 seconds
RMS offset      : 2768.579589844 seconds
Frequency       : 6.766 ppm slow
Residual freq   : -0.070 ppm
Skew            : 1.915 ppm
Root delay      : 0.039329700 seconds
Root dispersion : 0.004922534 seconds
Update interval : 521.5 seconds
Leap status     : Normal
Enter fullscreen mode Exit fullscreen mode

Field descriptions for chronyc tracking:

  • Reference ID: IP address of the remote NTP server being used.
  • Stratum: The machine's level in the NTP hierarchy (1 = directly connected to an atomic clock or GPS; 2 = synced to stratum‑1, etc.).
  • Ref time (UTC): The UTC time when the last update was received from the remote server.
  • System time: Difference between the local clock and the NTP time (slow means the local clock is behind; fast means it is ahead).
  • Last offset: The measured offset during the most recent synchronization.
  • RMS offset: Root‑mean‑square of the time offsets, indicating synchronization accuracy.
  • Frequency: The local clock's frequency error, in parts per million (ppm). slow means the local oscillator runs slower than a perfect clock.
  • Residual freq: Change in the local clock frequency since the last sync.
  • Skew: Uncertainty of the frequency estimate.
  • Root delay: Round‑trip time to the synchronization source.
  • Root dispersion: Maximum possible error of the synchronization source.
  • Update interval: Seconds between consecutive updates.
  • Leap status: Leap‑second status (Normal, Insert second, or Delete second).

3. Inspect NTP Source Servers – chronyc sources -v

This lists the NTP sources chronyd is using, along with their state and offset.

[root@vm151 ~]# chronyc sources -v

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* 203.107.6.88                  2  10   377   855  -5627us[-6536us] +/-   29ms
Enter fullscreen mode Exit fullscreen mode

The ^* indicates this server is the current best source and is reachable.

Summary

GBase 8a clusters rely on accurate system time for distributed transactions and log coordination. On modern Anolis (and similar RHEL‑based) systems, chronyc is the default time‑synchronization tool. Use chronyc makestep to force a quick correction, then verify with chronyc tracking and chronyc sources -v. Consider adding chronyc makestep to a periodic cron job to prevent clock drift after extended shutdowns, keeping your gbase database cluster running smoothly.

Top comments (0)