Real-Time Backup Deployment Models

A Look at Alternative Deployment Models for Real-Time Backup

DataExchange provides different deployment methods for Real-Time Backup replication. This chapter discusses the deployment methods available for the most common network configurations and provides you with information in addition to the deployment method between two machines discussed in Getting Started with Pervasive DataExchange Real-Time Backup Edition. This chapter also discusses disaster recovery procedures in the event you need to restore a replicated database. The sections in this chapter include the following:

Real-Time Backup Configurations

Replication Deployment using the Deployment Wizard

Replication Deployment using DXDeploy

Many-to-One Deployment using DXDeploy

Disaster Recovery

Real-Time Backup Configurations

DataExchange offers three options for Real-Time Backup deployment. An interactive deployment method uses the Deployment Wizard, which automates the entire deployment process and enables creating a replication schedule. Another deployment method uses the DXDeploy utility, which automates several of the processes necessary for replication. Before you consider what deployment option to use, you should first consider how you will want to configure Real-Time Backup.

Two-Machine Configuration

The most common configuration for Real-Time Backup replicates data between two machines in real-time from a Pervasive PSQL database to a standby server. Upon a system failure, clients can be directed to the up-to-date standby server. Operating at the database level, DataExchange captures database changes on the primary server and applies them to the backup server.

This type of configuration allows DataExchange to avoid errors common to disk-based replication tools, like replicating corrupt data, spreading viruses, or deleting desired user data. With Pervasive DataExchange powering a standby server, data loss, and down time is greatly lessened in the event of system failures, hardware failures, or site disasters.

The following figure illustrates a one-way replication backup network using two machines.

Figure 4-1 Real-Time Backup with Two Machines

In this scenario, you have one server, Server A, networked with your backup server. The server runs its own database, dbA. DataExchange then maintains a copy of the database on the standby backup server and replicates with the server at the backup location when changes are applied.

See Replication Deployment using the Deployment Wizard for information on starting the DataExchange Deployment Wizard.

Refer to Chapter 4, Replication Deployment,in your Getting Started with Pervasive DataExchange Real-Time Backup Edition manual for instructions on implementing Real-Time Backup on a two machine configuration using DXDeploy.

Many-to-One Configuration

The other configuration commonly used with Real-Time Backup consists of several database servers at different locations that replicate data to a backup standby server hosting multiple backup databases. This is referred to as a many-to-one configuration. The following provides an illustration of this type of configuration.

Figure 4-2 Real-Time Backup with Many-to-One Configuration

In this scenario, you have three servers, Server A, Server B, and Server C. Each machine is networked with your backup server. Each server runs its own database, dbA, dbB, and dbC, respectively. DataExchange then maintains individual copies of each database to the standby backup server and replicates with the server at the backup location when changes are applied.

Refer to Many-to-One Deployment using DXDeploy, for instructions on implementing Real-Time Backup on a many-to-one configuration using DXDeploy.

Note Currently DataExchange only supports implementing Real-Time Backup on a many-to-one configuration using DXDeploy.

Replication Deployment using the Deployment Wizard

Real-Time Backup deployment can be implemented using the DataExchange Deployment Wizard. The Deployment Wizard is a step-by-step wizard for deploying replication at First and Partner Sites and includes a means of creating a replication schedule. The Deployment Wizard provides automation of the procedures for the DataExchange command-line utility dxdeploy.exe.

Access the Deployment Wizard from Pervasive Control Center by selecting DataExchange then Deployment Wizard or by selecting Deployment Wizard from the operating system Start menu or Start screen.

Before You Get Started

Before you start the DataExchange Deployment Wizard, we recommend that you review the following deployment attributes. It is a good idea to make note of these items for the database you are deploying, as they are needed to complete the Deployment Wizard.

Project Name – this corresponds to a specific database. If your goal is to replicate a database named mydatabase, then you may want to call the project mydatabase project or something similar.

Network Name – this refers to the name you have chosen to represent the grouping of replication sites that participate in replication.

Release Name – this is similar to a version number for the design of the replication database.

DSN – this specifies the data source name (DSN) to be associated with the data files deployed for replication. The DSN must be unique on each site.

Directories and file names of data – this specifies the directories and data files to be included in the replication.

For detailed information about these attributes, see XML Attributes in Deployment Descriptor File in Getting Started with Pervasive DataExchange.

Replication Deployment using DXDeploy

Simple replication deployment between two machines is the standard use case for Real-Time Backup. This scenario involves a primary server and a backup server, as shown in Figure 4-1.

For detailed instructions on deploying a Real-Time Backup solution using DXDeploy, refer to Chapter 4, Replication Deployment,in the Getting Started with Pervasive DataExchange Real-Time Backup Edition.

Many-to-One Deployment using DXDeploy

In a many-to-one configuration, multiple sites back up data to a single site. A good choice for a First Site in such a configuration is often the backup location. Consider the following example scenario:

Figure 4-3 Multiple Sites Backing Up Data

Three servers, A, B, and C, each has its own network. Each server runs its own database, dbA, dbB, and dbC, respectively. You want to implement a solution in which a replicated copy of each database is maintained on one backup machine.

Given this scenario, the most reasonable choice for the First Site is the backup location. Why? Part of the reason is that a replication network can have only one First Site. In addition, the backup location meets the following criteria:

Contains network connectivity to the Partner Site(s).

Provides the physical storage for the entire set of data.

Lends itself as the location from which the least amount of file copying is required. Replication design requires that some files are copied to the Partner Site(s).

The following image shows the same configuration after you install DataExchange. Note that the Partner Sites are the sources of the data and the First Site is the backup location.

Figure 4-4 Many-to-One Configuration with DataExchange Installed

Note In the reverse of a many-to-one configuration, one First Site source replicates to two or more Partner Site backups. This configuration is deployed as a two-way replication.

Before You Get Started

Before performing this task you must install Pervasive DataExchange on a First Site and a Partner Site as explained in Getting Started with Pervasive DataExchange.

Tip So that you can restore your databases to their original state after this exercise, we recommend saving a copy of the Demodata database files before proceeding with this example.

For discussion purposes, this task assumes the following:

You have read the chapter Replication Deployment in Getting Started with Pervasive DataExchange Real-Time Backup Edition.

You have three Partner Sites whose names are ServerA, ServerB, and ServerC, as illustrated in Figure 4-3.

Demodata is the application database on all three Partner Sites.

Caution All applications using the database must be shut down before using this deployment method.

Deploying Using DXDeploy

To deploy databases in a many-to-one configuration

 

1	Ensure that the database you want to enable for replication is not being accessed by your application.

For example, suppose that Demodata is the database used by Myapp.exe. Ensure that Myapp is not accessing Demodata while you perform the steps to deploy Demodata.

2	On the backup (first) site, open the XML descriptor file EXPRESS.XML in a text editor. The file is located in the \<Installation Directory >\Replication\Docs directory.

3	Edit the XML descriptor file, specifying the appropriate information for ServerA and the backup (first) site.

Note that you will edit, and use, a different descriptor file for each Partner Site. Because the backup (first) site is a shared location, some information in the descriptor file must be unique each time that you use the file. The following table explains this.

XML Descriptor File Attribute	Must Be Unique for Each Partner Site	Notes
Project	Yes
Network	Yes
Release	No
First ServerName	No	This is the name of the backup (first) site, which is common to each Partner Site.
First Site DSN	Yes	The DSN must also be unique for the backup (first) site.
First Site DataDirectory	Yes	This is the backup location on the backup (first) site specific to each Partner Site
Relative Include Path	No	You could, for example, include “*.mkd” files from each Partner Site.
Absolute Include Path	Yes	Absolute paths must not conflict on the backup (first) site. For example, suppose that ServerA, ServerB, and ServerC each use the same absolute data path, C:\mydata\table1.mkd. That path can exist only once on the backup (first) site. This would result in a conflict because the table1.mkd file from the different Partner Sites would get overwritten on the backup (first) site.
Partner ServerName	Yes
Partner DSN	No	Each partner may use the same DSN if you want, provided the DSN is unique on that Partner Site.
Partner DataDirectory	No	The backup location on the backup (first) site does not have to be the same as the location of the data on the Partner Site.

4	Save EXPRESS.XML as ServerA.xml to a location of your choice. This task assumes that you save it to C:\.

5	Copy the Demodata directory from ServerA to the desired backup folder on the backup (first) site.

The backup location must be unique and must match the location specified for First Site DataDirectory in the XML descriptor file. This task assumes that the backup location is C:\Demodata_Backup_ServerA.

6	On the backup (First) site, open a command prompt and type the following:

DXDeploy /Site=First C:\ServerA.xml

The command is case-insensitive.

7	Press Enter.

DXDeploy provides high-level status messages on the screen as it completes its actions. DXDeploy is complete when the command prompt reappears.

8	After DXDeploy completes, type the following:

DXdeact <First Site DSN>

The command is case-insensitive.

<First Site DSN> is the DSN you specified in ServerA.xml for the First Site.

9	Press Enter.

10	Copy the contents of the DataExchange directory from C:\Demodata_Backup_ServerA on the backup (first) site to the Demodata directory on ServerA.

Note For a many-to-one configuration, ignore the replication template created on the backup (First) site. Instead, use the files for the activated database, which are located in the DataExchange directory.

11	Copy ServerA.xml from the backup (first) site to ServerA.

12	At a command prompt on the backup (first) site, type the following:

DXact /FIRSTSITE <First Site DSN>

The command is case-insensitive.

<First Site DSN> is the DSN you specified in ServerA.xml for the First Site.

13	Press Enter.

14	On ServerA, open a command prompt and type the following:

DXDeploy /Site=Partner C:\ServerA.xml

The command is case-insensitive.

15	Press Enter.

DXDeploy provides high-level status messages on the screen as it completes its actions. DXDeploy is complete when the command prompt reappears.

16	On ServerA, set up a replication schedule.

See Managing Replication Schedules for how to set up a replication schedule.

17	Bring your application back online.

18	Repeat steps 1 through 17 for each of the other Partner Sites.

Substitute “ServerB” for “ServerA” when repeating the steps for ServerB. Substitute “ServerC” for “ServerA” when repeating the steps for ServerC.

Disaster Recovery

This section explains how to recover from the failure of one replication site. The information assumes that the disaster occurs to your primary site, requiring that you temporarily switch production to your backup site. After a primary site is again provided, you then need to reestablish the primary site/backup site replication network.

A disaster could, of course, occur to the backup site. The information still applies; just substitute backup for primary. For ease of discussion, and to remain consistent with terminology commonly used to discuss disaster recovery, this section refers to primary site and backup site. Think of them as the First Site and Partner Site, respectively.

The information in this section applies only to a real-time backup situation or to a 1-way situation. See the chapter Deployment Process in Getting Started with Pervasive DataExchange Real-Time Backup Edition for an explanation of real-time backup deployment. See DataExchange Implementation Options for an explanation of 1-way deployment.

Failover

In the event of a disaster, you must switch your users to access the backup site. Use whatever methods are in place at your company to accomplish switching to a different server. Such methods are many and varied and beyond the scope of this document.

Since the backup site contains current data, your application(s) should continue to function as before.

Once your users are accessing the backup site, reestablish your First Site. Two disaster scenarios exist pertaining to the data on the primary site:

The primary site is catastrophically destroyed and no data can be recovered from it.

The primary is brought back into service and its data is still available, but no longer current.

No Data Recoverable

Use the following steps to reestablish your primary site.

To set up a new primary site

1	Install the Pervasive PSQL database product on the new machine.

Refer to the Getting Started guides for the product edition.

2	Install Pervasive DataExchange on the new machine.

If the machine was a First Site before, install a First Site setup. If it was a Partner Site, install the Partner Site setup. Refer to the Getting Started guides for the product edition (Real-Time Backup or Data Synchronization).

3	Install your application(s) on the new machine.

This creates a fresh copy of your application database on the new machine.

4	Create the same data source name (DSN) on the primary as used for the replication database on the backup.

5	Take your application(s) offline on the backup site.

You must ensure that the database is not being accessed until you get the primary and backup sites synchronized.

6	Deactivate the replication database on the backup sites.

See dxdeact.

7	From the backup machine, copy the following to the same locations on the primary machine:

All user database tables.

All data dictionary (DDF) files.

All replication control tables. Tables with “PDC” as the first three characters added to the name of your data tables.

All replication system tables. See Table 4-1.

8	Activate the replication database on the primary site.

See dxact.

9	Activate the replication database on the backup site.

See dxact. Note that the activation on the backup site performs an initial replication with the primary site. An initial replication is a full replication, in which all data is synchronized between the two machines.

The primary site and backup site now contain the same data.

10	Recreate any replication schedules from the primary site to the backup site.

See Schedule Tasks.

11	Switch your users to access the primary site and bring your application(s) back online.

 

Table 4-1

Replication System Tables

DACTHIST.MKD	DACTSITE.MKD	DACTTBL.MKD
DCMD.MKD	DCMDSITE.MKD	DCNF.MKD
DFKEY.MKD	DFRAGF.MKD	DFRAGI.MKD
DGRP.MKD	DIDB.MKD	DIDBDEF.MKD
DKEY.MKD	DLANG.MKD	DMSG.MKD
DMSGLANG.MKD	DPKEY.MKD	DPRM.MKD
DPRMGRP.MKD	DPRMTYP.MKD	DQUEUE.MKD
DSCHED.MKD	DSCHEMA.MKD	DSET.MKD
DSFSITE.MKD	DSITE.MKD	DSITEEXT.MKD
DSITELNK.MKD	DSITESET.MKD	DSORT.MKD
DTBLCHG.MKD	DTRN.MKD	DUSR.MKD
DUSRGRP.MKD	DUSRPRF.MKD	DVER.MKD
DWSTS.MKD

Data Recoverable But Not Current

Use the following steps to reestablish your primary site.

To place an existing primary site back into replication

1	Bring the primary machine back online.

2	Take your application(s) offline.

You must ensure that the database is not being accessed until you get the primary and backup sites synchronized.

3	Delete all replication schedules on the primary site.

See Schedule Tasks.

4	Deactivate the replication database on both the primary and the backup sites.

See dxdeact.

5	Activate the replication database on the primary site.

See dxact.

6	Activate the replication database on the backup site.

See dxact. Note that the activation on the backup site performs an initial replication with the primary site. An initial replication is a full replication, in which all data is synchronized between the two machines.

The primary site and backup site now contain the same data.

7	Recreate any replication schedules from the primary site to the backup site.

See Schedule Tasks.

8	Bring your application(s) back online.