MÉTODO SAVITSKY

Once the replication servers are defined, the details of what data should be sent to the servers can be specified. That is done in the form of replicates and replicate sets.

A

replicate

is the definition of some set of data on a server to be sent elsewhere. The cdr define replicate command is used to do this.

Example 6-3 on page 76 shows the replicate definitions corresponding to the requirements of the example. The cdr define replicate command can be quite long, so we chose to use a text file to construct the command rather than typing multiple lines each time.

The first replicate definition is very simple. It specifies the one-way propagation of changes to the order table on branch2 (one of the leaf nodes) to the HQ server (the root node). No conflict resolution is required, and all the other parameters use the default values. Best practice is to use descriptive names for the replicates so that a casual observer can understand what is defined.

This replicate does not specify anything about when or how often changed data should be transferred. The default is to move the data immediately at the end of each transaction. The alternatives are to move data at some regular interval (every 15 minutes, for example) or at some specific time (at 8:00 pm local time each evening, for example).

This replicate has two participants, denoted by the P and R (the last two lines of the replicate definition). Each participant defines the database and table that is the source (P or primary) or target (R or recipient) of the data. Data changed in the primary of a replicate is propagated to the other participants. Data changed in a recipient is not propagated. In this case, the replicate is one way because there is a single source and a single target.

Alternatively, a replicate may be defined with two or more primary participants. That is how an update-anywhere replicate is defined. In that case, some conflict resolution rule is required because the same row may be updated by separate transactions on different servers at the same time. As the data is propagated, the DBMS must be told which changes override others.

The next several replicate definitions complete the set required to have the orders, items, and customer data propagated as the requirements stipulate. Because only a single table can be used in each definition, separate replicates are required for each table whose data needs to be shared.

The last two definitions are for the last two requirements. In the

prices

replicate, there is a single source and multiple targets. Note that the destination for each replicate is declared as a SELECT statement rather than an INSERT statement. Note also that the --floatieee option is used so the floating point numbers are transferred correctly between the 32-bit and 64-bit systems.

The

credchg

replicate is an update-anywhere replicate. There are not Ps or Rs to denote sources or targets. Each participant in the replicate has both roles. We chose to use the time stamp as the means of resolving conflicts. To make problem resolution easier, use the --ats option; the --ris option specifies that data for which a conflict cannot be resolved should be retained so that someone can decide what to do with it.

In the first replicates, all the columns of every row are replicated. In the last two replicates, only some of the columns are replicated. If only some columns are included, the replicate must contain the primary key, even if that is not really what should be replicated. So the only way to replicate a single column is for that column to be the entire primary key.

Note that after a replicate is defined, no data is transferred. That only happens after the replicate is started. Best practice is to define all the replicates before starting any of them. That reduces the workload to synchronize the data when the replicates are started.

Notice that the cdr list replicate command, abbreviated in the example to cdr list repl, shows some of the replicates are read-only. That is not strictly correct. Those replicates are master-slave or uni-directional replicates. The read-only designates which server is the recipient of the data. In the first replicate definition, the HQ server receives the changes, but changes there are not propagated. Changes on the branch2 server are sent to the HQ server, however. Notice that some of the replicates transfer all of the columns in the rows of a table, but others transfer only some columns. In the first case (all of the columns are replicated), you may choose to have the whole row transferred even if only some of the columns change. Or, you may choose to send only the changed data. Sending only changed data may reduce the network traffic significantly. Example 6-3 shows the ISA interface for defining a replicate.

Example 6-3 Defining replicates

cdr define repl -C ignore bandaorders \

"R stores9@HQ:informix.orders" "select * from orders" \ "P stores9@branch2:informix.orders" "select * from orders"

"R stores9@HQ:informix.orders" "select * from orders" \ "P stores9@branch1:informix.orders" "select * from orders"

cdr define repl -C ignore bandaitems \

"R stores9@HQ:informix.items" "select * from items" \ "P stores9@branch2:informix.items" "select * from items"

cdr define repl -C ignore nileitems \

"R stores9@HQ:informix.items" "select * from items" \ "P stores9@branch1:informix.items" "select * from items"

cdr define repl -C ignore bandar_cust \

"R stores9@HQ:informix.retail_customer" "select * from retail_customer" \

"P stores9@branch2:informix.retail_customer" "select * from retail_customer"

cdr define repl -C ignore niler_cust \

"R stores9@HQ:informix.retail_customer" "select * from retail_customer" \

"P stores9@branch1:informix.retail_customer" "select * from retail_customer"

cdr define repl -C ignore bandaw_cust \

"R stores9@HQ:informix.whsale_customer" "select * from whsale_customer" \

"P stores9@branch2:informix.whsale_customer" "select * from whsale_customer"

cdr define repl -C ignore nilew_cust \

"R stores9@HQ:informix.whsale_customer" "select * from whsale_customer" \

"P stores9@branch1:informix.whsale_customer" "select * from whsale_customer"

cdr define repl -C ignore --floatieee prices \ "P stores9@HQ:informix.stock" \

"select stock_num, manu_code, unit, unit_price from stock" \ "R stores9@region1:informix.stock" \

"select stock_num, manu_code, unit, unit_price from stock" \ "R stores9@branch1:informix.stock" \

"select stock_num, manu_code, unit, unit_price from stock" \ "R stores9@branch2:informix.stock" \

cdr define repl -C timestamp --ris credchg \ "stores9@HQ:informix.customer" \

"select customer_num, credit_status from customer" \ "stores9@region1:informix.customer" \

"select customer_num, credit_status from customer" \ "stores9@branch1:informix.customer" \

"select customer_num, credit_status from customer" \ "stores9@branch2:informix.customer" \

"select customer_num, credit_status from customer"

In document Diseño de una embarcación planeadora (página 42-49)