Multisite availability (MSA) can make the process of setting up a replication system both faster and easier.
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.
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.
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 Replication Server Administration Guide Volume 2 > Manage Warm Standby Applications for a complete discussion of this warm standby application.
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.
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 one of the following syntaxL
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.