Skip to content
Platform Documentation

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, files are first replicated to Worker nodes via lsyncd, 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 worker 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 Worker 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.
  • File sync delay (cluster only) — Configuration files must be replicated before commands execute. Check systemctl status lsyncd on the Manager node.
  • Network issues — If server connectivity checks fail, verify firewall rules and network connectivity between the Manager and Worker servers.
  • 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.