Real-Time Backup Deployment Models
Deployment Models for Real-Time Backup
The following topics discuss deployment methods for Real-Time Backup replication, as well as disaster recovery steps in the event you need to restore a replicated database:
Real-Time Backup Configurations
This topic presents two types of configuration of DataExchange Real-Time Backup.
The first one is by far the most commonly used.
Two-Machine Configuration
In its two-machine configuration, Real-Time Backup replicates data in real-time from a Zen database to a standby server. Upon a system failure, clients can be directed to the standby server. This type of configuration allows DataExchange to avoid errors common to disk-based replication tools, such as replicating corrupt data, spreading viruses, or deleting desired data. With DataExchange powering a standby server, data loss and down time are greatly lessened in the event of system failures, hardware failures, or site disasters.
The following figure illustrates this 1-way replication backup.
Figure 1 Real-Time Backup with Two Machines
In this scenario, Server A is networked with a backup server. The server runs its own database, dbA. DataExchange maintains a copy of the dbA database on the standby backup server and replicates with the Server A when changes occur there.
Simple, 1-way 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 1.
Many-to-One Configuration
The other configuration 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 diagram illustrates this configuration.
Figure 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 maintains a copy of each database on the standby backup server and replicates changes on Server A, Server B, and Server C to their backup copies.
See Many-to-One Deployment Using DXdeploy for instructions on implementing Real-Time Backup on a many-to-one configuration using DXdeploy.
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 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 each Partner Site.
•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 each Partner Site.
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 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.
Before You Get Started
Before performing this task you must install DataExchange on a First Site and a Partner Site.
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 Replication Deployment.
•You have three Partner Sites named ServerA, ServerB, and ServerC, as illustrated in Figure 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. On a 64-bit system this file is found in C:\Program Files (x86)\Actian\Zen\Replication\Docs.
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 example assumes 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 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 enter the following:
dxdeploy /Site=First C:\ServerA.xml
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 finishes, enter the following:
dxdeact <First Site DSN>
<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, enter the following:
dxact /FIRSTSITE <First Site DSN>
<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 enter the following:
dxdeploy /Site=Partner C:\ServerA.xml
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.
Substitute ServerB for ServerA when repeating the steps for ServerB. Substitute ServerC for ServerA when repeating the steps for ServerC.
Disaster Recovery
This topic 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 topic refers to primary site and backup site. Think of them as the First Site and Partner Site, respectively.
The information here applies only to a real-time backup situation or to a 1-way situation. See Deployment Process for an explanation of real-time backup deployment. See 1-Way Deployment Using DXdeploy for a working example 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 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 Zen database product on the new machine.
2 Install DataExchange on the new machine.
If the system was a First Site before, install a First Site. If it was a Partner Site, install the Partner Site.
3 Install any previously installed applications on the new system.
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 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 site.
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 files (DDFs).
•All replication control tables, which have the name of each data table with the prefix PDC. Their default location is C:\ProgramData\Actian\Zen\<database name>\DX_<project name>.
•All replication system tables shown in the following list. Their default location is C:\ProgramData\Actian\Zen]Replication\Data.
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 |
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 back online.
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 offline.
Be sure that the database is not 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. This is a full replication, in which all data is synchronized between the two systems.
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 back online.