Download ppt - IBM Software Group | IBM Informix Data Management Software Informix User Forum 2005 Replication Solutions in the IBM Informix Dynamic Server - 1 Replication

IBM Software Group | IBM Informix Data Management Software

Informix User Forum 2005 Replication Solutions in the IBM Informix Dynamic Server - 1

Replication Solutions in the IBM Informix Dynamic Server

Speaker NameSpeaker Name

Madison Pruet / IBMMadison Pruet / IBM

Informix User Forum 2005 Moving Forward With Informix

Atlanta, Georgia December 8-9, 2005



Replication Offerings in IDS

Primary Secon

daryHDR

Enterprise Replication



How HDR and ER differ?

HDR ER

Provides single primary and singlesecondary

Allows configurable source(s)/target(s) and supports peer-to-peer

Primary and secondary must run thesame executables and have similardisk layout – they are mirror images

Source/target do not have to be thesame – they do not have to be mirrorimages

Secondary restricted to ‘dirty read’report processing

Allows full transactional usage of both source and target

Simple to set up and administer Setup and admin. more complex (pre-v10)

Does not support blobspace blobs Supports blobspace blobs

Primary purpose is for high availability Primary purpose is for data distribution

Replication can be synchronous Replication is asynchronous



Highly Available Replication (HDR)

PrimPrimaryary SSecoeco

ndaryndary



HDR Setup

B

Primary

ontape –s –L 0 / onbar –b –L 0

1) Backup made of primary server

onmode –d primary Server-B

2) Notify primary server identity of secondary

ontape –p / onbar –r -p

3) Physical restore backup on secondary server

Logs

5) Logical log transmission begins

Primary

Secondary

A

4) Notify secondary server identity of primary

onmode –d secondary Server-A



HDR – Normal Operations

B

Dirty Reads Allowed

Primary Second

ary

A

Users reading and updating databaseCan be

Updated

Network LinkFor log Transmission

Running Reports

Log Buffers are transferred to

Secondary



HDR Availability - Failover

B

Users reading and updating database

Secondary

Down

A

Standard

onmode –d standard

Running Reports (Not Any More!!)



Down

HDR Restart

B

Standard

A

onmode -s

1) Bring Server-B to quiescent state

Quiescent

onmode –d secondary Server-A

Secondary

2) Switch Server-B back to secondary mode

4) Possibly restore unloaded logs5) Transfer current logs from secondary and resume

Primary

3) Physically Restore failed system (if media failure) or Restart primary server (no media failure)

ontape -p

oninit



Recent Changes to HDR

Support of logged SBLOBSSupport of TimeSeriesTransfer of index if corruption encounteredReimplementation of DRAUTOGroup Name Usage

Probably need to set INFORMIXCONRETRY and INFORMIXCONTIME

INFORMIXCONTIME – TCP timeout value in secondsINFORMIXCONRETRY – number of times to retry the TCP connect



Demo 1 TimeDemo 1 Time



Enterprise Replication (ER/CDR)



New ER features for v10Major Features

Schema Evolution Support

Initial Sync/Resync Support

Enabling cdr sync and cdr check in v10UC4

Template SupportSupporting Functionality

Mastered Replicates

Shadow ReplicatesMiscellaneous

Always Apply Conflict Resolution

Ignore Deletes



Mastered ReplicatesER maintains a dictionary defining the transport formatCan be strict (column names must match) or non-strictDictionary obtained by selecting information from one of the cataloguesProvides better support for replicate consistency

Local table definition checked against the schema definition within ER

Strictly mastered replicates (name verification) simplify schema evolutionWhen performing schema evolution, the local format of the row and the replicated format of the row may differDictionary obtained from the table definition at ‘define replicate’ timeClassic replicates (pre v10) can be converted to mastered replicatesRequired for Schema Evolution Support



Shadow ReplicatesProvides a seamless means of converting the replicate characteristics, including the projection listProvides replication between a subset of the participants of a primary replicateThe shadow can be swapped with its primaryCan have some different attributes from the primary replicate

Primary replicate might be using timestamp conflict resolution, but shadow might be always apply

Can contain different columns from the primary replicateMust be in the same state as the primary replicateProvides supporting functionality for other functions

Remastering

Sync

Schema Evolution



Defining a Mastered Replicate

usage: cdr define repl [-c server] [-vuiAFIORTm] -C rule(s) [-M master] [-S scope] [-n y/n] [-t] [-a time] [-e intvl] [-f y|n] [-D y/n] repl participant -M --master=<node> define master replicate -t --empty Empty mastered replicate -n --name=y|n mastered replicate name verification -v --verify verify the existing replicates using master definition -u --autocreate automatically create tables if they do not exists -a time --at=time replicate at specified time -c server --connect=server connect to server -e intvl --every=intvl replicate every intvl minutes -i --immediate continuous replication (default) -A --ats aborted transaction spooling -C rule[,rule] --conflict=rule[,rule] conflict resolution rule(s) -F --floatcanon transfer floating point in canonical form (deprecated) -I --floatieee transfer floating point in IEEE form (recommended) -O --optimize don't call procedure unless different server -R --ris row information spooling -T --firetrigger fire triggers when replicating -S scope --scope=scope scope of conflict resolution (row or trans) -f y|n --fullrow y|n Enable/Disable sending of full row for updates -m <primary repl> --mirrors <primary repl> Define a shadow replicate -D y|n --ignoredel y|n do not process any deletes on targets

Identifies the node to be used as the source of the CDR catalogue Used to create an empty mastered replicate Create a strict mastered replicate Perform verification

only Automatically create non-existing objects



Adding a participant to an existing mastered replicate

usage: cdr change repl [-c server] [-a | -d] [-v | -u] replicate participant -c server --connect=server connect to server -a --add add participant -d --del remove participant -v --verify verify the existing replicates using master definition -u --autocreate automatically create tables if they do not exists



Defining a Shadow Replicate

usage: cdr define repl [-c server] [-vuiAFIORTm] -C rule(s) [-M master] [-S scope] [-n y/n] [-t] [-a time] [-e intvl] [-f y|n] [-D y/n] repl participant -M --master=<node> define master replicate -t --empty Empty mastered replicate -n --name=y|n mastered replicate name verification -v --verify verify the existing replicates using master definition -u --autocreate automatically create tables if they do not exists -a time --at=time replicate at specified time -c server --connect=server connect to server -e intvl --every=intvl replicate every intvl minutes -i --immediate continuous replication (default) -A --ats aborted transaction spooling -C rule[,rule] --conflict=rule[,rule] conflict resolution rule(s) -F --floatcanon transfer floating point in canonical form (deprecated) -I --floatieee transfer floating point in IEEE form (recommended) -O --optimize don't call procedure unless different server -R --ris row information spooling -T --firetrigger fire triggers when replicating -S scope --scope=scope scope of conflict resolution (row or trans) -f y|n --fullrow y|n Enable/Disable sending of full row for updates -m <primary repl> --mirrors <primary repl> Define a shadow replicate -D y|n --ignoredel y|n do not process any deletes on targets

Name of the primary replicate for this shadow replicate



Shadow Replicates (with schema evolution)

A

C

B

A table has been altered.A shadow of the primary replicateis created and then the two areswapped. This allows each node to

receive in either the primary or the shadow.

Replicating old format of row

Replicating newformat of row



How shadow replicates are used with resync

A

C

B

Resync Data for thereplicate uses shadow



Swapping the shadow with the primary

icdr swap shadow -xusage: cdr swap shadow [-c server] -p name -P ID -s name -S ID -p --primaryname=xxx name of primary replicate -P --primaryid=XXX id of primary replicate -s --shadowname=yyy name of shadow replicate -S --shadowid=YYY id of shadow replicate

N.B. As part of the swap, then name of the primary and the shadow replicate will be swapped. The replicate id will not. Use cdr list replicate to get the replicate id.



Converting a classic replicate into a mastered replicate

Must be done prior to performing any alter on a replicated tableFirst create a shadow replicate for the existing primary replicateThen swap the shadow with the primary replicateOnce swap is performed, remove the shadow



Setup diagram for demos

serv2 (cdr2) serv3 (cdr3)serv4 (cdr4)

HDR

serv1prim/serv1sec (cdr1)

CorporateHeadquarters

ER ERER

Regional Offices

N.B. Any node withinthe domain can replicateto any other node withinthe domain. They do not have to be directlyconnected.



Sqlhost file for using ER with HDR

cdr1 group - - i=1serv1prim onsoctcp linuxt40 ids.serv1prim g=cdr1serv1sec onsoctcp linuxt40 ids.serv1sec g=cdr1 cdr2 group - - i=2serv2 onsoctcp linuxt40 ids.serv2 g=cdr2 cdr3 group - - i=3serv3 onsoctcp linuxt40 ids.serv3 g=cdr3 cdr4 group - - i=4serv4 onsoctcp linuxt40 ids.serv4 g=cdr4

HDR pair configured in one group






TemplatesProvides a means for deployment of many tables as a unit

Simplifies Administration

Creates a Replicate Set

Reduces the Effort to setup ReplicationDefining the template

Sets the tables within the template – can be entire database

Defines the replication attributes

Generates mastered replicates for the members of the template

Realizing the templateCreates all of the participants on the node

Can create the tables and/or database on the nodes

Verifies that all of the columns match properly



First create stores_demo database on cdr1

We will create the databaseon server cdr1 only. We will later use the autocreatefunction to generate thedatabase and tables on theother nodes.

The “msgs” table needs to have a primary key.

> dbaccessdemo -log

DBACCESS Demonstration Database Installation Script

Dropping existing stores_demo database ....

Creating stores_demo database ....

Lockmode set.

Database created.

Database closed.

…

> dbaccess stores_demo -Database selected.> alter table msgs add constraint primary key (number, lang);Table altered.



Then create the ‘stores’ template on the database

> cdr define template stores -C always -S row -M cdr1 -d stores_demo –aObtaining dictionary for stores_demo@cdr1:''mpruet''.customerObtaining dictionary for stores_demo@cdr1:''mpruet''.ordersObtaining dictionary for stores_demo@cdr1:''mpruet''.manufactObtaining dictionary for stores_demo@cdr1:''mpruet''.stockObtaining dictionary for stores_demo@cdr1:''mpruet''.itemsObtaining dictionary for stores_demo@cdr1:''mpruet''.stateObtaining dictionary for stores_demo@cdr1:''mpruet''.call_typeObtaining dictionary for stores_demo@cdr1:''mpruet''.cust_callsObtaining dictionary for stores_demo@cdr1:''mpruet''.msgsObtaining dictionary for stores_demo@cdr1:''mpruet''.catalogCreating mastered replicate stores_serv1_1_1_customer for table ''mpruet''.customerCreating mastered replicate stores_serv1_1_2_orders for table ''mpruet''.ordersCreating mastered replicate stores_serv1_1_3_manufact for table ''mpruet''.manufactCreating mastered replicate stores_serv1_1_4_stock for table ''mpruet''.stockCreating mastered replicate stores_serv1_1_5_items for table ''mpruet''.itemsCreating mastered replicate stores_serv1_1_6_state for table ''mpruet''.stateCreating mastered replicate stores_serv1_1_7_call_type for table ''mpruet''.call_typeCreating mastered replicate stores_serv1_1_8_cust_calls for table ''mpruet''.cust_callsCreating mastered replicate stores_serv1_1_9_msgs for table ''mpruet''.msgsCreating mastered replicate stores_serv1_1_10_catalog for table ''mpruet''.catalog

Server where dictionaryis obtained

Empty Mastered replicates are created within thetemplate

Generate Template usingall tables within stores_demodatabase



What are the characteristics of a Template?

Contains the table dictionary of the members of the templateContains the column attributes of the tables within the templateProvides a description of the network format of the replicateGenerates empty replicates for each of the tables within the templateWhen realized, can generate the tables on the nodes being realizedThe template is an extension of the replicate set. Therefore, if a template is created of a database, then all of the replicated tables will be part of that replicate set. This means that further administrative tasks, such as ‘cdr check’, can be performed on the set.



Finally Realize the template

cdr realize template stores -S cdr1 -u cdr2 cdr3 cdr4Verification of stores_demo@cdr2:'mpruet'.customer startedVerification of stores_demo@cdr2:'mpruet'.customer is successfulVerification of stores_demo@cdr3:'mpruet'.customer startedVerification of stores_demo@cdr3:'mpruet'.customer is successfulVerification of stores_demo@cdr4:'mpruet'.customer startedVerification of stores_demo@cdr4:'mpruet'.customer is successfulVerification of stores_demo@cdr2:'mpruet'.orders startedVerification of stores_demo@cdr2:'mpruet'.orders is successful…Creating table...create table 'mpruet'.customer ( customer_num serial not null, fname char(15), lname char(15), company char(20), address1 char(20), address2 char(20), city char(15), state char(2), zipcode char(5),…

We are ‘realizing’ the stores template on the four servers, usingthe data on cdr1 to create an initial sync. By using the –u option,we are requesting that any missing tablebe automatically created from themastered replicate dictionary.



And let’s see if it worked…

DISPLAY: Next Restart ExitDisplay next page of results.

----------------------- stores_demo@serv4 ------ Press CTRL-W for Help --------

customer_num 101fname Ludwiglname Paulicompany All Sports Suppliesaddress1 213 Erstwild Courtaddress2city Sunnyvalestate CAzipcode 94086phone 408-789-8075

N.B. – we initially only createdthe stores_demo database oncdr1, now it is on serv4/cdr4






cdr check

Provides a means of checking if replicated tables are synchronizedUses a checksum algorithm to determine if a row is not ‘in sync’Optionally can automatically repair the discrepancy if desiredProduces a report of rows not synchronizedCan be run against a replicate as well as a replicate setCan be run against multiple nodes Detects extra rows or missing rows N.B. not activated until v10UC4N.B. to use in v10UC4, the checksum UDRs must be installed (will be available in IBM developer’s works)



Problem --- data is not consistent

customer_num lname

101 Pauli 103 Currie 104 Higgins 105 Vector 106 Watson 107 Ream 108 Quinn 109 Miller 110 Jaeger 111 Keyes 112 Lawson 113 Beatty 114 Albertson

cdr2customer_num lname

101 Pauli 102 Sadler 103 Currie 104 Higgins 105 Vector 106 Watson 107 Ream 108 Quinn 110 Jaeger 111 Keyes 112 Lawson 113 Beatty 114 Albertson

customer_num lname

101 Paul 102 Sadler 103 Currie 104 Higgins 105 Vector 106 Watson 107 Ream 108 Quinn 109 Miller 110 Jaeger 111 Keyes 112 Lawson 113 Beatty 114 Albertson

cdr1 cdr4

Spelling?

102 is missing?

Extra rows



Running the basic check

cdr check replset -s stores -m cdr1 -a

------ Statistics for stores_serv1_1_1_customer ------Node Rows Extra Missing Mismatch Processed---------------- --------- --------- --------- --------- ---------cdr1 27 0 0 0 0cdr4 28 1 0 1 0cdr3 28 1 0 0 0cdr2 27 1 1 0 0

WARNING: replicate is not in sync

------ Statistics for stores_serv1_1_6_state ------Node Rows Extra Missing Mismatch Processed---------------- --------- --------- --------- --------- ---------cdr1 52 0 0 0 0cdr4 52 0 0 0 0cdr3 52 0 0 0 0cdr2 52 0 0 0 0

------ Statistics for stores_serv1_1_9_msgs ------Node Rows Extra Missing Mismatch Processed---------------- --------- --------- --------- --------- ---------cdr1 12 0 0 0 0cdr4 12 0 0 0 0…

Found the rows

N.B. Since replication wascreated by using a templatecalled stores, then we havea stores replicate set.

Run the check on all nodesusing the stores set. All nodeswill use server ‘cdr1’ as the master.



Performing check with repair

------ Statistics for stores_serv1_1_6_state ------Node Rows Extra Missing Mismatch Processed---------------- --------- --------- --------- --------- ---------cdr1 52 0 0 0 0cdr4 52 0 0 0 0cdr3 52 0 0 0 0cdr2 52 0 0 0 0

------ Statistics for stores_serv1_1_9_msgs ------Node Rows Extra Missing Mismatch Processed---------------- --------- --------- --------- --------- ---------cdr1 12 0 0 0 0cdr4 12 0 0 0 0…

cdr check replset -R -s stores -m cdr1 -a

------ Statistics for stores_serv1_1_1_customer ------Node Rows Extra Missing Mismatch Processed---------------- --------- --------- --------- --------- ---------cdr1 27 0 0 0 2cdr4 28 1 0 1 1cdr3 28 1 0 0 1cdr2 27 1 1 0 1

Run the check on all nodesusing the stores set. All nodeswill use server ‘cdr1’ as the master.

Deleted Extra Rows



Extra rows on the target Sync and check can process extra rows on the targets through --extratargetrows=<rule> (-e) option

delete – delete any extra rows found on the targets (default)

merge – replicate any extra rows on the targets to all other participants

keep – simply keep the extra rows on the targetsIf the extra row rule is delete, then sync/check will delete the targetrow using cascading deletesIf the merge rule is being used, then the row will be replicated from the target node



Sync and referential integrity

Processing of the members of a replicate set uses the referential integrity rules on the source node to determine the order of resyncParent tables are resynced prior to the child tableDeletes on the target are done using cascading deletes



cdr sync

Similar to cdr check, but does not use a checksum algorithm to detect inconsistenciesAll rows are transferred to the targetsCan be performed on a replicate or a replicate setCan support synchronization to multiple targets Invoked via the ‘cdr sync’ command, or through ‘cdr start’ and ‘cdr realize template’Does not require that the nodes be idleInvoked internally as part of start with sync functionality






Questions?Speaker NameSpeaker Name

[email protected]@us.ibm.com

Informix User Forum 2005 Moving Forward With Informix

Atlanta, Georgia December 8-9, 2005