Database Slave replication

All installation and configuration problems and questions

Moderators: gerski, enjay, williamconley, Op3r, Staydog, gardo, mflorell, MJCoate, mcargile, Kumba, Michael_N

Database Slave replication

Postby donX » Thu Mar 09, 2017 8:19 am

Hi Guys,

Is it possible to configure vicidial in redundancy mode?

Here's what I'm planning, have 4 servers, 2 for application and 2 for DB. 1 DB server is the master where all transactions from both app server is stored, the 2nd DB server serves as a fail-over with DB1 goes down where both app server points to that DB automatically.

The problem is.

1. when installing vici, it doesn't ask for a slave database for this purpose
2. replicating master to slave will either be done through manual scheduled scripting
3. how to configure vici to point to slave db when db1 is down.

Thanks,
donX
 
Posts: 50
Joined: Tue May 17, 2016 8:38 am

Re: Database Slave replication

Postby williamconley » Thu Mar 09, 2017 1:57 pm

1) Welcome to the Party! 8-)

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) This depends a great deal on your system's intensity. A heavily used mysql DB does not like replication, as it locks tables and takes up valuable CPU cycles and also requires disk writes that can be heavy. Consider exploring other methods if your system is heavy use, or at least be on standby to turn off replication if it begins to overload your system (happens!). Note that replication overloads can be difficult to detect as this is not a logged event and replication status is not something that can be easily viewed "in progress". I've found systems that flat-out claimed to not be replicating right now but were overloading and the mysql replication folder had files that were increasing in size rapidly. Obviously replication was in progress, but mysql claimed it wasn't. Awkward. Also: If replication fails and the system auto-initiates "re-sync" of tables, your Vicidial DB server will be useless until it has been completed. Once again, awkward.

4) Consider alternate methods, such as log shipping and a script at the backup server to auto-restore each log as it arrives (at timed intervals of course).

5) "Vicidial" isn't a single thing that can be configured to use a different DB server. There are active scripts that expect their connection to the DB server to stay live. It may actually be easier to build a script that causes the "dead/dying" server's local IP to change and the "coming online" server to take over its local IP address. Connections will break, which is inevitable, but new ones will be made and the system will go back online quickly. However: None of this is built AFAIK because it is cost-prohibitive. It's generally better to make your DB server "bullet-proof" and seriously backed up. Alternately, of course, a script could be built to kill all running scripts after changing the DB server value in the appropriate file. Once again, noone has built this as it is not cheap to build or test. This will still be disruptive, but will resolve itself quickly (within a minute or so) if done properly. It would of course have to run on ALL the servers (including the DB server, which may need to be told to shut up in some fashion).
Vicidial Installation and Repair, plus Hosting and Colocation
Newest Product: Vicidial Agent Only Beep - Beta
http://www.PoundTeam.com # 352-269-0000 # +44(203) 769-2294
williamconley
 
Posts: 20258
Joined: Wed Oct 31, 2007 4:17 pm
Location: Davenport, FL (By Disney!)


Return to Support

Who is online

Users browsing this forum: Google [Bot] and 81 guests