510 likes | 529 Views
Learn about database replication for remote offices, corporate data centers, and system integration. Understand different replication approaches, benefits, drawbacks, and architecture features. Explore a patented replication technology for dynamic data slicing and partner selection.
E N D
PeerDirect Distributed Enterprise J. Espen Stokke alias “Curt…” Professional Services Manager
PeerDirect Distributed Enterprise Agenda • Introduction to Database Replication • Architecture Overview • Configuration • Replication Rule Design
Introduction to Database Replication What if… • Remote offices could benefit from local application performance, no matter where they are located? • Corporate data could automatically synchronize across the enterprise? • Your eBusiness infrastructure was infinitely scalable? • Remote users could update central databases when they are on the road?
Introduction to Database Replication Remote Offices Corporate Data Center How to Remote Restore? Data Center Peak Performance Latency Restricted Data Access Remote Users Remote Failover Linking Systems Network Bandwidth and Outages Solve Common Expensive Problems . . .
Integration - Multiple Production Site No Designated Master Bi-directional & Heterogeneous Two Way Update anywhere, propagate everywhere Duplication - Single Production Site Designated Master Copy Source to Target(s) One Way Data Modifications only allowed at Source Introduction to Database Replication
Introduction to Database Replication Replication uses • Back-up • Fail-over • Latency avoidance • Load balancing • Reporting • Distributed environments • Consolidation • Synchronisation
Introduction to Database Replication Approaches • Log based (AI, Progress to Progress) • Database activity logged for periodic ‘replay’ at all locations • Queue based (SonicMQ, Any to Any) • Middleware intercepts application to database activity for periodic replay at all locations • Table based (PeerDirect, Any to Any) • Captures changes, queries source and duplicates values at all locations
Introduction to Database Replication Drawbacks of each approach • Log based • Log size • Can not remain dormant (sleeping) long • Periodically need to re-synch • Inefficient use of bandwidth • Typically only hub and spoke topology • Queue based • All of the above • Application must be modified • Table based • Not real-time • Increases database size
PeerDirect Distributed Enterprise Agenda • Introduction to Database Replication • Architecture Overview • Configuration • Replication Rule Design
Architecture Overview Order Processing Site A Production OLTP Order Processing Site B Order Processing Site C Production OLTP Production OLTP Distributed DBMS Management Features and benefits Feature Benefit • Bi-directional update-everywhere model • Read-write data between multiple databases • Replicate, synchronize, and distribute corporate data across multiple locations
Architecture Overview Features and benefits Feature Benefit • Scheduled synchronization • Net change compression • Strong encryption • Subset data using ‘slices’ • Maximize network efficiency, reduce costs • Security • Controlled access to data
Architecture Overview Features and benefits Feature Benefit • Replicates between different database types • MS SQL Server and Progress • Oracle and Progress • Supported databases • Progress • Oracle • SQL Server • DB2 • Share data in mixed environments • Consolidated view of corporate data
Architecture Overview Features and benefits Feature Benefit • Multiple topologies supported • Peer-to-peer • Hub and spoke • Load balance clustering • Provide new options for building scalable systems • Flexible configurations
Architecture Overview Features and benefits Feature Benefit • Auto-discovery of nodes within the replication network • Improve quality of service and system availability • Improved system administration • Allows mobile workers who are disconnected or have low-bandwidth limitations access to enterprise applications
Architecture Overview Features and benefits Feature Benefit • Database level configuration • Adds needed tables to replicated database to manage replication • Does not modify user-defined tables • Existing application does not need to be altered
Architecture Overview Patented replication technology • Dynamic Data Slicing Architecture (DDSA) • Table partitioning - schema • Work set partitioning - query • Column level partitioning - fragment • Dynamic data migration • Dynamic Bandwidth-Managed Partner Selection (DBP) • Auto-discovery, auto-balanced • Avoids overloading any one server • Backbone, server and workstation algorithms • Collision Avoidance Methodology (CAM) • Record fragment management – related columns • Consistent resolution contracts • Rich API for custom resolution
Architecture Overview Table-based Application Database PK Data Table “M” Rows Control Tables 1 table per database table PK Control Table “M” Rows System Tables 41 tables of setup data
Architecture Overview System Tables 41 tables of setup data + Control Tables 1 table per database table System and control table cost • Cost • Typically 15% to 25% size increase of the overall database size • Scales linearly and is predictable • Advantages • No user table modifications • No primary key restrictions • Predictable footprint
Architecture Overview Embedded Application Application Application Non-Progress Database Progress Database Database Control Tables PDR Control Tables Control Tables Triggers System Tables System Tables System Tables Change capture methods
Architecture Overview System Requirements • PDDE 6.1 • Progress 9.1D • Service Pack 5 • DataDirect Driver 4.1 • Available via FTP site
Architecture Overview PeerDirect Distributed Enterprise • Principal components PeerDirect Distributed Enterprise (PDDE) ReplicationEngine(PDRE) ReplicationDesigner(PDRD) ReplicationAdministrator(PDRA)
Architecture Overview PeerDirect Distributed Enterprise • Available licenses PeerDirect Distributed Enterprise (PDDE) SDK InnerEdge OuterEdge OuterEdgeWorkstation
Architecture Overview PeerDirect Distributed Enterprise • Available licenses InnerEdge Servers are “complete” PDRE sites that exist as part of your data center and possess a complete set of data for replication to other sites. PeerDirect Distributed Enterprise (PDDE) InnerEdge
Architecture Overview PeerDirect Distributed Enterprise • Available licenses OuterEdge Servers are PDRE sites installed in remote office locations that replicate with the central data center or peer databases. PeerDirect Distributed Enterprise (PDDE) OuterEdge
PeerDirect Distributed Enterprise Agenda • Introduction to Database Replication • Architecture Overview • Configuration • Replication Rule Design
Configuration Replication Engine • Communicates via SQL through ODBC • The closer the Replication Engine is to the database, the better the performance • Supports Win32 and Linux • Configuration of InnerEdge and OuterEdge servers affect the way in which sites will be replicated
Configuration Machine A DB PeerDirect DB Machine B Machine A PeerDirect DB DB Machine A Machine B Machine C DB DB PeerDirect PDRE Setup
Configuration Sample configuration A InnerEdge Server OuterEdge Server PeerDirect DB DB PeerDirect 4GL App.
Configuration InnerEdge Server InnerEdge Server InnerEdge Server OuterEdge Server OuterEdge Server OuterEdge Server OuterEdge Server PeerDirect PeerDirect PeerDirect PeerDirect DB DB DB DB DB DB DB PeerDirect PeerDirect PeerDirect 4GL App. 4GL App. 4GL App. 4GL App. Sample configuration B
Configuration OuterEdge OuterEdge OuterEdge OuterEdge Distributed Enterprise • Aircraft Manufacturer • Aircraft maintenance application • Maintenance records were handled either on paper or in different centralized databases • Maintenance issues cause commercial aircraft delays and military readiness issues • Solution: One PeerDirect InnerEdge Server and multiple OuterEdge Workstations • Remote capabilities, work sets, and occasionally connected users • Aircraft maintenance data captured while aircraft is being maintained resulting in significant cost savings InnerEdge
PeerDirect Distributed Enterprise Agenda • Introduction to Database Replication • Architecture Overview • Configuration • Replication Rule Design
Replication Rule Design Database considerations • Generic • No auto-increment fields • Primary keys or candidate keys must be identified • PDUSER must be created with proper DBA permissions • Progress • Unique primary keys must be defined and available to SQL engine • Primary unique index • 4GL dates must be SQL92 compliant • Be aware of column width overflow • Heterogeneous • Schemas of the data being replicated must match
Replication Rule Design Basic steps to defining rules • Specify the application database • Select the tables to replicate • Define fragments to minimize the number of data collisions • Subset data into work sets • Arrange tables in transaction sets and/or groups • Prepare to activate replication-enabled database • Enable heterogeneous replication (if required)
Replication Rule Design Partial Sports2000 Schema Analyze the Schema
Replication Rule Design Specify the application database • Select the database type • Enter the location of the database • Non-production instance is recommended for development • Enter the PDUSER user and password • Enter any optional ODBC parameters
Replication Rule Design Enter the project information • Specify the name of the project • Enter the name of the network • Enter a name for the replication release
Replication Rule Design Selecting tables to replicate • Select the Not Replicated tab • Choose the tables you wish to replicate • Multi-select tables by holding down the Ctrl or Shift keys • Right click the group and select Replicate Table • Select the Replicate tab and view the tables that are now selected to replicate
Replication Rule Design Table structure • Verify primary key or select candidate keys * • Under the Key column, click on the field that is the primary key for the table • From the drop down box, select the appropriate ordinal • Select field to be marked as a GUID field
Replication Rule Design Fragments • Generic replication • Unit of replication is whole record • Changes occur at multiple locations • One user changes Addr • One user changes Limit • Can cause ‘False Collisions’ Name Addr City Zip Ctry Pymt Rating Limit
Replication Rule Design Fragments • Common solution to generic replication • Unit of replication is each field • Changes occur at multiple locations • One user changes Addr and Limit • One user changes Addr and Zip • Can cause ‘Silent Data Corruption’ Name Addr City Zip Ctry Pymt Rating Limit Name Addr City Zip Ctry Pymt Rating Limit
Replication Rule Design Fragments • PeerDirect solution to generic replication • Unit of replication is a group of fields • Changes occur at multiple locations • One user changes Addr and Limit • One user changes Addr and Zip • Helps avoid ‘False Collisions’ • Optimizes the replication cycle Name Addr City Zip Ctry Pymt Rating Limit
Replication Rule Design Fragment considerations • Common update responsibility • Database size • 12 bytes/fragment • Frequency of replication • Frequency of data being changed • All columns in a fragment change • Primary keys can not be part of fragments • Customized conflict handling can be created
Replication Rule Design Foreign Keys • Determines the order in which tables are replicated • Parent tables must be replicated before child tables • Alphabetic order is used if no foreign key relationships are defined • Table relationships are defined from the bottom level upward • Child to parent • Must be defined if work sets or transaction sets are to be used
Replication Rule Design Foreign Keys • The Designer will read the database's key constraints and display the foreign key relationships if defined within your database
Replication Rule Design Acct Credit Hist ADetl Trans TDetl Introduction to work sets • PeerDirect allows you to define the business rules for sub-setting around base tables Ctry Off Off Prod Prod Cust Price Price Acct Credit Hist ADetl Trans TDetl
Replication Rule Design Ctry Off 1 - Canada Cust 2 - USA 12 - New York Acct 3 - Australia 29 - Toronto 142 - Bouchard . . . 37 - Montreal 217 - W. Gates 84006239 44 - Sydney 330 - A. Palmer 93050403 . . . 401 - L. Haney 93072677 550 - N. Peart 96193414 . . . 97005567 98717696 99656643 99700174 . . . Defining work sets • Define the ‘Ctry’ base table • Subscribe the site to its country
PeerDirect Replication Network Order Processing Site A Production OLTP Order Processing Site B Order Processing Site C Production OLTP Production OLTP Distributed DBMS Management
Introduction to Database Replication PeerDirect Distributed Enterprise • Breaks dependency on centralized application architectures • Radically improves employee productivity with decentralized applications • Disconnected use • Creates an inherently resilient application architecture • Eliminates the latency and availability problems caused by the centralized model