DB Server upgrade in cluster failed

[VFRDavid]

A few days ago, I replaced my DB server with a bigger box - went from 24 Core processor / 64GB RAM / 500GB Drive to 40 Core / 128GB / 12 TB...I had existing servers that were on an older SVN / schema, so I maintained those versions, at least initially, I planned on updating the SVNs to the latest version, or close to it, once the new DB server proved reliable...

Due to an issue with the CMOS / CD ROM driver, I couldn't use CD to install from the v7 ISO on the new box - I may have been able to use a bootable USB copy, but instead, I used the v8 ISO, which didn't have the issue. To keep the versions consistent across the cluster, I installed the same SVN (2973) and DB schema (1542). I moved the asterisk database to the new box, changed the old box's IP, changed the new box's IP to the old DB's IP (so no IP Update should have been required), and started it up - all servers registered with each other, test calls worked, but, when we went live, it was a mess...asterisk service crasing, MySQL extremely slow on queries that took a couple of seconds on the previous server, and more...so, last night, we moved the database back to the original box, flip-flopped the IP addresses between the old and new DB server again, rebooted, all looked good - but - again - major issues...when an Agent logged in, their phone rings (IAX or SIP), but when they answer, they do not get the "Only member" message and the call drops almost immediately. The solution seemed to be to re-pointed any agent phones I wanted to work to one of the other servers. All of these issues, make me think that - even though I used the same SVN/schema - maybe there were changes in the MySQL schema / values purely based on he ISO version I installed from? Or CONF file changes that were introduced by v8?

here is some other info about our system:
VERSION: 2.14-670a
BUILD: 180424-1521

I have been up for about 60 hours at this point, so - if I left anything out, or if it doesn't make any sense, please ask me and I will do my best to re-word/elaborate/etc as needed to include the information necessary to help me...

I have just about everyone working again - all extensions registered to a single server - but - if anyone could point me in the direction of what I should be researching - I really would appreciate it...David

[williamconley]

sounds like you were running asterisk on the DB server and your new vBox version had a more recent version of asterisk than your vDial version could handle, so crash and burn. Also sounds like when you tried to change back you had already made some changes that you did not change back, so ... crash and burn again until you could work through finding all the changes.

Advice: Upgrade in place (no hardware changes) to the latest version of Vicidial. Run it on the newer version of Vicidial for at least a day before you try again. Then when you do replace the DB server with a newer vBox version in a newer server ... there will be no compatibility problems since all versions of Vicidial are backwards compatible, but only more recent versions can handle the more recent Asterisk versions (which are installed with the more recent vBox .isos). Just remember that the "admin->Servers" entry for that server will require changes for the new asterisk version. Plus anything else in there that you can verify/alter ... verify ... and alter as needed.

In other words: Upgrade to the latest Vicidial so you can be compatible on all servers with all versions of Asterisk. Then when you upgrade any individual server, any version of asterisk will still work on that server. Thus needing to install with Vicibox 8 or 9 (which installs a more recent version of asterisk ...) won't be a problem.

Installing and then moving the DB means you brought the DB Schema with you. As long as you also installed the same Vicidial Version (with build, full match all the way) you should not have had any problems with "matching". Note that relying on SVN alone is not sufficient. You have to verify the Vicidial Version with Build on each machine (to be certain). Especially if you are familiar (and comfortable) with SVN, since this comes with the risk that your SVN has been messed with in some fashion (those afraid of SVN never seem to "svn up" randomly, whereas those who are familiar have been known to dabble ... and forget! lol)

Does the 40 core server have the same CPU speed as the 24 core server had? Or are the cores slower? That could account for slower.

If the 40 core server has the same speed, then what you *could* do is just move the DB to the 40 core server by changing the Database Server variable in all the Vicidial servers. You don't need to even enter it in the servers table. In fact, it doesn't need to have Vicidial installed at all. Just remember that the users in mysql have to be matched as well as bringing over the database. We have several clients who have dedicated DB servers with ZERO Vicidial code running on them. No scripts, no web pages, nothing. Just the DB on that server. Of course, you may want to bring along most/all of the my.cnf settings.