Redundant database

This guide explains how to use a dedicated VoIPmonitor sensor instance to perform real-time replication of the CDR database to a secondary MySQL/MariaDB server. This provides a native, application-level method for creating backups or read-only replicas.

Overview & Use Case

VoIPmonitor offers a built-in mechanism to replicate its database. This is achieved by running a special instance of the sensor in "database backup mode." In this mode, the sensor does not sniff any packets; its sole purpose is to connect to a primary (source) database, read CDR data, and write it to a secondary (destination) database.

This method is an alternative to traditional MySQL replication and is particularly useful for:

• Creating a read-only replica database for reporting or analysis without impacting the performance of the primary database.
• Setting up a hot-standby database for disaster recovery.
• Consolidating data from multiple, smaller VoIPmonitor databases into one central database.

The process incrementally syncs data starting from a specified date, ensuring that the destination database stays up-to-date in near real-time.

Configuration

To set up database replication, you will run a new, dedicated VoIPmonitor sensor instance on the server that hosts your secondary (destination) database. This instance requires its own `voipmonitor.conf` file.

Below is a complete example configuration file for a replication instance.

Example `voipmonitor.conf` for Replication

Create a new configuration file, for example at `/etc/voipmonitor-backup.conf`:

# /etc/voipmonitor-backup.conf

[general]

# --- Destination Database (where to write data) ---
# This instance connects to the local database where data will be replicated.
mysqlhost                      = 127.0.0.1
mysqldb                        = voipmonitor_replica  # It is wise to use a different DB name
mysqlusername                  = root
mysqlpassword                  = your_destination_db_password
cdr_partition                  = yes  # Ensure partitioning is enabled on the destination

# --- Source Database (where to read data from) ---
# These parameters tell the sensor which primary database to replicate.
database_backup_from_mysqlhost   = 192.168.0.1  # IP of the PRIMARY database server
database_backup_from_mysqldb     = voipmonitor    # Name of the source database
database_backup_from_mysqlusername = root
database_backup_from_mysqlpassword = your_source_db_password

# --- Replication Control ---
# The date from which the replication should begin. The sensor will replicate all
# data from this date forward.
database_backup_from_date        = 2024-01-01

# The number of parallel threads to use for inserting data into the destination database.
# Increase this value for higher throughput.
database_backup_insert_threads   = 3

# The pause in seconds between each batch of replicated data.
database_backup_pause            = 3

Running the Replication Instance

Once your configuration file is ready, you can start the sensor in this special mode.

1. Manual Test Run

It is highly recommended to first run the process manually to ensure all settings are correct and there are no connection errors.

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

• -k: Prevents the process from forking into the background.
• -v 1: Sets verbosity to level 1, which will show status information.
• Watch the output for any database connection errors or other warnings.

2. Running as a Service

To run the replication instance permanently as a background service, you will need to create a separate `systemd` or `init.d` service file for it. This process is covered in the Multiple Sniffer Instances guide. The key is to ensure the new service unit file uses the -c /etc/voipmonitor-backup.conf argument to load your specific configuration.

AI Summary for RAG

Summary: This article describes how to use a dedicated VoIPmonitor sensor instance to perform application-level replication of its MySQL/MariaDB database. It explains that this feature is an alternative to standard database replication, useful for creating read-only replicas or hot-standby backups. The guide provides a detailed example of a `voipmonitor.conf` file configured for this "database backup mode." It highlights the key parameters, distinguishing between the destination database connection settings (`mysqlhost`, etc.) and the source database settings (`database_backup_from_mysqlhost`, etc.). It explains the function of `database_backup_from_date` to control the starting point of the sync, and `database_backup_insert_threads` for performance tuning. Finally, it provides command-line instructions for running the replication instance, recommending a manual test run before setting it up as a permanent service. Keywords: database replication, backup, mysql backup, mariadb replication, replica, read-only, standby, disaster recovery, database_backup_from_date, database_backup_from_mysqlhost, voipmonitor.conf, high availability Key Questions:

• How can I create a real-time backup of my VoIPmonitor database?
• How do I replicate the VoIPmonitor database to another server?
• What is the "database backup mode" for the sniffer?
• What configuration is needed to mirror the VoIPmonitor database?
• Can I use VoIPmonitor to create a read-only replica of my database for reporting?
• How does the `database_backup_from_date` parameter work?