In some cases, this simple configuration may be
suitable especially if the system meets the customer's availability
requirements and represents an appropriate balance of risk and benefits.
As we mentioned earlier, availability design must be driven from a
business perspective.
In practice, we rarely see such systems used in
production. Instead, the system above is generally used for development,
proof-of-concepts, or demonstrations.
If you want to use a similar system in production,
consider the following:
- The ability to recover the database. At a minimum,
backup the system and database regularly. Also backup your database
transaction logs to allow rollforward recovery from the database backups.
- The backup tapes and archived database transaction
logs should be stored off-site. This prevents a data center disaster,
such as fire, from destroying not only the database server node but
also all the backup tapes.
Even with these considerations, this configuration
has the following issues:
- Loss
of transactions – if you lose the database server and you have to
restore the database to a different server, you will lose recent transactions.
After a database restore, you have to rollforward or replay all the
transactions found in the transaction logs created after that database
backup. Typically, the most current active transaction log, in simple
configurations, are only saved when the log closes. If you lose the
log, you have lost all the recent transactions captured in that log
after the database restore.
- Loss of transactions in the integration
queues – if you lose the disk on which integration queues are kept,
you will lose all the unprocessed transactions in those queues.