Setting up MySQL/MariaDB for VICIdial

VICIdial keeps almost everything in a database — leads, agents, call logs, campaign settings, live status. The dialer reads and writes to it constantly, so the database is not a side concern. Getting MySQL or MariaDB set up correctly is part of getting VICIdial to run at all. Here is what it actually needs.

The asterisk database

VICIdial stores its tables in a database named asterisk. That is the database the web interface, the dialing scripts, and the AGI (Asterisk Gateway Interface) scripts that run inside the Asterisk dialplan all talk to. Every lead list, disposition, and campaign config lives there. When people say a VICIdial box is healthy, a big part of what they mean is that this database is responsive and not falling behind on writes.

The cron and DB users

VICIdial connects to the database with its own user accounts rather than the database root. The cron user is the one the background scripts and Keepalive processes use to load the hopper, update agent status, and place calls on schedule. Those scripts run every minute and must reach the database reliably, so the user needs the right grants on the asterisk database. If the cron user's credentials or permissions are wrong, dialing quietly stops even though the web screens still load.

flowchart LR
  CRON[Cron scripts] --> DB[asterisk database]
  WEB[Web admin and agent screens] --> DB
  AGI[AGI scripts in dialplan] --> DB
  DB --> LIST[Lead lists and hopper]
  DB --> LOGS[Call logs and status]
  LOGS --> RPT[Real time and report views]

MyISAM tables

Most core VICIdial tables use the MyISAM storage engine rather than InnoDB. This is a deliberate choice for the write-heavy, high-churn tables the dialer hammers all day. One practical consequence worth knowing: MyISAM does not support transactional rollback, so a script that fails partway through can leave partial changes in place. Do not assume an operation is all-or-nothing on these tables. It matters when you are debugging a job that reported a failure but seems to have done half its work.

Tuning basics and where the DB lives

Tuning starts simple: give the database enough memory for its key buffers, keep slow queries out of the dialing path, and make sure the disk can keep up with the constant writes. The live screens and the Real-time report views read from the same database the dialer writes to, so a database that is starved for memory shows up as laggy real-time data first.

On a single-server install the database lives on the same box as everything else, which is fine for smaller teams. As you grow, the database is usually the first thing you move onto its own machine so the dialers can spend their CPU on calls. Wherever it lives, the dialing scripts and AGI (Asterisk Gateway Interface) scripts must be able to reach it with low latency, because a slow database makes the whole dialer feel slow.

This article is part of our complete guide to installing VICIdial. When the database outgrows the dialer box, see single-server vs clustered VICIdial for how the split works.

If standing up and tuning MySQL or MariaDB for VICIdial is not how you want to spend your week, VICIfast provisions a VICIdial server in under 40 seconds with the database created, secured, and tuned for you.