Redundant database: Difference between revisions

From VoIPmonitor.org
(Review: oprava překlepů v odkazech (instancies->instances, aktualizace odkazu na Backing_Up_GUI_Configuration))
(Fix AI Summary format: use bold labels instead of sub-headings)
 
(10 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{DISPLAYTITLE:Active Calls (Real-time Monitoring)}}
{{DISPLAYTITLE:Database Redundancy and Migration}}
[[Category:GUI manual]]
[[Category:Configuration]]
[[Category:High Availability]]


This page describes the Active Calls view, which provides real-time monitoring of ongoing calls in the VoIPmonitor GUI.
This guide covers methods for replicating, synchronizing, and migrating the VoIPmonitor CDR database between instances.


== Overview ==
== Overview ==


The Active Calls view displays current calls in real time and allows you to listen to G.711 calls live (requires sniffer version 7 or newer). The view refreshes automatically according to the configured refresh interval (default: 2 seconds).
VoIPmonitor offers the following methods for CDR synchronization:


=== Communication with Sniffer ===
{| class="wikitable"
|-
! 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 [[Mysql_master-master_replication_hints|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 ===
 
<kroki lang="plantuml">
@startuml
skinparam shadowing false
skinparam defaultFontName Arial
 
rectangle "OLD Server" {
  rectangle "Sniffer" as SNIFF
  database "Source DB" as SRC
}


Live call data is fetched from the VoIPmonitor sniffer instance through the manager TCP port 5029. If calls are not displayed, verify that the web server can reach this port:
rectangle "NEW Server" {
  rectangle "Migration\nInstance" as MIG
  database "Destination DB" as DST
}


<kroki lang="mermaid">
SNIFF -down-> SRC : writes CDRs
flowchart LR
MIG -left-> SRC : reads\n(database_backup_from_*)
    subgraph GUI["Web GUI"]
MIG -down-> DST : writes\n(mysql*)
        Browser["Browser"]
 
        PHP["PHP Backend"]
note bottom of MIG
    end
  No packet capture
    subgraph Sniffer["VoIPmonitor Sniffer"]
  managerport = 5030
        Manager["Manager API<br/>Port 5029"]
end note
        Capture["Packet Capture"]
@enduml
    end
    Browser -->|HTTP/HTTPS| PHP
    PHP -->|TCP 5029| Manager
    Manager -->|Active Call Data| PHP
    Capture -->|Live Data| Manager
</kroki>
</kroki>
=== 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:


<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
telnet localhost 5029
scp root@old-server:/etc/voipmonitor.conf /etc/voipmonitor-migrate.conf
</syntaxhighlight>
</syntaxhighlight>


=== Direct URL Access ===
'''Required modifications in <code>/etc/voipmonitor-migrate.conf</code>:'''


You can open the Active Calls view directly using this URL format:
<syntaxhighlight lang="ini">
# 1. Avoid port conflict with production sniffer
managerport = 5030


<syntaxhighlight lang="text">
# 2. DISABLE packet capture (comment out all interface lines)
http://your-server/admin.php?activecalls=1
# interface = eth0
</syntaxhighlight>


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


The filter box adapts to the type of input provided. Calls can be filtered by:
# 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


* National or international (via combo box)
# 5. Start date for replication
* Sensor
database_backup_from_date = 2024-01-01
* IP address or IP prefix
* Phone number or prefix
* Call-ID


=== Filter Syntax Examples ===
# 6. Performance tuning
database_backup_insert_threads = 3  # Higher = faster but more load
database_backup_pause          = 3  # Higher = less load on source DB
</syntaxhighlight>
 
'''Parameter Reference:'''


{| class="wikitable"
{| class="wikitable"
|-
|-
! Input !! Description
! Parameter !! Description
|-
|-
| <code>192.168.%</code> || Filters calls with source or destination IP starting with 192.168.x.x
| <code>database_backup_from_date</code> || Start date for sync (YYYY-MM-DD)
|-
|-
| <code>00</code> || Filters calls where the number starts with 00
| <code>database_backup_insert_threads</code> || Parallel write threads (higher = faster, more load)
|-
|-
| <code>abc123</code> || Searches for exact Call-ID match
| <code>database_backup_pause</code> || Seconds between batches (higher = gentler on source DB)
|-
|-
| <code>%abc123%</code> || Searches for Call-ID containing "abc123" (substring match)
| <code>database_backup_desc_dir</code> || Set <code>yes</code> to also write new incoming data to destination
|}
|}


Note: By default, Call-ID search matches the full Call-ID string. To search for a substring, add the <code>%</code> wildcard character to the start and/or end of the search string.
=== Running the Migration ===


== Bottom Graphs ==
'''Test manually first:'''
<syntaxhighlight lang="bash">
voipmonitor --config-file /etc/voipmonitor-migrate.conf -k -v 1
</syntaxhighlight>


The bottom section of the Active Calls view displays graphs showing the top callers grouped by:
'''Run as systemd service:'''
* Caller IP address
* Called IP address


[[File:activecalls.png]]
Create <code>/etc/systemd/system/voipmonitor-migrate.service</code>:
<syntaxhighlight lang="ini">
[Unit]
Description=VoIPmonitor Database Migration
After=network.target mysql.service


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


The Active Calls view allows you to show or hide columns based on your preferences. This is useful when:
[Install]
WantedBy=multi-user.target
</syntaxhighlight>


* You want to reduce visual clutter and focus on specific information
<syntaxhighlight lang="bash">
* Certain columns contain data that is causing performance issues (e.g., parsing errors in the Proxy column)
systemctl daemon-reload
* Your display has limited screen space
systemctl enable --now voipmonitor-migrate
</syntaxhighlight>


To hide or show columns:
== Migrating PCAP Files ==


# Locate the column header area at the top of the table
Database migration does NOT include PCAP files. Migrate separately using rsync:
# Click on the column visibility icon (typically a column or grid icon) or look for a "Show columns" dropdown menu
# Uncheck columns you want to hide, check columns you want to show
# The view will update immediately with your selection


Your column visibility preferences are stored in the GUI configuration (saved in the MySQL <code>custom_config</code> table) and persist across sessions.
<syntaxhighlight lang="bash">
rsync -avz root@old-server:/var/spool/voipmonitor/ /var/spool/voipmonitor/
</syntaxhighlight>


=== Troubleshooting Performance Issues ===
{{Warning|1='''Timezone must match between servers.''' PCAP paths use local timezone (<code>spooldir/YYYY-MM-DD/HH/MM/</code>). Mismatched timezones cause GUI to fail finding historical PCAPs.}}


If the Active Calls view becomes unresponsive or slow, particularly when displaying certain columns like "Proxy":
<syntaxhighlight lang="bash">
# Check timezone
timedatectl


;Temporary workaround:
# Set timezone
:Hide the problematic column using the column visibility method above.
timedatectl set-timezone Europe/Prague
 
;If the GUI is completely unresponsive:
:* Connect directly to the GUI database
:* Check the <code>custom_config</code> table for column visibility settings
:* Clear or modify the relevant configuration entries
:* Contact support with SSH access to the GUI host for investigation
 
;Information to provide for support:
:* A SIP PCAP dump of a problematic call (to identify data causing parsing errors)
:* A mysqldump of the <code>voipmonitor.custom_config</code> table (to review current column configuration)
 
== Programmatic Access to Active Calls ==
 
In addition to viewing active calls in the GUI, you can programmatically retrieve active call data for automation and integration purposes.
 
=== GUI API (Recommended for Centralized Systems) ===
 
The VoIPmonitor GUI provides a web API endpoint <code>listActiveCalls</code> that retrieves active calls from all connected sensors/probes. This is the preferred method for centralized monitoring environments.
 
*Method:* HTTP POST or GET to <code>/php/api.php?task=listActiveCalls</code>
*Documentation:* [[WEB_API#listActiveCalls]]
 
Example:
<syntaxhighlight lang="bash">
curl -X POST 'http://yourserver/php/api.php?task=listActiveCalls&user=USER&password=PASSWORD&params={"sensorId":"1"}'
</syntaxhighlight>
</syntaxhighlight>


=== Sniffer Manager API (For Individual Sensors) ===
== Schema Compatibility ==
 
For direct access to a single sensor instance, use the sniffer service's manager API on port 5029. The <code>listcalls</code> command retrieves active call data from the specific sensor.


*Method:* TCP connection to port 5029
The migration instance automatically handles database schema upgrades. This is useful when:
*Documentation:* [[Encryption_in_manager_api_customer#How_to_use_the_API_-_examples|Manager API]]
* Migrating to different MySQL/MariaDB versions
* Upgrading VoIPmonitor versions during migration
* Moving from local MySQL to remote Percona


Example:
'''To identify schema changes manually:'''
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
echo 'listcalls' | nc localhost 5029
systemctl restart voipmonitor
tail -f /var/log/voipmonitor/voipmonitor.log | grep -E "CLI|ALTER|CREATE TABLE"
</syntaxhighlight>
</syntaxhighlight>


The manager API supports filtering by caller number, called number, IP addresses, and other criteria. See the [[Encryption_in_manager_api_customer#Example_with_filter_used|Manager API documentation]] for advanced filtering examples.
{{Warning|1=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.}}


=== Choosing the Right Method ===
== See Also ==


*Use the GUI <code>listActiveCalls</code> API when:*
* [[Mysql_master-master_replication_hints|Master-Master Replication]]
* You have multiple sensors/probes and need centralized access
* [[Backing_Up_GUI_Configuration|Backing Up GUI Configuration]]
* You want to query all connected sensors from a single endpoint
* [[Multiple_sniffer_instancies|Multiple Sniffer Instances]]
* You are building external integrations that need filtered results


*Use the sniffer manager API when:*
== AI Summary for RAG ==
* You need direct access to a specific sensor instance
* You are running scripts locally on the sensor host
* You require low-latency queries without GUI involvement


== 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.
'''Summary:''' Active Calls provides real-time monitoring of ongoing VoIP calls with live listening capability for G.711 codec. Calls are fetched via manager port 5029 and can be filtered by IP, number, sensor, or Call-ID. Column visibility can be customized and settings persist in the database. Programmatic access is available through two methods: the GUI's listActiveCalls API for centralized monitoring of multiple sensors, and the sniffer's manager API (listcalls command) for direct sensor access.


'''Keywords:''' active calls, real-time monitoring, live calls, manager port 5029, call filter, column visibility, custom_config, G.711 listening, listActiveCalls API, programmatic access, automation, manager API, listcalls command
'''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:'''
'''Key Questions:'''
* How do I view active/live calls in VoIPmonitor?
* How to migrate VoIPmonitor database to a new server?
* Why are active calls not showing in the GUI?
* What are the database_backup_from parameters for database migration?
* How do I filter calls by IP address or phone number?
* How to move old CDR records to another server?
* How do I hide or show columns in the Active Calls view?
* How to migrate PCAP files to a new server?
* What port is used for fetching live call data?
* What is the difference between database backup mode and master-master replication?
* How can I programmatically check if a call to a specific phone number is currently active?
* How to migrate GUI settings between servers?
* What is the difference between listActiveCalls API and the sniffer's manager API?
* How do I retrieve active calls from all connected sensors?
* How do I query active calls from a single sensor directly?

Latest revision as of 00:13, 11 February 2026


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

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?
Retrieved from "https://www.voipmonitor.org/doc/index.php?title=Redundant_database&oldid=11236"