Skip to content
Thirdlane

Data Sync

Data Sync provides administrators with visibility into the configuration synchronization pipeline. It is available in Configuration Manager under Tools > Data Sync.

Overview

When you save a change in Configuration Manager, the system records it with a version number, regenerates configuration files, and queues commands (e.g., reload PBX dialplan, refresh Kamailio routing). The sync agent (cacher) running on each server picks up the commands and applies them.

In an all-in-one deployment this happens instantly on the local server. In a cluster, the files are copied out to the other servers first, and each server’s sync agent processes only its own commands.

Data Sync shows the real-time status of this pipeline and highlights any failures or delays.

What You Can See

The Data Sync screen provides several diagnostic checks:

  • Pending Changes — Configuration changes that have not yet been processed or delivered to the other servers. A non-zero count may indicate the sync agent is stopped or falling behind.
  • Server Connectivity — Verifies that the manager can communicate with each registered server over the network.
  • Sync Queue Status — Shows the current state of the sync command queue, including any stalled or failed entries. Each entry corresponds to a command that a specific server needs to execute.
  • Version Comparison — Compares the current configuration version on each server against the latest version. Servers that are behind have not yet applied recent changes.

Resolving Issues

When a problem is detected, the diagnostics output provides context to help determine the root cause:

  • Sync agent not running — Check with systemctl status cacher on the affected server. The sync agent must be running for changes to be applied.
  • Server version behind — The server may have missed commands or the agent may have been temporarily stopped. Check cacher logs on that server for errors.
  • Files not arriving (cluster only) — Configuration files must reach a server before its commands run. The copy runs on the manager, so check systemctl status lsyncd there.
  • Network issues — If server connectivity checks fail, verify firewall rules and network connectivity between the manager and the other servers.

Best practices

  • Check here first when a saved change doesn’t take effect. A non-zero Pending Changes count, a stalled queue entry, or a server behind on version usually explains why a phone, route, or setting isn’t behaving as configured.
  • Watch it after cluster maintenance. After updating or rebooting a telephony worker, confirm its version has caught up and connectivity is green before assuming the server is ready for calls.
  • Correlate with the Change Log. If a specific change appears stuck, the change log shows exactly what it was and when it was made.
  • Leave the deployment-mode switcher off in production. It exists only for dev/QA boxes and is hidden unless explicitly enabled.
  • Change Log — Shows all configuration changes with version numbers, useful for correlating issues with specific changes.
  • Data Sync Overview — How the sync architecture works.

Testing: switching deployment mode (admin-only)

For development and QA boxes only, the Data Sync screen can expose a bar at the top that lets you flip this server between All-in-One and Cluster on the fly. It is hidden by default and is controlled by a purely local flag, so enabling it on one machine never makes it appear on others.

To enable on a single server:

Terminal window
echo "mode_switcher_enabled=1" >> /etc/webmin/asterisk/instances.txt

Reload the Data Sync screen. The mode bar will appear above the normal diagnostics content, showing the current mode and letting you switch. Changing the mode writes the new value to both instances.txt and system_settings.deployment_mode, then reloads the app so menus and layouts rebuild.

Notes:

  • The flag lives only in /etc/webmin/asterisk/instances.txt. It is never stored in the database and never replicated.
  • The switcher is independent of the data_sync_debug_mode flag that controls the Simulate Updates / Purge History toolbar; either flag can be on without the other.
  • Existing rows in the servers table from a previous cluster configuration remain untouched in All-in-One mode. All-in-One code paths filter by local hostname, so extra rows are simply ignored and re-appear if you flip back to Cluster.
  • Posting to the setDeploymentMode action without this flag set returns success: 0 with a “Mode switcher is not enabled on this server.” message.

To disable, remove the line (or set it to 0) and reload.