From a35e2fac8416526bf5e4228df0b40d3e3c9d9dba Mon Sep 17 00:00:00 2001 From: erilong Date: Wed, 31 Oct 2007 20:14:04 +0000 Subject: [PATCH] more table definitions --- symmetric/src/docbook/user-guide.xml | 492 +++++++++++++++++++++------ 1 file changed, 382 insertions(+), 110 deletions(-) diff --git a/symmetric/src/docbook/user-guide.xml b/symmetric/src/docbook/user-guide.xml index bab37ac1ff..547da027d3 100644 --- a/symmetric/src/docbook/user-guide.xml +++ b/symmetric/src/docbook/user-guide.xml @@ -44,25 +44,50 @@ Introduction
- The Problem of Synchronization - -
-
- SymmetricDS Feature Overview + The Problem of Synchronization + + SymmetricDS includes features that solve a particular set of synchronization + problems. +
Notification Schemes - Push (trickle-back data) or Pull (trickle-poll data) changes + + After a change to the database is recorded, the nodes interested in the change + are notified. Change notification is configured to perform a push (trickle-back) + or a pull (trickle-poll) of data. When several nodes target their changes to a + central node, it is efficient to push the changes instead of waiting for the + central node to pull from each source node. When network configuration protects + a node with a firewall, a pull configuration allows the node to receive data + changes that might otherwise be blocked using push. The frequency of the change + notification is configured by default to one minute. +
Two-Way Table Synchronization - The same table can be synchronized both to and from the host system while - avoiding update loops + Some data may synchronize in one direction. For example, a retail store sends + its sales transactions to a central office, and the central office sends its + stock items to the store. Some data may synchronize in both directions. For + example, the retail store sends the central office an inventory document, and + the central office updates the document status, which is sent back to the store. + SymmetricDS supports bi-directional synchronization and avoids getting into + update loops by only recording data changes outside of synchronization.
Data Channels - Table synchronizations are grouped into independent channels + + Data synchronization is defined at the table (or table subset) level. Each + managed table can be assigned to a channel that helps control the flow of data. + A channel is a category of data that is be prioritized and synchronized + independently of other channels. For example, in a retail environment, users may + be waiting for inventory documents to update while a promotional sale event + updates a large number of items. If processed in order, the item updates would + delay the inventory updates even though the data is unrelated. By assigning item + table changes to the "item" channel and inventory table changes to the + "inventory" channel, the changes are processed independently so inventory can + get through. +
Transaction Awareness @@ -166,8 +191,8 @@ Getting Started - This chapter is a hands-on tutorial that shows how to synchronize the sample database - between two running nodes of SymmetricDS. + This chapter is a hands-on tutorial that demonstrates how to synchronize the sample + database between two running nodes of SymmetricDS. To get started, you create a root (central source) database and a client (remote target) @@ -433,13 +458,16 @@
Pulling Data - Change data on the root database, which is pulled by the client database. + + Modify data in the root database. The changes are propagated to the client database + during pull synchronization. + Open an interactive SQL session with the root database. - Add a new item for sale on the root database + Add a new item for sale to the root database insert into item_selling_price (price_id, price) values (55, 0.65); @@ -472,13 +500,16 @@
Pushing Data - Change data on the client database, which is pushed to the root database. + + Modify data in the client database. The changes are propagated to the root database + during push synchronization. + Open an interactive SQL session with the client database. - Add a new sale on the client database + Add a new sale to the client database insert into transaction (tran_id, store, workstation, day, seq) values @@ -527,59 +558,121 @@ - Node - - - - Column NameType - NullKeyDefault - Description - - - - - node_idvarchar(50)N - PKUnique identifier for a node - - - node_group_idvarchar(50)N - FKThe node group that this node belongs to, such as "store" - - - external_idvarchar(50)N - A domain-specific identifier for context within the local system. For example, the retail store number. - - - sync_enabledbooleanintN - 0Indicates whether this node should be sent synchronization. Disabled nodes are ignored by the triggers, so no entries are made in DataEvent for the node. - - - sync_urlvarchar(2000)N - The URL to contact the node for synchronization. - - - schema_versionvarchar(50)N - The version of the database schema this node manages. Useful for specifying synchronization by version. - - - symmetric_versionvarchar(50)N - The version of SymmetricDS running at this node. - - - database_typevarchar(50)N - The database product name at this node as reported by JDBC. - - - database_versionvarchar(50)N - The database product version at this node as reported by JDBC. - - - heartbeat_timetimestampN - The last timestamp when the node sent a heartbeat, which is attempted every ten minutes by default. - - - -
+ Node + + + + Column Name + Type + Null + Key + Default + Description + + + + + node_id + varchar(50) + N + PK + + Unique identifier for a node + + + node_group_id + varchar(50) + N + FK + + + The node group that this node belongs to, such as "store" + + + + external_id + varchar(50) + N + + + + A domain-specific identifier for context within the local + system. For example, the retail store number. + + + + sync_enabled + booleanint + Y + + 0 + + Indicates whether this node should be sent synchronization. + Disabled nodes are ignored by the triggers, so no entries are + made in DataEvent for the node. + + + + sync_url + varchar(2000) + Y + + + The URL to contact the node for synchronization. + + + schema_version + varchar(50) + Y + + + + The version of the database schema this node manages. Useful for + specifying synchronization by version. + + + + symmetric_version + varchar(50) + Y + + + The version of SymmetricDS running at this node. + + + database_type + varchar(50) + Y + + + + The database product name at this node as reported by JDBC. + + + + database_version + varchar(50) + Y + + + + The database product version at this node as reported by JDBC. + + + + heartbeat_time + timestamp + Y + + + + The last timestamp when the node sent a heartbeat, which is + attempted every ten minutes by default. + + + + +
@@ -588,6 +681,61 @@ Security features like node passwords and open registration flag are stored in the NodeSecurity table. + + + Node Security + + + + Column Name + Type + Null + Key + Default + Description + + + + + node_id + varchar(50) + N + PK FK + + Unique identifier for a node + + + password + varchar(50) + N + + + + The password used by the node to prove its identity during + synchronization. + + + + registration_enabled + booleanint + N + + 0 + Indicates whether registration is open for this node. + + + registration_time + timestamp + Y + + + The timestamp when this node was registered. + + + +
+ +
Node Group @@ -595,6 +743,44 @@ A category of Nodes that synchronizes data with one or more NodeGroups. A common use of NodeGroup is to describe a level in a hierarchy of data synchronization. + + + Node Group + + + + Column Name + Type + Null + Key + Default + Description + + + + + node_group_id + varchar(50) + N + PK + + + Unique identifier for a node group, usually named something + meaningful, like "store" or "warehouse". + + + + description + varchar(50) + Y + + + A description of this node group. + + + +
+
Node Group Link @@ -602,6 +788,52 @@ A source NodeGroup sends its data updates to a target NodeGroup using a pull, push, or custom technique. + + + Node Group Link + + + + Column Name + Type + Null + Key + Default + Description + + + + + source_node_group_id + varchar(50) + N + PK FK + + The node group where data changes should be captured. + + + target_node_group_id + varchar(50) + N + PK FK + + The node group where data changes will be sent. + + + data_event_action + char(1) + N + + P + + The notification scheme used to send data changes to the target + node group. (P = Push, W = Wait for Pull, X = Extract Listener) + + + + +
+
Channel @@ -610,6 +842,52 @@ Channels allow control over the type of data flowing and prevents one type of synchronization from contending with another. + + + Channel + + + + Column Name + Type + Null + Key + Default + Description + + + + + source_node_group_id + varchar(50) + N + PK FK + + The node group where data changes should be captured. + + + target_node_group_id + varchar(50) + N + PK FK + + The node group where data changes will be sent. + + + data_event_action + char(1) + N + + P + + The notification scheme used to send data changes to the target + node group. (P = Push, W = Wait for Pull, X = Extract Listener) + + + + +
+
Trigger @@ -690,76 +968,70 @@ - + version {major},{minor},{patch} - - Indicates the version of the file format - + Indicates the version of the file format - + table {table name} - - - Sets the context of which table to operate on - - + + Sets the context of which table to operate on + - + keys {column name...} - - - Lists the column names that are used as the primary key for the table. Only - needs to occur after the first occurrence of the table. - - + + + Lists the column names that are used as the primary key for the table. + Only needs to occur after the first occurrence of the table. + + - + columns {column name...} - - - Lists all the column names of the table. Only needs to occur after the first - occurrence of the table. - - + + + Lists all the column names of the table. Only needs to occur after the + first occurrence of the table. + + - + insert {column value...} - - - Insert into the table with the values that correspond with the columns - - + + + Insert into the table with the values that correspond with the columns + + - + update {old key value...},{new column value...} - - - Update the table using the old key values to set the new column values - - + + + Update the table using the old key values to set the new column values + + - + delete {old key value...} - - - Delete from the table using the old key values - - + + Delete from the table using the old key values +