When you execute SET SYNC MODE MAINTENANCE in a database, the database no longer updates sync history information and the next incremental refresh does not necessarily copy all changes from the master database to the replica database. Before you synchronize the master and replica databases, you must repeat the master database changes in the replica databases. You should also execute SET SYNC MODE MAINTENANCE in the replica database.
The requirement for applying changes in both master and replica databases is an important difference from the way that a solidDB synchronized system normally behaves. One of the major advantages of the Advanced Replication technology is that it allows a system to be self-healing in some situations; incorrect data on a replica database is usually replaced with data from the master database, and therefore errors on replica databases tend to disappear over time.
In maintenance mode, however, you lose this self-healing property. Since the master and replica database do not store sync history data, they do not know what changes were made, and the master database does not send all the updates to the replica database the next time that the replica refreshes.
There are two possible sources of error:
1 You might accidentally make a different change on the master database than on the replica database. For example, when you add a new column to a table, you might set the default value to 1 on the master database, but accidentally set it to 2 on the replica database.
2 Even if you perform the same operations without error on both the master and replica databases, certain types of errors might occur if the replica and master databases do not have the same starting values in the data.
For example, suppose that the master and replica databases each calculate sales tax on an invoice. If the master and replica databases have different values for the total price on the invoice, they calculate different sales tax, even if they use the same formula. This situation can often occur because master and replica databases are updated independently (asynchronously) during maintenance mode operations. The replica database is not necessarily in synchrony with the master database at the time that the replica database starts making updates.
When the databases are in maintenance mode, it is not safe to perform operations that rely on the replica and master databases being exactly in sync. For example, adding a new column does not affect existing data values. However, if you change the values of existing columns while in maintenance mode, those changes might not match. You should also avoid performing DML operations while in maintenance mode.
While a catalog sync mode is Maintenance, the following rules apply:
▪ The catalog does not send or receive synchronization messages and therefore will not engage in synchronization activities (for example, refresh or respond to a refresh request).
▪ DDL statements (for example, ALTER TABLE) are allowed on tables that are referenced by publications.
▪ When the sync mode changes, the server sends one of the following system events: SYNC_MAINTENANCEMODE_BEGIN or SYNC_MAINTENANCEMODE_END.
▪ If the master catalog publications are altered (dropped and re-created) by using the OR REPLACE option, then the publication metadata (internal publication definition data) is refreshed automatically to each replica the next time that the replica refreshes from the changed publication. (This is true whether or not the database was in Maintenance sync mode when the publication was replaced.)
▪ Each catalog has a read-only parameter named SYNC_MODE in the parameter bulletin board so that applications can check the catalog mode. Values for that parameter are either "MAINTENANCE" if the catalog is in maintenance sync mode or "NORMAL" if the catalog is not in maintenance sync mode. The value is NULL if the catalog is not a master or a replica database.
▪ A user can have more than one catalog in Maintenance sync mode at a time.
▪ If the session that set the mode ON disconnects, then the mode is set off.
▪ The normal synchronization history operations are disabled. For example, when a delete or update operation is done on a table that has synchronization history on, the synchronization history tables does not store the "original" rows (that is, the rows before they were deleted or updated). Note, however, that deletes and updates apply to the synchronization history table, for example:
DELETE * FROM T WHERE c = 5
will delete rows from the history table as well as from the base table. The following table shows how various operations (INSERT, DELETE, and so on) apply to the synchronization history tables in master and replica when sync mode is set to Maintenance.
Operation
Master
Replica
INSERT
Rows are inserted to base table.
Rows are inserted to base table and marked as official.
UPDATE
Both base table and history is updated.
Both base table and history is updated. Tentative/official status is not updated so tentative rows remains tentative and official rows remains official.
DELETE
Rows are deleted from base table and from history.
Rows are deleted from base table and from history.