Redundancy

See why customers enjoy using Pleasant Password Server with a KeePass client

Pleasant Password Server contains redundancy features and and is compatible with database and infrastructure systems that enable these types of features.

Have Questions? Contact Us!

Related Topics:

Licensing:

See Activating on a New Machine

Server Failover

Pleasant Password Server can be run with multiple instances on a database cluster. Multiple installs can be configured to run against the same database, concurrently or as a failover setup. Server backups, reconfiguring DNS, etc. are subject to your local policies and infrastructure.

Database Failover

Database Recovery Process

It's recommended that if a redundant database is used during an outage that it be promoted to primary, since re-merging of data is not a supported operation. Note that this affects selection of replication methods.

Replication Methods

Pleasant Password Server can be configured to use enterprise-level databases that themselves incorporate mirroring or replication. We recommend a Transactional replication method, something which PostgreSQL and Microsoft SQL Server support.

Due to the limitations mentioned above, Merge replication is not supported.

In the case of Snapshot replication, any changes made to the primary database since the last snapshot would be lost. Even if the database is recovered, merging the changes into the backup is not supported.

Activating or promoting a backup database is dependent on local policies and infrastructure.

Possible implementations:

Scenario 1: Redundant databases with manual failover

In this case, an IT administrator would be notified of a failure in the database used by Pleasant Password Server. They would disable the primary database and promote the backup database to primary. Then, they would log on to the machine where Pleasant Password Server was installed and use the Service Configuration Utility to select the secondary database as the one being used.

Restoring would involve disabling Pleasant Password Server, backing up the database from the secondary server, restoring it to the primary, and then re-enabling Pleasant Password Server.

Scenario 2: Redundant databases with automatic failover

In this scenario, a primary web server with Pleasant Password Server installed and running) points to the primary database, while a redundant web server (with Pleasant Password Server installed, but not running) is configured to point to a backup database. These would be behind a load-balancer which can signal a failure, in which case:

The primary database is disabled,
The primary web server is disabled,
The secondary database is promoted,
The secondary web server is activated, and
The load-balancer serves information from the secondary web server instead.

We don't recommend that systems are configured to automatically return to the primary system, as occurrence of data loss is probable due to lack of merge ability.