Overview

MSA can make the process of setting up a replication system both faster and easier.

Some of the features that MSA provides are:

A simple replication methodology that requires only one replication definition for the primary database and only one subscription for each subscribing database.
A replication filtering strategy that lets you choose whether or not to replicate individual tables, transactions, functions, system stored procedures, and data definition language (DDL).
Replication of DDL to any replicate database—including non–warm standby databases.
Replication to multiple replicate sites—for warm standby as well as non–warm standby databases.

You can overlay MSA scenarios over your existing replication structure. The procedures for implementing MSA are similar to those you use to replicate to warm standby or replicate databases.

Database replication

When you use table and function replication, you describe each piece of data that is to be replicated using individual table and function replication definitions and subscriptions. This methodology allows you to transform data and provides fine-grained control over the information being entered in the replicate database. However, it requires that you mark each table or function to be replicated, create a replication definition for each replicated table or function, and create subscriptions for each replication definition at each replicate database.

MSA lets you identify specific database objects: tables, functions, transactions, DDL, and system stored procedures in a single replication definition. You can choose to replicate the entire database, or you can choose to replicate—or not replicate—particular tables, functions, transactions, DDL, and system stored procedures in that database. If you do not need to replicate partial tables, MSA can provide replication while affording the advantages of simple setup and maintenance.

When the replicate is a warm standby database

In the non-MSA warm standby scenario, changes to the primary database are copied directly to the warm standby database without alteration. This methodology allows replication of DDL. To change or qualify the data sent, you must add table and function replication definitions. Each primary database can have one, and only one, standby database. See Chapter 3, “Managing Warm Standby Applications,” in the Replication Server Administration Guide Volume 2 for a complete discussion of this warm standby application.

MSA provides all the features of the warm standby application described in Chapter 3, “Managing Warm Standby Applications,” in the Replication Server Administration Guide Volume 2. In addition, MSA:

Enables replication to multiple standby databases
Allows you to replicate or not replicate specific database objects

Bidirectional replication support for DDL in MSA

You can configure multisite availability (MSA) to set up a two-way replication of DDL transactions between two Adaptive Server databases.

Replication Server 15.0 and later supports this bidirectional replication using a Replication Server configuration parameter called dsi_replication_ddl. When dsi_replication_ddl is set to on, DSI sends set replication off to the replicate database, which instructs it to mark the succeeding DDL transactions available in the system log not to be replicated. Therefore, these DDL transactions are not replicated back to the original database, which enables DDL transactions replication in bidirectional MSA replication environment.

To set up bidirectional replication:

Create a bidirectional MSA replication environment. See “Creating a bidirectional replication environment”.
Grant “set session authorization” privilege to the maintenance user on the destination database, as shown in the following example:
```
grant set session authorization to maint_user
```
Alter the connection of the destination database to set dsi_replication_ddl configuration parameter to “on” to enable bidirectional DDL replication, as shown in the following example:
```
alter connection to dataserver.database set dsi_replication_ddl on
```
Replicate DDL transactions.

MSA mixed-version environment

In an MSA mixed-environment, the primary Replication Server filters the data features with higher versions.

Incompatible commands are not sent to the standby Replication Server. The configuration parameter dist_stop_unsupported_cmd suspends the DIST if there are incompatible commands. You can configure this parameter using the following syntax:

configure replication server 
  set ‘dist_stop_unsupported_cmd’ to [‘on’ | ‘off’] alter connection srv.db 
  set ‘dist_stop_unsupported_cmd’ to [‘on’ | ‘off’] alter logical connection lsrv.ldb 
  set ‘dist_stop_unsupported_cmd’ to [‘on’ | ‘off’]

By default, dist_stop_unsupported_cmd is off. When the parameter is on, the DIST suspends itself if a command cannot be sent to some destinations. Resume DIST by skipping the entire transaction, or reset the parameter to off.

To create a database subscription from a primary Replication Server with version 15.0, the replicate Replication Server must be version 15.0 or later.