Redundant database

This guide covers methods for replicating, synchronizing, and migrating the VoIPmonitor CDR database between instances.

Overview

VoIPmonitor offers the following methods for CDR synchronization:

Method	Description	Use Case
Database Backup Mode	Dedicated sniffer reads from source DB, writes to destination DB	Online migration, read-only replicas, hot-standby
Master-Master Replication	Bidirectional MySQL/MariaDB replication	Full HA with automatic failover (see Master-Master Replication)

ℹ️ Note: Both methods synchronize CDR data only. GUI settings (users, alerts, capture rules) must be migrated separately via Tools → Backup & Restore.

Database Backup Mode

A dedicated VoIPmonitor instance reads CDRs from a source database and writes them to a destination database. This is the recommended method for online GUI migration.

Architecture

Online GUI Migration Workflow

1. Install VoIPmonitor GUI on the new server with a fresh database
2. Backup configuration: On old GUI → Tools → Backup & Restore → backup configuration tables
3. Restore configuration: On new GUI → upload the backup file (do this BEFORE starting migration)
4. Create migration config file (see below)
5. Start migration instance
6. Once replication catches up, switch users to the new GUI
7. Stop migration instance and decommission old server

Configuration

Copy the original config and modify for migration mode:

scp root@old-server:/etc/voipmonitor.conf /etc/voipmonitor-migrate.conf

Required modifications in /etc/voipmonitor-migrate.conf:

# 1. Avoid port conflict with production sniffer
managerport = 5030

# 2. DISABLE packet capture (comment out all interface lines)
# interface = eth0

# 3. Destination Database (NEW server - local)
mysqlhost      = 127.0.0.1
mysqldb        = voipmonitor
mysqlusername  = root
mysqlpassword  = new_password

# 4. Source Database (OLD server - remote)
database_backup_from_mysqlhost     = 192.168.0.1
database_backup_from_mysqldb       = voipmonitor
database_backup_from_mysqlusername = root
database_backup_from_mysqlpassword = old_password

# 5. Start date for replication
database_backup_from_date = 2024-01-01

# 6. Performance tuning
database_backup_insert_threads = 3   # Higher = faster but more load
database_backup_pause          = 3   # Higher = less load on source DB

Parameter Reference:

Parameter	Description
database_backup_from_date	Start date for sync (YYYY-MM-DD)
database_backup_insert_threads	Parallel write threads (higher = faster, more load)
database_backup_pause	Seconds between batches (higher = gentler on source DB)
database_backup_desc_dir	Set yes to also write new incoming data to destination

Running the Migration

Test manually first:

voipmonitor --config-file /etc/voipmonitor-migrate.conf -k -v 1

Run as systemd service:

Create /etc/systemd/system/voipmonitor-migrate.service:

[Unit]
Description=VoIPmonitor Database Migration
After=network.target mysql.service

[Service]
Type=simple
ExecStart=/usr/local/sbin/voipmonitor -c /etc/voipmonitor-migrate.conf
Restart=on-failure

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl enable --now voipmonitor-migrate

Migrating PCAP Files

Database migration does NOT include PCAP files. Migrate separately using rsync:

rsync -avz root@old-server:/var/spool/voipmonitor/ /var/spool/voipmonitor/

⚠️ Warning: Timezone must match between servers. PCAP paths use local timezone (spooldir/YYYY-MM-DD/HH/MM/). Mismatched timezones cause GUI to fail finding historical PCAPs.

# Check timezone
timedatectl

# Set timezone
timedatectl set-timezone Europe/Prague

Schema Compatibility

The migration instance automatically handles database schema upgrades. This is useful when:

• Migrating to different MySQL/MariaDB versions
• Upgrading VoIPmonitor versions during migration
• Moving from local MySQL to remote Percona

To identify schema changes manually:

systemctl restart voipmonitor
tail -f /var/log/voipmonitor/voipmonitor.log | grep -E "CLI|ALTER|CREATE TABLE"

⚠️ Warning: For cross-version migration (e.g., MySQL 5.7 to 8.0), use the migration instance method instead of mysqldump. It handles schema differences automatically.

See Also

• Master-Master Replication
• Backing Up GUI Configuration
• Multiple Sniffer Instances

AI Summary for RAG

Summary

VoIPmonitor provides two methods for CDR database redundancy and migration: (1) Database Backup Mode — a dedicated VoIPmonitor migration instance (with no packet capture) reads CDRs from a source database and writes them to a destination database using database_backup_from_* parameters. This is the recommended method for online GUI migration between servers. The migration instance uses a separate config file (/etc/voipmonitor-migrate.conf) with managerport = 5030 to avoid conflicts with the production sniffer. Key parameters: database_backup_from_mysqlhost, database_backup_from_mysqldb, database_backup_from_mysqlusername, database_backup_from_mysqlpassword, database_backup_from_date (start date), database_backup_insert_threads (parallelism), database_backup_pause (throttling), database_backup_desc_dir (write new incoming data too). (2) Master-Master Replication — standard bidirectional MySQL/MariaDB replication for full HA with automatic failover (documented separately). Both methods synchronize CDR data only — GUI settings must be migrated via Tools → Backup & Restore. PCAP files must be migrated separately using rsync, and timezones must match between servers or historical PCAPs will not be found in the GUI. The migration instance handles schema upgrades automatically, making it suitable for cross-version migrations (e.g., MySQL 5.7 to 8.0). Important: There is NO "dual write" or "mysql2*" parameter feature — parameters like mysql2host, mysql2db do not exist in VoIPmonitor.

Keywords

database backup, migration, redundant database, CDR replication, database_backup_from_mysqlhost, database_backup_from_date, database_backup_insert_threads, database_backup_pause, database_backup_desc_dir, managerport, voipmonitor-migrate.conf, PCAP migration, rsync, timezone, schema compatibility, MySQL migration, MariaDB, master-master replication, GUI migration, Backup & Restore, high availability, hot-standby, systemd service

Key Questions

• How do I migrate VoIPmonitor database to a new server?
• How to replicate CDR data between two VoIPmonitor instances?
• What are the database_backup_from parameters for database migration?
• How to configure a VoIPmonitor migration instance?
• How to move old CDR records to another server for archiving?
• How to migrate PCAP files to a new server?
• Why do PCAP files not show after server migration?
• Does VoIPmonitor support writing CDRs to two databases simultaneously?
• What is the difference between database backup mode and master-master replication?
• How to handle MySQL version differences during migration?
• How to run VoIPmonitor migration as a systemd service?
• What is database_backup_desc_dir used for?
• How to throttle database migration to reduce load on source server?
• How to migrate GUI settings (users, alerts, capture rules)?