System information

our data is abstracted outside of Asterisk, we can use applications such as unison
(http://www.cis.upenn.edu/~bcpierce/unison/) or rsync to keep the configuration files
synchronized between the primary and the backup system. We could also use subver-
sion or git to track changes to the configuration files, making it easy to roll back changes
that don’t work out.
Of course, if our database goes away due to a failure of the hardware or the software,
our system will be unavailable unless it is programmed in such a way as to be able to
work without the database connection. This could be accomplished either through the
use of a local database that simply updates itself periodically from the primary database,
or through information programmed directly into the dialplan. In most cases the func-
tionality of the system in this mode will be simpler than when the database was avail-
able, but at least the system will not be entirely unusable.
A better solution would be to use a replicated database, which allows data written to
one database server to be written to another server at the same time. Asterisk can then
fail over to the other database automatically if the primary server becomes unavailable.
Figure 22-4. Asterisk database integration, single server
494 | Chapter 22: Clustering