Алгоритм, обеспечивающий согласованность данных на всех узлах кластера, использует время системных часов, установленных на машине. Таким образом, зависит от расхождения времени на разных машинах, поскольку координатор запросов всегда дожидается машины с наибольшим отставанием. Поэтому принципиально важно, чтобы время на всех связанных узлах кластера Shardman было синхронизировано, поскольку отсутствие этой синхронизации может негативно повлиять на производительность Shardman из-за увеличенной задержки фиксации транзакции.

Во-первых, для обеспечения синхронизации времени на всех узлах кластера установите и разверните демон chrony.

  sudo apt update
  sudo apt install -y chrony
  sudo systemctl enable --now chrony

Проверьте, что chrony работает правильно.

chronyc tracking

Ожидаемый вывод:

      Reference ID    : C0248F82 (Time100.Stupi.SE)
      Stratum         : 2
      Ref time (UTC)  : Tue Apr 18 11:50:44 2023
      System time     : 0.000019457 seconds slow of NTP time
      Last offset     : -0.000005579 seconds
      RMS offset      : 0.000089375 seconds
      Frequency       : 30.777 ppm fast
      Residual freq   : -0.000 ppm
      Skew            : 0.003 ppm
      Root delay      : 0.018349268 seconds
      Root dispersion : 0.000334640 seconds
      Update interval : 1039.1 seconds
      Leap status     : Normal

Обратите внимание, что контроль величины расхождения часов должен выполняться инструментарием операционной системы. Средства диагностики Shardman не могут являться единственным достоверным средством измерения.

Чтобы проверить, существует ли на данный момент существенная рассинхронизация, используйте представление shardman.pg_stat_csn, которое выводит статистику задержек, возникающих во время импорта снимков CSN. Расчёт значений производится непосредственно в момент соответствующего действия или при вызове функций shardman.trim_csnxid_map() или shardman.pg_oldest_csn_snapshot(). Вызов этих функций осуществляется из служебного процесса csn trimmer routine (процесс усечения CSN), поэтому его отключение приведёт к остановке сбора этой статистики.

Поле csn_max_shift представления shardman.pg_stat_csn отображает максимальную задержку снимка CSN, вызвавшего задержку. Это значение определяет расхождение часов между узлами кластера. Последовательный рост этого значения является индикатором того, что в кластере есть по крайней мере одни часы, не синхронизованные с другими. Если данное значение превышает 1000 микросекунд, рекомендуется проверить параметры синхронизации по времени.

Другим индикатором расхождения может быть повышение значения csn_total_import_delay при неизменном значении csn_max_shift. Однако разовое повышение может быть вызвано единичным сбоем, а не проблемами с синхронизацией по времени.

Кроме того, если разница между CSNXidMap_head_csn и shardman.oldest_csn превышает значение параметра csn_snapshot_defer_time и долгое время не меняется, это значит, что заполнилась карта CSNSnapshotXidMap. Это может привести к сбою глобальной транзакции.

У этой проблемы две возможные причины.

При выполнении команды EXPLAIN для распределённых запросов, при включённом параметре конфигурации shardman.silk_tracepoints выводится информация о трассировке времени прохождения запроса и результата его выполнения по компонентам системы. Эта информация состоит из строк со значениями метрик, которые показывают время прохождения через каждый компонент. Метрики net (qry), net (1st tup) и net (last tup) вычисляются как разница отметок времени на разных серверах. Эта величина включает в себя время передачи сообщения и величину (положительную или отрицательную) сдвига часов между серверами. Таким образом, по величине этих метрик возможно косвенно оценить расхождение часов между серверами.