vicidial.org

Hi Guys,

Badly need your help.

This is what i did, we have 2 vicidial servers, oldvici and newvici.

oldvici's web and db is in one server, while newvici's webserv and dbserv is clustered both located on a different physical servers.

So oldvici's web and db has 1 IP which x.x.x.xxx, newvici's webserv's IP is x.x.x.151 and dbserv's IP is x.x.x.150.

I need to replicate all data from oldvici to the newvici, so I created an sql dump of oldvici's asterisk database and restored it to newvici's dbserver x.x.x.150.

However, things did not go as expected, though comparing the tables from both databases (old and new), all data is intact --its a complete replica, but there are locations in the newvici's interface does not reflect the data in it's database. e.g: vicidial_users, vicidial_campaigns, vicidial_lists, vicidial_campaign_statuses, etc.

The tables aren't empty, it's just doesn't propagate to the application's end as expected. (i can still login using the current users, changing the pw through the database, causes change on the application, but the information is not showing)

I hope im making any sense.

Please help.

THanks,

1) Welcome to the Party!

2) As you are obviously new here, I have some suggestions to help us all help you:

When you post, please post your entire configuration including (but not limited to) your installation method (7.X.X?) and vicidial version with build (VERSION: 2.X-XXXx ... BUILD: #####-####).

This IS a requirement for posting along with reading the stickies (at the top of each forum) and the manager's manual (available on EFLO.net, both free and paid versions)

You should also post: Asterisk version, telephony hardware (model number is helpful here), cluster information if you have one, and whether any other software is installed in the box. If your installation method is "manual/from scratch" you must post your operating system with version (and the .iso version from which you installed your original operating system) plus a link to the installation instructions you used. If your installation is "Hosted" list the site name of the host.

If this is a "Cloud" or "Virtual" server, please note the technology involved along with the version of that techology (ie: VMware Server Version 2.0.2). If it is not, merely stating the Motherboard model # and CPU would be helpful.

Similar to This:

Vicibox X.X from .iso | Vicidial X.X.X-XXX Build XXXXXX-XXXX | Asterisk X.X.X | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Intel DG35EC | Core2Quad Q6600

3) You must also match the precise version on the new server to the database (or upgrade the database you just moved to match the new server, take your pick but they must match!)

4) After the move of the database, the "admin update server ip" script must be run with the old/new server IPs. You can NOT just change it in the admin->servers record and hope for the best, that will fail. However: You can run that script at any time with those two IPs and it will catch all the entries you missed.

5) If the original was a single and the new is a cluster: You will lose all your clustering information during the transition. It's actually best at this point to perform a fresh install on the NONdb server(s) and get a clean install with Kumba's automated clustering technique (which is flawless IMHO).

6) If you take my advice: You'll actually perform a full upgrade to the latest code during this transition on all servers. In fact, if you perform a full, fresh installation on the DB server BEFORE moving the DB, then upgrade the DB and run the IP update script, you'll then be able to run the cluster script on a completely up to date system.

7) There are entries that are NOT modified by the IP update script:
* Audio Store folder likely doesn't exist. Change the folder name in the system settings table to match the new server, or change the folder name on the HD to match the value in system settings.
* Probably a good idea to copy the audio files from the old audio store while you're at it.
* Admin->System Settings has choices for VM server and possibly a couple others that should be set since the IP of the server changed
* Admin->Servers has some settings that are IP related as well
* You may or may not want to copy all your previous recording files. If you do, you may need to run the recording archive URL correction script to fix their values in the recording log so the links will work on the new server.