vicidial.org

We have a small Vicibox install"

Vicibox 10
VERSION: 2.14-853a
BUILD: 220328-1420

1 database server
1 web server
2 asterisk servers currently (it will grow to more)
(all of the above servers were installed using the Vicibox 10 ISO)

Our DBA is asking if we could move the database to a server in Azure. Obviously that server can't be installed from scratch using the Vicibox ISO image.
So my question is whether it's possible to move just the database and link the web server and asterisk servers to it. I have no idea at this point where the connection to MariaDB is configured on the web server and the asterisk servers.

1) Thank you for posting your Vicidial Version (with build).

2) Please post your entire Installer version in the future (10.X.X rather than "10").

3) You can not "move" your Vicidial database to a cloud service. More on that later.

4) You can REPLICATE your Vicidial database anywhere you want to make that data available for other processes.

Vicidial Clustering and Database:

The DB server must be available on the local network with virtually no lag. Every second a Vicidial cluster generates THOUSANDS of DB requests and makes decisions on the result of those requests. Any delay (ANY delay) will cause instability and poor decisions. Crash and Burn poor decisions. Compare to using an engine that's not actually IN the car ...

Also, the Vicidial DB's response time (especially on a clustered system) is crucial to the functionality of the system. A virtualized / Cloud-Based / Distributed Database is marvelous for online catalogs and websites where an extra fraction of a second delay (all the time) and an occasional several second response is not a problem. In vicidial, response time is measured in nanoseconds, not seconds. Vicidial isn't about supporting the Admin Web Pages so you can create settings. The Admin web pages are about creating DB entries to control the Dialers, which run perl scripts that utilize hi-res perl timing (that's the nanosecond timer for perl scripting). One perl script on a dialer will observe that an outbound call has been answered, it will then mark the call answered, mark the call "being handled", look for an available agent based on the campaign settings (which it must, of course, request and receive based on the identity of that call), then send a signal to the DB's call_manager to store a value that tells the Dialer upon which the call resides what to do with the call. That dialer (which may or may not be the one running the original "i have an answered call!" script running) must then transfer the call according to those instructions, by hammering the call_manager script at all times to see if there's anything to do. Then it transfers the call and updates the DB so the agent screen can be updated simultaneously with the call arriving in the conference without lag. All of this has about one second to occur to avoid audio-lag since your Dialer called someone and the last thing you want is for them to listen to several seconds of silence while a remote database decides what to do.

here you go mate:

https://dialer one/how-to-backup-and-restore-your-vicidial-cyburdial-server/?amp