Failover and data recovery in Core database

Here you can find how you can prepare for disaster recovery with the Jive Core database.

Note: You may choose to configure redundant databases and replicate data between them. Jive does not provide database replication configuration or support. Your data center or DBA team, or both, must provide database support for you and your configuration. We have seen customers successfully deploy Oracle RAC and SQL server HA configurations with Jive.

Core database failover in single data center HA configuration

For details about a single data center HA configuration, refer to Configuring Core Application database for high-availability.

Core database failover in multiple data center HA configuration

Disaster Recovery (DR) architecture varies greatly from data center to data center. In a strategy where all systems are fully replicated to a DR facility, you may be able to architect the Jive Platform as you would with a single data center HA configuration. In many cases, however, the DR strategy is more manual and requires a multiple data center HA configuration. For more information, see Designing multiple data center HA configuration and Designing single data center HA configuration.

You may follow one of these possible DR strategies:

Create backup at a remote location (simplest DR strategy)

If a recent full backup of the database is available at a remote location, it is possible to recover the system to the point in time of the available backup. Upon declaration of a disaster, perform the following:

  1. Set up a new cluster of application servers and point them to a new empty database at the recovery facility.
  2. After completion of initial setup, save specific property values from the new database's jiveProperty table somewhere or copy them to a backup table. For more information on which properties need to persist, see Restoring database with persistent properties.
  3. Restore the database backup over the newly created database.
  4. Apply the properties that should persist (as determined in Step 2) from the new database to the restored database jiveProperty table. For more information, see Restoring database with persistent properties.
  5. Restart the application server.
Note: Data loss in the event of a disaster can be minimized by pushing incremental backups, and transaction write-ahead logs to the remote facility. Point-in-time recovery may be performed up to the point of the disaster if backups are available.

Use Cold/Warm state servers

Streaming replication, or Write-Ahead Logging (WAL), maintains a recent copy of the database at the remote facility. You need to make sure a cluster of application servers are already set up and attached to an empty database. Upon declaration of disaster, the replicated database should replace the empty database with specific values in jiveProperty persisted to reflect the DR environment. For more information, see Restoring database with persistent properties.

It is important to consider which properties should be replaced with values from the original production site, and which values should reflect values of the new facility. The persisted values depend on system configuration, as well as any customizations that could impact the jiveProperty table. Review, validation, and live testing of a system failover eliminates any potential issues that could arise during an actual disaster.