Table of Contents
A trigger row may be updated using SQL to change a synchronization definition.
SymmetricDS will look for changes each night or whenever the Sync Triggers Job
is run (see below). For example, a change to place the table
into the price channel would be accomplished with the following statement:
update SYM_TRIGGER set channel_id = 'price', last_update_by = 'jsmith', last_update_time = current_timestamp where source_table_name = 'price_changes';
All configuration should be managed centrally at the registration node. If enabled, configuration changes will be synchronized out to client nodes. When trigger changes reach the client nodes the Sync Triggers Job will run automatically.
Centrally, the trigger changes will not take effect until the Sync Triggers Job runs. Instead of waiting for the Sync Triggers Job to run overnight after making a Trigger change, you can invoke the syncTriggers() method over JMX or simply restart the SymmetricDS server.
The configuration of your system as defined in the
sym_* tables may be modified at runtime. By default, any changes made to
sym_* tables (with the exception of
sym_node) should be made at the registration server. The changes will
be synchronized out to the leaf nodes by SymmetricDS triggers that are automatically created on the tables.
If this behavior is not desired, the feature can be turned off using a parameter. Custom triggers may be added
sym_* tables when the auto syncing feature is disabled.
The standalone SymmetricDS installation uses Log4J for logging. The configuration file is
log4j.xml file has hints as to what logging can be enabled for useful, finer-grained logging.
SymmetricDS proxies all of its logging through Commons Logging. When deploying to an application server, if Log4J is not being leveraged, then the general rules for for Commons Logging apply.
Monitoring and administrative operations can be performed using Java Management Extensions (JMX). SymmetricDS uses MX4J to expose JMX attributes and operations that can be accessed from the built-in web console, Java's jconsole, or an application server. By default, the web management console can be opened from the following address:
Using the Java jconsole command, SymmetricDS is listed as a local process named SymmetricLauncher.
In jconsole, SymmetricDS appears under the MBeans tab under then name defined by the
property. The default value is SymmetricDS.
The management interfaces under SymmetricDS are organized as follows:
Node - administrative operations
Incoming - statistics about incoming batches
Outgoing - statistics about outgoing batches
Parameters - access to properties set through the parameter service
Notifications - setting thresholds and receiving notifications
SymmetricDS creates temporary extraction and data load files with the CSV payload of a synchronization when
the value of the
stream.to.file.threshold.bytes SymmetricDS property has been reached. Before reaching the threshold, files
are streamed to/from memory. The default threshold value is 32,767 bytes. This feature may be turned off by setting the
property to false.
SymmetricDS creates these temporary files in the directory specified by the
java.io.tmpdir Java System property. When
SymmmetricDS starts up, stranded temporary files are aways cleaned up. Files will only be stranded if the SymmetricDS engine is force killed.
The location of the temporary directory may be changed by setting the Java System property passed into the Java program at startup. For example,
Purging is the act of cleaning up captured data that is no longer needed in SymmetricDS's runtime tables. Data is purged through delete statements by the Purge Job. Only data that has been successfully synchronized will be purged. Purged tables include:
The purge job is enabled by the
start.purge.job SymmetricDS property. The job runs periodically according to the
job.purge.period.time.ms property. The default period is to run every ten minutes.
Two retention period properties
indicate how much history SymmetricDS will retain before purging. The
purge.retention.minutes property indicates the period
of history to keep for synchronization tables. The default value is 5 days.
indicates the period of history to keep for statistics. The default value is also 5 days.
The purge properties should be adjusted according to how much data is flowing through the system and the amount of storage space the database has. For an initial deployment it is recommended that the purge properties be kept at the defaults, since it is often helpful to be able to look at the captured data in order to triage problems and profile the synchronization patterns. When scaling up to more nodes, it is recomended that the purge parameters be scaled back to 24 hours or less.