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
- Install VoIPmonitor GUI on the new server with a fresh database
- Backup configuration: On old GUI → Tools → Backup & Restore → backup configuration tables
- Restore configuration: On new GUI → upload the backup file (do this BEFORE starting migration)
- Create migration config file (see below)
- Start migration instance
- Once replication catches up, switch users to the new GUI
- 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. CRITICAL: Pre-create partitions for historical dates
# Must match (or be earlier than) database_backup_from_date above.
# Without this, all migrated CDRs land in a single partition and
# cleandatabase cannot DROP old partitions by calldate.
create_old_partitions_from = 2024-01-01
# Alternative: create partitions for the last N days
# create_old_partitions = 365
# 7. Performance tuning
database_backup_insert_threads = 3 # Higher = faster but more load
database_backup_pause = 3 # Higher = less load on source DB
⚠️ Warning: Partitions must exist for all migrated dates before migration starts. By default, VoIPmonitor only creates partitions for the current day and create_new_partitions days ahead (default: 2). If historical CDRs are inserted without matching partitions, they all end up in a single partition — and cleandatabase (which uses DROP PARTITION by calldate) will no longer be able to remove old data selectively. Always set create_old_partitions_from to the same date as database_backup_from_date.
Verify partitions after first start:
SELECT PARTITION_NAME, PARTITION_DESCRIPTION
FROM information_schema.PARTITIONS
WHERE TABLE_NAME = 'cdr'
ORDER BY PARTITION_ORDINAL_POSITION
LIMIT 10;
Parameter Reference:
| Parameter | Description |
|---|---|
database_backup_from_date |
Start date for sync (YYYY-MM-DD) |
create_old_partitions_from |
(Critical for migration) Create partitions from this date (YYYY-MM-DD). Should match database_backup_from_date.
|
create_old_partitions |
Alternative: create partitions for the last N days (integer) |
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 allow write new CDRs to destination db instead of to sourcedb
|
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
AI Summary for RAG
Summary: VoIPmonitor supports two methods for CDR database redundancy: (1) Database Backup Mode — a dedicated migration instance reads CDRs from source DB and writes to destination using database_backup_from_* parameters, recommended for online server migration; (2) Master-Master MySQL replication for full HA. GUI settings migrate separately via Backup & Restore. PCAP files require separate rsync migration with matching timezones.
Keywords: database backup, migration, redundant database, CDR replication, database_backup_from_mysqlhost, database_backup_from_date, database_backup_insert_threads, database_backup_pause, voipmonitor-migrate.conf, PCAP migration, rsync, timezone, master-master replication, high availability
Key Questions:
- How to migrate VoIPmonitor database to a new server?
- What are the database_backup_from parameters for database migration?
- How to move old CDR records to another server?
- How to migrate PCAP files to a new server?
- What is the difference between database backup mode and master-master replication?
- How to migrate GUI settings between servers?