Presentation on theme: "Chat with the Lab Replication in the IBM Informix Dynamic Server."— Presentation transcript:
Chat with the Lab Replication in the IBM Informix Dynamic Server
Replication in the IBM IDS Server - 2 Chat With the Lab Agenda FWhat is Enterprise Replication FHow is Enterprise Replication different from HDR FInternal Overview of HDR/ER FRecent Improvements in Enterprise Replication (10.x) FTroubleshooting Enterprise Replication
Replication in the IBM IDS Server - 3 Chat With the Lab IDS Enterprise Replication (ER) FLog based, Transaction oriented replication FAsynchronous, Homogeneous (IDS only) FPrimary/Target + Update anywhere FConsolidation, Dissemination, Workload partitioning FTightly coupled with the server FWeb and command line administration
Replication in the IBM IDS Server - 4 Chat With the Lab ER History FInitial Release: 7.22 in 12/1996 Version I releases FVersion II (7.31 & 9.2x) Queue and NIF redesign, Hierarchical Routing FVersion III (9.3) Extensibility, Increased parallelism, Smart blob queuing, In-place alter to add/drop CRCOLS, Serial Col Primary Key Support, … FVersion IV (9.4) ER/HDR support, Large transaction support, Complex Type support, Performance enhancements, Network Encryption FVersion V (10.x) Templates, Alter Support, Resync Support, Mastered Replicates, Shadow Replicates
Replication in the IBM IDS Server - 5 Chat With the Lab How HDR and ER differ? HDRER Provides single primary and single secondary Allows configurable source(s)/target(s) Primary and secondary must run the same executables and have similar disk layout Source/target do not have to be the same Secondary restricted to report processingAllows full usage of both source/target Simple to set up and administerSetup and administration more complex Primary and secondary are mirror imagesSource and target can be totally different Does not support blobspace blobsSupports blobspace blobs Primary purpose is for high availabilityPrimary purpose is for data distribution Replication can be synchronousReplication is asynchronous
Replication in the IBM IDS Server - 6 Chat With the Lab HDR – How it works AcctTable Logical Log Buffer Logical Logs Written to Disk PrimarySecondary Reception Buffer Recovery Buffer Logical Logs Written to Disk AcctTable LogRecvr drsecapply HDR Buffer DRINTERVAL Sets maximum time lag in seconds for HDR buffer transmission Set to ‘-1’ for synchronous.
Replication in the IBM IDS Server - 7 Chat With the Lab ER – how it works SourceTarget Spool Global Catalog syscdr Logical Log Grouper Snoopy Send Queue NIF Receive Queue Data Synch Data Synch Database Regroups transaction and performs evaluation Target apply threads Transmits Txn to targets Transmits Txn to targets Database Ack Queue
Replication in the IBM IDS Server - 8 Chat With the Lab ER Setup Issues FRow is identified by its primary key FSQLHOSTS issues FLogSize issue FConflict Resolution issues FTopology FScope issues FStable Queue
Replication in the IBM IDS Server - 9 Chat With the Lab SQL host changes for ER srv1tcp1 ontlitcp dallas port1 srv1tcp2ontlitcpdallasport2 srv1shmonipcshmdallassrv1shm1 srv2tcp1 ontlitcp houston cdr2 srv2shmonipcshmhoustonsrv2shm Label Type Server Service Options srv1_g group - - i=1 srv1tcp1 ontlitcp dallas port1 g=srv1_g srv1shmonipcshmdallassrv1shm1 srv2_g group - - i=2 srv2tcp1 ontlitcp houston cdr2 g=srv2_g srv2shmonipcshmhoustonsrv2shm CDRID – any number between 1 and Must be unique within replication domain. g=srv2_g NO!!! ER groups should only contain TCP connections. Group Name
Replication in the IBM IDS Server - 10 Chat With the Lab SQL host changes for ER with HDR (9.4) srv1tcp1 ontlitcp dallas port1 srv1tcp2ontlitcpdallasport2 srv1shmonipcshmdallassrv1shm1 srv2tcp1 ontlitcp houston cdr2 srv2shmonipcshmhoustonsrv2shm Label Type Server Service Options srv1_g group - - i=1 hdrPrim ontlitcp dallas port1 g=srv1_g dhrSecontlitcpftworthport1g=srv1_g srv1shmonipcshmdallassrv1shm1 srv2_g group - - i=2 srv2tcp1 ontlitcp houston cdr2 g=srv2_g Configure HDR pair as members Of the same ER group
Replication in the IBM IDS Server - 11 Chat With the Lab Snoopy position Replay position Current position Log needs position Replay position Snoopy position Current position Log needs position Unique id Log Number Advancing Log Positions DDR BLOCK zone Snoopy/Replay/DDRBLOCK
Replication in the IBM IDS Server - 12 Chat With the Lab Work Done to Avoid DDRBLOCK state FSpooling Threads Starts spooling much earlier FCDR_MAX_DYNAMIC_LOGS (9.4) Allows ER to dynamically add a log rather than enter a DRBLOCK state -1 Add logs infinitely 0Turn off >0Number of logs ER is allowed to dynamically create
Replication in the IBM IDS Server - 13 Chat With the Lab What is Conflict Resolution? A B C Very Fast Network Slow Network Fast Fingered Fred can update an order faster than can be delivered to ‘C’ on the ‘Buggy Network’ What to do when the original order finally arrives from A after Fred’s update has been applied? Who Wins??? Sally enters a new order on ‘A’
Replication in the IBM IDS Server - 14 Chat With the Lab Conflict Resolution FMethod to determine if the current version or a just received version of the row should ‘win’ Ignore Row must be applied as is Timestamp Most recent update wins Upsert processing Stored Procedure User written stored procedure is invoked Always Apply (10.0) Like Ignore but performs upserts FRequires CRCOLS (shadow columns) CDRTIME, CDRSERVER Create table... With CRCOLS
Replication in the IBM IDS Server - 15 Chat With the Lab What if Fred Deleted the order??? A B C Very Fast Network Slow Network Fast Fingered Fred can also delete an order faster than can be delivered to ‘C’ on the ‘Buggy Network’ Opps What to do when the original order finally arrives from A?? Deleted Row Tables
Replication in the IBM IDS Server - 16 Chat With the Lab Routing - All Roots A B C
Replication in the IBM IDS Server - 17 Chat With the Lab Routing - Hierarchial A (root) B (non-root) C (non-root) B1 (leaf) B2 (leaf)C1 (leaf) C2 (leaf)
Replication in the IBM IDS Server - 18 Chat With the Lab Routing - Hub/Spoke A (root) B (leaf) C (leaf) D (leaf) E (leaf)
Replication in the IBM IDS Server - 19 Chat With the Lab Routing vrs Replication FThe Server Definitions define the topology and routing of the ER domain FThe Replicate Definitions define which tables are replicated and where the targets are located FAny table can be replicated to any other server within the replication domain
Replication in the IBM IDS Server - 20 Chat With the Lab Things to think about Scope FTransaction scope is really “All or Nothing” If one row fails within the transaction and you are in transaction scope, then all of the rows fail. The transaction is always applied as a transaction. The transaction is NOT rolled-back on the source FTriggers are normally not fired on the target Firing triggers can be a way to replicate a procedure rather than replicate a table change FTimed Based replication is not a good thing
Replication in the IBM IDS Server - 21 Chat With the Lab Smart Blob Queue Setup (9.3+) FStable storage moved table space blobs to smart blob space FDefined by CDR_QDATA_SBSPACE in onconfig FCan be logged or non-logged 9.4 can have multiple entries for CDR_QDATA_SBSPACE Can have both logged and unlogged smartblob queue Small transactions use logged smartblob space Large transactions use unlogged smartblob space If using with HDR, then only logged smartblob space used
Replication in the IBM IDS Server - 22 Chat With the Lab ER Encryption Configuration FENCRYPT_CDR 0Encryption Turned Off 1Encrypt if peer can decrypt 2Encryption must be used FENCRYPT_CIPHERS List of to use or to reject Default is all without using ECB mode FENCRYPT_SWITCH, Time between renegotiations
Replication in the IBM IDS Server - 23 Chat With the Lab New Stuff
Replication in the IBM IDS Server - 24 Chat With the Lab New Features in 10.x FMastered Replicates FShadow Replicates FTemplate Support Allows multi-table deployment with minimal adminstration FTable Alter Support Support add/modify/drop of column, attach/detach of fragment FSync Support Supports multi-node – update anywhere syncronization FInfrastructure Mastered Replicates Shadow Replicates FOther Always Apply, Ignore Deletes
Replication in the IBM IDS Server - 25 Chat With the Lab Mastered Replicate FA new replicate type in IDS Traditional replicate are called classic replicate now FA master replicate is a replicate that stores dictionary information in CDR database FGuarantees data integrity check column type FCan be used to verify column name (--name=y) FEnables table generation on participants FAlso allow user to perform alter operations on replicated tables F“Select *” is converted into “select col1, col2, col3…”
Replication in the IBM IDS Server - 26 Chat With the Lab Master Replicate (example….) cdr define repl SharkRepl \ –S row –C always –M Miami_g –name=y \ “select * from Sharks” \ “select * from Sharks”
Replication in the IBM IDS Server - 27 Chat With the Lab Shadow Replicate A B C
Replication in the IBM IDS Server - 28 Chat With the Lab Shadow Replicate FFunctions as a ‘special case’ replicate FUsed in alter to seamlessly swap one replicate definition for another (remastering) FUsed in Sync to provide targeted replication cdr define replicate shadowReplicate -M masterNode –m primaryReplicate –S row –C always …
Replication in the IBM IDS Server - 29 Chat With the Lab Re-mastering FSeamlessly swaps one replicate definition for another FUses shadow replicates internally Fcdr remaster –M Miami_g SharkRepl “select * from Sharks” FA replicate should be re-master after a replicated table is altered on all nodes
Replication in the IBM IDS Server - 30 Chat With the Lab Template in Enterprise Replication FEase of ER administration and setup ER Template feature is an extension to the replication set concept Mass deployment with multiple tables Easy to define and deploy replicate Can create tables and deploy on new node Can provide initial data Sync Easy command line interface Eliminates many schema related errors
Replication in the IBM IDS Server - 31 Chat With the Lab Enterprise Replication Template FThe ER Template feature has two main commands and two other supporting commands. Define template Realize template List template Delete templete
Replication in the IBM IDS Server - 32 Chat With the Lab Define Template FDefine a template on participants (tables) FCreates the empty master replicates internally and also a replset on the specified tables FMaster replicate is based on tables definition taken from master node cdr define template SharkReplTemp –S row –C timestamp –M NewYork_g –d DB --all
Replication in the IBM IDS Server - 33 Chat With the Lab F Realize operation Instantiate a template on one or many server F Table on each server matches master definition F Additional columns at any participants are ignored F Realize operation can create tables F Tables can be synced at realize time cdr realize template SharkReplTemp Miami_g Charleston_g NewYork_g F Replication is started by default Realize Template
Replication in the IBM IDS Server - 34 Chat With the Lab Things to Consider With Templates FA template needs to be defined from the non-leaf server just as a replicate set and replicates FAlways we need to have direct connectivity between –c server and the Master node FAlways we need to specify a group name i.e. g_ as the master node. FInitial Sync using a template requires that all servers should be always directly connected during sync.
Replication in the IBM IDS Server - 35 Chat With the Lab Alter table/fragment support on ER table F This feature provides alter support for tables being replicated (10.00) 1.add/drop default values 2.add/drop SQL checks 3.add/drop fragments 4.attach/detach fragments 5.add/drop columns 6.recluster indexes 7.alter non replicated columns 8.modify replicated column
Replication in the IBM IDS Server - 36 Chat With the Lab Alter on Replication Table FTable defined using master replicate can be altered FDuring alter ER is notified of alter of a replicated table ER spools the queue to avoid having to snoop any old log records ER blocks any ER activity on the table (CDR Alter Mode) Normal alter logic performed ER is notified that the alter is complete and rebuilds dictionary information Table is verified to ensure that replication can resume FIf replication column is altered, it is verified FAlter mode can be set/unset manually through CDR CLI or implicitly through SQL alter statement itself. cdr alter [-c server] –o|-f
Replication in the IBM IDS Server - 37 Chat With the Lab Alter table/fragment Restrictions FER must be in active state for altering a replicated table except in scenarios where adding/dropping check constraints and default values. FAlter operations are supported only on tables defined with mastered replicates. FRename table operation is not supported FRename column operation is not supported FDrop table operation is not supported
Replication in the IBM IDS Server - 38 Chat With the Lab Resync feature in FTo bring a newly participating table up-to- date with the ongoing replication. FRepair a replicated table if replication was stopped or failed for some reason.
Replication in the IBM IDS Server - 39 Chat With the Lab Sync in a multi-node environment A B C
Replication in the IBM IDS Server - 40 Chat With the Lab Using sync option FSync tables when starting replicate FSync tables when template is realized cdr realize template –c Dallas_g SharkReplTemp –S NewYork_g cdr start replicate repl1 –S NewYork_g
Replication in the IBM IDS Server - 41 Chat With the Lab Repair using sync option FBy defining and running a ‘repair job’ FRepair is defined on active replicate FRepair entire table FRepair part of a table
Replication in the IBM IDS Server - 42 Chat With the Lab Repairing a replicate FRepair a replicate $ cdr define repair -r -b -e -S extratargetrow option can be one of : delete, keep, merge (default is delete)
Replication in the IBM IDS Server - 43 Chat With the Lab FRepair a replicate set $ cdr define repair [ -c ] -R -b -e -S CDR determines the order of replicate jobs internally based on the referential constraints between the tables in the replset on the target server. NOTE: If the source or leaf of a repair job is a leaf server then ‘connect server’ has to be a non-leaf server Repairing a set
Replication in the IBM IDS Server - 44 Chat With the Lab Running a Repair job FStarting a Repair job $ cdr start repair [ -c ] jobname The ‘connect server’ has to be the source server of the job. FStopping a Repair job $ cdr stop repair [ -c ] jobname This will stop the scanning of source table for the repair job. But forwarding of data to the target server will continue. ‘start repair’ command on the same job will resume scanning.
Replication in the IBM IDS Server - 45 Chat With the Lab How repair job work … FGenerates stored procedures and triggers to: Scan the source data Handle the extra target row options – including cascade deletes if the option is delete Cleanup the rows in the internal tables and populate the violations table for errors. Do dummy updates on the source data to replicate to the target.
Replication in the IBM IDS Server - 46 Chat With the Lab ATS & RIS Repair Command syntax: $ cdr repair ats [-C] $ cdr repair ris [-C] -C option does only check for the existence of failed rows on target and source.
Replication in the IBM IDS Server - 47 Chat With the Lab ATS & RIS Repair How It Works: If the failed operation is ‘delete’ then do a ‘local’ delete of those row(s) on the target server. If the failed operation is ‘insert’ or ‘update’ If the row(s) are found on the ‘source server’ of the failed transaction then do a ‘dummy update’ on those row(s) If the row(s) are NOT found then do a ‘local’ delete on the target server.
Replication in the IBM IDS Server - 48 Chat With the Lab In Closing - Questions???