Hopper does not autoload after switching to Slave database

[hashtagjet]

Hi,
Vicidial Install information
VERSION: 2.14-694a
BUILD: 181005-1738
Asterisk 11.25.1

Setup DB separate server
everything else on 1 server

So to begin with the issue, we recently migrated to another server. We switched to our slave database which is already on the new rack. We moved the dialer/web server onto the new rack but maintained it's IP. We pointed the Web application to the new DB server via editing VARDB_server on /etc/astguiclient.conf. After this, we rebooted both servers.

After loading, the web gui loaded fine, no errors, but the hopper was never filled with any leads.

Tried running ADMIN_update_server_ip.pl on the database server and updated the new IP. Seems to have ran fine with no errors. But the leads were still not going into the hopper. So we ran /usr/share/astguiclient/AST_VDhopper.pl --debug and then it loaded the hopper with leads. Problem is it doesn't auto load leads after that. After the leads were used up, it was never refilled.

I figured I can run the AST_VDhopper.pl script on a cron job, but not sure if it's a good idea so I came here to ask first.

When I run screen on web/dialer server I get this.

Code: Select all

There are screens on:
        1598.ASTfastlog (Detached)
        1596.ASTVDremote        (Detached)
        1594.ASTVDauto  (Detached)
        1591.ASTlisten  (Detached)
        1588.ASTsend    (Detached)
        1585.ASTupdate  (Detached)
        1426.asterisk   (Detached)
        1418.astshell20190216194936     (Detached)
8 Sockets in /var/run/screens/S-root.


The old DB server has this on screen -ls

Code: Select all

There are screens on:
        1643.ASTemail   (Detached)
        1641.ASTVDadFILL        (Detached)
        1639.ASTVDadapt (Detached)
3 Sockets in /var/run/screens/S-root.

the new/current DB server has nothing when I run screen -ls

Code: Select all

No Sockets found in /var/run/screens/S-root.

I'm assuming something is not running on the DB server. What can I do to fix this?

Sincerely,
Jet

[williamconley]

if you replaced a server and in so doing took a server offline, you need to check the "crontab -e" of the server you took offline and find what scripts were running at timed intervals and execute the same scripts on the new server.

Eg: If keepalive or hopper were running on the Old DB, they must also run on the New DB. Same with any Screens, it's likely that the new server should have the same screens running. And also check the /etc/astguiclient.conf file for any Other differences. Every setting is for ... something. If there's a difference, there's a reason and that reason may include a need for your new server to have an adjustment.

PS: It's a good idea to also include your Installer with Version.

[hashtagjet]

Thanks for the response. I'll make sure to add the installer next time. It's Vicibox-8.0.1.

I just remembered, when I installed the Dialer/Webapp, I specifically set it's a dialer and the DB is separate. I did the same with the database server. I believe when I installed the Slave, I specifically set up that it's a salve server. Would that be why it doesn't have the Jobs that was running on the slave DB? Is there a command to promote the slave server to Master?

[williamconley]

I specifically set up that it's a salve server. Would that be why it doesn't have the Jobs that was running on the slave DB?

Yep. The Slave DB is actually JUST a reporting server. Nothing else. It doesn't even need web (although you can use it as web, if you like, or any other role you installed).

Is there a command to promote the slave server to Master?

Nope. Because it's not a "slave", it's merely a report server that happens to have a full copy of the DB due to replication.

To make it master, you'd have to change it from a read-only replication server to read/write database server. Then you'd have to tell it and all the other servers that it's the DB server (in /etc/astguiclient.conf) and reboot everybody. New DB has to be UP before all the other servers, of course, since they need DB access during startup and forever after.