|
|
|
The behavior of the Replicator Server is controlled by configuration options, or flags. These flags are contained in the configuration file for each server. Each server can have customized behavior based on the flags set.
When a server is started, it reads its configuration file to set its parameters. The server only reads its configuration file during startup, so although you can edit the file, the changes do not take effect until the server is stopped and restarted. You can, however, send commands to a running server to alter its behavior.
For instructions on sending commands to a running server, see Database Events. For more information on server parameters, see Server Parameters.
|
|
|
For effective monitoring, you can configure your servers in the following ways:
|
|
|
Through electronic mail, servers can provide notice to the DBA or other users of any errors as they occur. The level of message logging is dependent on the Log Level flag (-LGLn) setting. For more information, see Message Logging.
Note: The e-mail notification list feature is not available on Windows.
Visual DBA: In VIsual DBA, you set up the mail alert feature by expanding the Replication branch in the Database Object Manager and expanding the Mail Alert Users branch. For more information, see the online help topic Defining Error Mail Destinations. 
Replicator Manager: In Replicator Manager, you set up the mail alert feature using the Mail Notification List window by adding the e-mail account for those users who require e-mail notification. For more information, see Create a Mail Notification List.
The Error Mail (-MLE) flag, which controls the sending of error messages, is set by default. If you set the No Error Mail (-NML) flag, no mail messages are sent.
Note: When a transaction (for example, an unresolved collision) cannot be transmitted to its target, it remains on the distribution queue. Because the Replicator Server retries propagation every time it rereads the queue (as when new items are queued up), multiple mail notifications are sent. Consider this when deciding whether to use the MLE or -NML flags and who to include in the mail notification list.
|
|
|
If the volume of errors reaches a certain point (the default is 100), the Replicator Server shuts down to maintain the integrity of the system and to allow you to troubleshoot problems. The server automatically keeps track of its error count. You can control at what point the server shuts down by specifying a number that represents the maximum error count in the Maximum Error (-EMXn) flag.
If the error count of the server reaches the maximum error count, the server is automatically shut down. Each time the server is started, the error count of the server is reset to 0. If collision resolution is set on your system, be sure to increase the error count maximum to accommodate collision errors. Each collision, even if resolved automatically, counts as an error.
To change the maximum error count at any time, use one of the following methods:
Visual DBA and Performance Monitor: Use the Performance Monitor Raise Events page. For more information, see the Raising Events at the Server Level topic in Visual DBA or Visual Performance Monitor online help.
Replicator Manager: Use the Send Database Event Window in Replicator Manager.
|
|
|
The status of a server is sent to the Activity page in the Visual DBA Performance Monitor window or the Replication Monitor window at server startup, shutdown, and in response to a ping operation. The ping operation returns the status of the server and its error count.
Note: It is recommended that you use the rsstatd command to display Replicator Server statistics that are cumulative from server startup. Using rsstatd does not incur dbevent overhead.
You can monitor your system more closely with the Send Notifications flag
(-MON). The -MON flag causes the servers to issue activity notifications.
The -MON and Send No Notifications (-NMO) flags control whether the server issues activity notifications. Every time a row is propagated to a target and every time a transaction is committed, a notification is sent (or not sent if -NMO is selected) that updates the Incoming Records, Outgoing Records, and Activity display fields in the Performance Monitor or Replication Monitor. The -MON and -NMO flags also cause the server to notify the Performance Monitor or Replication Monitor when an error occurs. The default is -MON.
Though the -NMO flag stops the server from issuing activity notifications on errors, you can ping a server to obtain its status, overriding any -NMO flag.
|
|
|
When a Replicator Server starts, it creates three log files:
The replicat.log file contains Replicator Server messages. This file writes its buffers after every message is logged, allowing you to see the latest logged messages in real time. Messages are appended to this file from run to run.
The print.log file contains information that normally goes to the standard output (stdout), such as error output from the DBMS Server. This file contains Replicator Server messages at its specified logging level. This file gets initialized from run to run.
Unlike replicat.log, it is possible that the print.log does not contain the latest error messages.
Note: The print.log is not created on Microsoft Windows.
The commit.log file is the two-phase commit recovery log for the Replicator Server. This file must not be manipulated because it contains information to resolve leftover willing-to-commit transactions. If the server has been shut down cleanly and there are no willing-to-commit transactions, it is safe to delete this file. Otherwise, do not delete it. This file is initialized from run to run, unless there are incomplete two-phase commit transactions, in which case they are recovered first.
Periodically, you must shut down the servers to clean out the log files.
The Log Level (-LGL) flag controls which messages get written to the replicat.log file, while the Print Logging Level (-PTL) flag controls the messages written to the print.log. Both the -PTL and -LGL flags share various settings that indicate the message levels that are logged.
The message levels that require attention are the Level 1 error messages and the Level 3 warning messages. You are advised to set the -LGL flag to receive Level 1 through Level 3 messages.
|
|
|
Message logging levels 0 through 3 are as follows.
Note: Message Levels 4 and 5 are reserved for internal use only and can be set at the request of Customer Support to troubleshoot your system.
SILENT
Logs no messages.
Note: The exception is DBMS Server error messages, for example, informing users of deadlock. The server continues to channel these messages to the standard output (stdout).
Logs ERRORS
Errors are any occurrence that causes the Replicator Server to alert you to take some action. Error messages include configuration, timeout, transmission, and fatal errors such as the inability to replicate, the issuance of an invalid database event, or the inability to complete a distributed transaction.
Logs ERROR and INFORMATIONAL messages
Informational messages provide normal server status information such as startup, shutdown, and the setting of flags.
(Default) Logs ERROR, INFORMATIONAL, and WARNING messages
Warning messages convey some information about a problem or identify an unusual situation that requires your attention, for example, an invalid startup flag in the configuration file.
|
|
|
The way each Replicator Server detects, handles, and notifies you of errors depends on the error mode of the CDDS. For more information, see How Errors Are Handled.
Error handling also depends on flag settings that you can change while the server is running.
A server detects errors in these categories:
|
|
|
If the runrepl.opt file settings are invalid or inconsistent, the server logs the error, changes the offending flag to the default setting, and continues. If the runrepl.opt file settings are incomplete, that is, required options are missing, the server shuts down.
You can specify whether to bypass the unique key check on the replicated tables when the server first connects to a database.
If primary key checking is enabled, Replicator Server checks for unique keys for the tables assigned to it on the local and remote databases to which it transmits. If key checking discovers an error on the local database, the server is shut down. If an error is found when checking a remote database, the target is quieted.
The primary key-checking options are:
Enables key checking (default)
Disables key checking
|
|
|
DBMS server errors include timeout, deadlock, and log file full errors. If a DBMS server error occurs during the transmission of data or the distribution of queue information, the servers increase the error count, issue a mail message to those users listed in the Mail Notification List, and retry the transaction.
DBMS server timeout means that database resources are currently unavailable and require a retry. During the retry, the server rolls back the current transaction and re-attempts the timed-out transaction.
Note: If the error count reaches the maximum specified in the -EMX flag, the server shuts down.
|
|
|
If errors other than a DBMS server timeout occur during the transmission of data, the server performs the action as determined by the error code of the CDDS. For more information, see How Errors Are Handled.
|
|
|
The way the server processes replicated transactions is affected by configuration flags. You can use these configuration flags to do the following:
|
|
|
You can control traffic in a server by quieting or activating:
To affect a running server, you must send an event to it.
Visual DBA and Performance Monitor: For more information, see the Raising Events at the Server Level topic in online help for Visual DBA or Visual Performance Monitor.
Replicator Manager: You can send an event from the Replication Monitor or from a terminal monitor. For more information, see Send Database Event Window.
Servers, databases, or CDDSs can also be quieted by errors, depending on the error mode setting.
When you start a server, all databases and CDDSs are made active. You can, however, start a server in quiet mode by setting the Quiet Server (-QIT) flag as a startup parameter.
The flags that control server, database, and CDDS status are described below:
An active server continually processes transactions for replication.
The Unquiet Server (-NQT) flag is primarily used on a server to resume propagation suspended with the -QIT flag.
A quiet server ignores the activity in the replicated database and processes only the pending replication transactions when it receives a dd_go_servern database event. When used in conjunction with the -EVT flag, the server also processes transactions on a periodic basis. For more information, see -EVTn Flag.
If the CDDS has QuietServer error mode and an error occurs, this flag is set against a server. Use the -NQT flag to activate the server.
A single run server processes the pending replication transactions for its server number before it shuts down. This status is generally used to schedule the replication with the operating system's job scheduling system.
If an error occurs that quiets a CDDS or database, the Clear Quiet Targets (-CLQ) flag resumes propagation. When
-CLQ is issued against a server, the server continues quiet; all quieted CDDSs and databases that the server is assigned to are activated for propagation.
Note: The value of this flag is stored in the replicator system catalogs; using the dd_set_servern event merely causes the replication server to update the value.
The Quiet Database (-QDBn) flag suspends propagation activity to database number n. This flag can be set using the dd_set_servern event or in response to an error (if the error mode QuietDatabase was set).
Note: The value of this flag is stored in the replicator system catalogs; using the dd_set_servern event merely causes the replication server to update the value.
Use the -UDBn or -CLQ flag with the dd_set_servern event to resume propagation activity to a quiet database.
The Unquiet Database (-UDB) flag resumes propagation activity to a database after it is suspended with the Quiet Database (-QDB) flag or by an error (if error mode QuietDatabase was set).
The Quiet CDDS (-QCDn) flag suspends propagation activity to CDDS number n. This flag can be set using the dd_set_servern event or in response to an error (if the error mode QuietCDDS was set).
Note: The value of this flag is stored in the replicator system catalogs; using the dd_set_servern event merely causes the replication server to update the value.
Use the -UCDn or -CLQ flag with the dd_set_servern event to resume propagation activity to a quiet database.
The Unquiet CDDS (-UCDn) flag resumes propagation activity to a CDDS after it was suspended with the -QCDn flag or by an error (if error mode QuietCDDS was set).
Note: The QDB, UDB, QCD, and UCD flags do not take effect immediately; instead, they prevent or allow propagation the next time the servers read transactions from the distribution queue.
|
|
|
From the first time a record is manipulated in a distributed transaction until the last record of that transaction is processed, records applicable to the transaction are locked in the local and the target database and remain locked until the final commit (or rollback) statement is issued.
Lock timeout is controlled by the Lock Timeout (-TOTn) flag, where n is the number of seconds. Ingres Replicator waits to obtain a lock before aborting the transaction and reprocessing the replication. The recommended value for n is 30 or greater. The default value is 60. The -TOTn flag can only be set in the configuration file; therefore, to change the value of -TOTn, you must stop and restart the server after editing the configuration file.
Important! If deadlocking is a problem in your environment, replication can make the situation worse. If you are unable to resolve a deadlock, see Strategies for Avoiding Deadlock. If the problem persists, contact Customer Support for assistance.
|
|
|
Replicator Servers read the distribution queue into memory. If there is a high volume of replication activity, there is potential for the queue to become so large that the Replicator Server cannot efficiently handle it. To prevent this from occurring, Ingres Replicator provides the Transaction Break Limit (-QBT) and the Queue Read Limit (-QBM) flags, which define how many queue records can be read into memory.
The Replicator Server reads rows from the distribution queue up to the value of the -QBT flag (4000 rows by default) and begins looking for a logical break in the transaction to stop reading and start propagation. The maximum number of rows a Replicator Server can read into memory from the distribution queue is the value of the -QBM flag (5000 rows by default).
Important! If the number of rows in a single transaction exceeds the value of the -QBM flag, the Replicator Server writes an appropriate error message to the replicat.log file and shut down. You need to increase the value of the -QBM flag and restart the Replicator Server.
The settings you choose for -QBM or -QBT depend on your operating system environment and the nature of your database transactions. If you find you are running out of virtual memory or you are paging excessively in the operating system, use values lower than the default. If you are reaching the default limits and are not having memory problems, increase the default.
Note: Once memory is acquired, a Replicator Server continually re-uses it. If a Replicator Server acquires too much memory, dynamically resetting the -QBT or QBM values has no effect. To change memory usage, a Replicator Server must be shut down and restarted.