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!
- Setting up Failover
- Clustering & High-Availability
- Disaster Recovery
- Data Recovery Options
- Cloud Hosting with IIS
- Cloud Hosting
- Hardware and Software Requirements
Pleasant Password Server incorporates an in-memory cache, so running more than one simultaneous instance against a database is not advised. Multiple installs can be configured to run against the same database, provided they're not running concurrently. Server backups, reconfiguring DNS, etc. are subject to your local policies and infrastructure.
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.
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.
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.