1. ® Information Management © 2005 IBM Corporation IBM Software Group Availability Overview in IDS Cheetah Dave Desautels Lenexa, KS Senior Software Engineer - Informix

2. Information Management 2 Agenda  Why Replicate?  Enterprise Replication – then and now  HDR – then and now  Additional new functionality in Cheetah

3. Information Management 3 Replication

4. Information Management 4 Workload Partitioning Different datum ‘owned’ in different locations (warehouses) High Availability Provide a hot backup to avoid downtime due to system failure Secondary Capacity Relief Offload some work onto secondary systems (reporting/analysis) Reporting Database Why Replicate?

5. Information Management 5 Enterprise Replication

6. Information Management 6 Pre-Cheetah: Enterprise Replication  Uses  Workload partitioning  Capacity relief  Flexible and Scalable  Subset of data  Only RDBMS with this feature  Supports update anywhere  Very low latency  Synchronize local with global data  Integrated  Compatible with all other IDS availability solutions  Secure data communications

7. Information Management 7 Enterprise Replication Topology  The entire group of servers is the replication domain  Every server has a role  Root – fully connected to all other Root servers, aware of entire topology  Non-Root – aware of the entire topology, only directly connected to it’s children and parent root  Leaf – direct connect to only Root or Non- Root nodes  Any node within the domain can replicate data with any other node in the domain  Data can be replicated thru a node without having to house the replicated table  Any node can be an HDR pair Root Non-Root Leaf

8. Information Management 8 ER Strengths  Flexible  Choose Columns to Replicate  Choose where to Replicate  Supports Update anywhere  Conflicting updates resolved by:  Timestamp, Stored Procedure, Always Apply  Completely implemented in the Server  No additional products to buy  Based on log snooping rather than transaction based  Support for heterogeneous OS, IDS versions, and hardware

9. Information Management 9 ER Guidelines  Table must have a primary key which is unique throughout the replication domain  Although Conflict Resolution supported, better to avoid conflicts  Root commit does not depend on any target commit  Need to ensure plenty of log space if network or target goes down  Smart blob space needed for queue  Could lead to extra log records written

10. Information Management 10 New Enterprise Replication Features in Cheetah  Improved ER performance: Apply Parallelism  Improved ability to update target tables in parallel  Reduces response latency back to source  Fire Triggers During Synchronization on ER Servers  Triggers can now be used during ER synchronization  Default is off  New built-in Checksum  No longer need to build a private checksum function  No setup needed to run 'cdr check' function  “cdr check” checks whether two ER nodes are in synch  Ensures the checksum is properly installed and can be safely used by all ER nodes

11. Information Management 11 HDR Replication

12. Information Management 12 Pre-Cheetah: HDR Replication  Uses:  High availability: takeover from primary  Capacity relief: distribute workload  Secondary available for Read-only queries  Simple to administer  Integrated  Compatible with all other IDS availability solutions  Any ER node can also be an HDR pair Primary serverSecondary server

13. Information Management 13 Strengths of HDR  Easy setup  Just backup the primary and restore on the secondary  No significant configuration required  Secondary can be used for dirty reads  Provides failover to secondary  Automatic failover when DRAUTO is set  Stable code  Has been part of the product since version 7  Integrates easily with ER

14. Information Management 14 Recent HDR Features Prior to Cheetah  DRIDXAUTO  Specifies if the primary will automatically resend indexes if the secondary detects corruption of the index  ER/HDR  Support of ER within the HDR environment  Support of logged extended/user defined types  Time Series, Smart Blobs, Logged UDTs  Support for HDR groups  Supports connection failover  Ontape to STDOUT  Allows a secondary to be restored from primary without doing a backup to media

15. Information Management 15 Customer Problem #1 “We Need Additional Availability!”  Need additional nodes for reports  Scale out for workload distribution  One bunker site for disaster recovery not enough

16. Information Management 16 Where do we go from Here?  Next evolutionary step for HDR  New type of secondary – RSS nodes  Can have 0 to N RSS nodes  Can coexist with HDR secondary  Uses:  Reporting  Web Applications  Additional backup in case primary fails  Similarities with HDR secondary node:  Receive logs from Primary  Has its own set of disks to manage  Primary performance does not affected RSS  RSS performance does not affect primary  Differences with HDR secondary node:  Can only be promoted to HDR secondary, not primary  Can only be updated asynchronously  Only manual failover supported Primary Node Secondary Node RSS #2RSS #1 Replication to Multiple Remote Secondary Nodes Remote Standalone Secondaries!

17. Information Management 17 Usage of RSS: Additional Capacity Applications Secondary ServersPrimary Server Customer needs to add additional capacity for its web applications. Adding additional RSS nodes may be the answer.

18. Information Management 18 Usage of RSS – Availability with Poor Network Latency Customer in Dallas wants to provide copies of the database in remote locations, but knows there is a high latency between the sites. RSS uses a fully duplexed communication protocol. This allows RSS to be used in places where network communication is slow or not always reliable. Dallas Memphis New Orleans

19. Information Management 19 Usage of RSS – Bunker Backup Customer currently has their primary and secondary in the same location and is worried about loosing them in a disaster. They would like to have an additional backup of their system available in a remote location for disaster recovery. Using HDR to provide High Availability is a proven choice. Additional disaster availability is provided by using RSS to replicate to a secure ‘bunker’.

20. Information Management 20 Customer Problem #2 “We have too much data!”  I want the benefits of replication but I can’t afford to duplicate my data  I want to have my data available on my replicas with lowest possible latency  I want to add or remove capacity as demand changes

21. Information Management 21 What is the Answer?  Next evolutionary step  SDS nodes share disks with the primary  Can have 0 to N SDS nodes  Uses:  Adjust capacity online as demand changes  Does not duplicate disk space  Features  Doesn’t require any specialized hardware  Simple to setup  Can coexist with ER  Can coexist with HDR and RSS secondary nodes  Similarities with HDR secondary node:  Dirty reads allowed on SDS nodes  The primary can failover to any SDS node  Differences with HDR secondary node:  Only manual failover of primary supported Primary SDS #1 Shared Disk Shared Disk Mirror SDS #2 SDS #3 Blade Server HDR with Multiple Shared Disk Secondary Nodes Shared Disk Secondary Nodes

22. Information Management 22 SDS Usage: Capacity as Needed Primary SDS #1 Shared Disk SDS #2 SDS #3 Blade Server A Primary SDS #1 SDS #2 SDS #3 Shared Disk Blade Server B Web Applications Analytic Applications

23. Information Management 23 Replication – The Complete Picture Primary SDS Blade Server A Building-A HDR Traffic Blade Server B HDR Secondary Shared Disk RSS Blade Server C Shared Disk Shared Disk Mirror SDS Blade Server D Building-B Offline RSS Traffic HDR Traffic Primary HDR Secondary SDS Client Apps

24. Information Management 24 Reminder: What We had Before Cheetah… HDR Blade Server A Building-A Blade Server B Blade Server A Building-A Blade Server B Building-B HDR OR…

25. Information Management 25 Problem – Secure HDR Communication  SECURITY is a concern in every industry  Data that travels between primary and secondary systems may be snooped  Replication over long distance increase the risk

26. Information Management 26 Solution - HDR Encryption  Encrypts data traffic between HDR servers  Based on OpenSSL and uses standard ciphers.  Enabled via onconfig file, defaults off  Both primary and secondary must use the same onconfig values

27. Information Management 27 Continuous Log Restore

28. Information Management 28 Existing problem (Setting up a stand by system)  Difficult to maintain an IDS instance in recovery mode  With ontape, after a log restore completes, ontape waits: bash-2.05# ontape -r Please mount tape 1 on /tape/t2 and press Return to continue....... Continue restore? (y/n)y Do you want to back up the logs? (y/n)n.... Restore a level 1 archive (y/n) n Do you want to restore log tapes? (y/n)y.... Please mount tape 1 on /tape/lt2 and press Return to continue... Do you want to restore another log tape? (y/n)  Wait at the prompt for next tape to fill up and then press Y  Otherwise system will complete recovery and comes to quiescent mode

29. Information Management 29 Preparing Remote Standby System Primary Log backup device Restore Logs onbar –b –l ontape -a Remote Standby Physical backup Physical Restore

30. Information Management 30 Continuous log restore option with ontape/onbar  With continuous log restore option, server will suspend log restore: bash# ontape -l -C Roll forward should start with log number 8 Log restore suspended at log number 10 bash#  Log restore can be restarted again with ontape command bash# ontape -l -C Roll forward should start with log number 7 Log restore suspended at log number 7 bash#  Recovery mode is terminated by ontape –l command

31. Information Management 31 Using Continuous log restore option  Logical log backups made from an IDS instance are continuously restored on a second machine  Using continuous log restore does not effect the primary server  Can co-exist with HDR/ER for disaster recovery (use HDR for HA and continuous log restore for disaster recovery)  Sending logs can be automated via ALARMPROGRAM in onconfig

32. Information Management 32 Using Continuous Log Restore for Disaster Recovery IDS Physical Log Logical Logs reserve pages DBS1 1GB DBS3 2GB DBS2 1GB ROOTDBS ID S Physical Log Logical Logs reserve pages DBS1 1GB DBS3 2GB DBS2 1GB ROOTDBS Log backup device onbar –r –l -C ontape –l -C onbar –b –l ontape -a Recoveringonline

33. Information Management 33 Combining HDR with Continuous Log Restore for HA and Disaster Recovery Secondary Primary Log backup device onbar –r –l -C ontape –l -C onbar –b –l ontape -a Remote Standby

34. Information Management 34 IDS 11.10 Information Center http://publib.boulder.ibm.com/infocenter/idshelp/cheetahb/index.jsp  Contains v11.10/2.91 and v10.0/2.90 IDS and CSDK user documentation, plus links to other essential Informix information  Task-based contents pane helps locate information; bookmarking feature keeps favorite topics handy  Extensive built-in search capability:  Full search of IDS and CSDK documentation using: –Exact words & phrases –Wildcards –Boolean operators –Criteria group –Quick Search of targeted subject areas –Results are prioritized  Questions? Ask your ID advocate  Look at the 10.0 Info Center: google “Informix Information Center”

35. Information Management 35 Helpful Links & Contacts  Informix Instant Answers by E-mail:  mailto:ibmifmx@us.ibm.com mailto:ibmifmx@us.ibm.com  Informix Product Page  http://www.ibm.com/informix/ http://www.ibm.com/informix/  Informix Platform Roadmap  http://www- 306.ibm.com/software/data/informix/pubs/roadmaps.html http://www- 306.ibm.com/software/data/informix/pubs/roadmaps.html  Informix Product Life Cycle (PLC) Roadmap  http://www-306.ibm.com/software/info/supportlifecycle/list/i.html  Informix Product Platform Availability (Select Download Spreadsheet on Right)  http://www- 306.ibm.com/software/data/informix/pubs/roadmaps.html http://www- 306.ibm.com/software/data/informix/pubs/roadmaps.html n Informix International User Group (IIUG)  http://www.iiug.org http://www.iiug.org n DM Today Newsletter  http://www-3.ibm.com/software/data/db2infonews/ http://www-3.ibm.com/software/data/db2infonews/

36. Information Management 36 Helpful Links (Continued)  Which Edition Of IDS is Right For You?  http://www-306.ibm.com/software/data/informix/ids/ids-ed-choice/ n Compare Informix Dynamic Server Editions:  http://www- 128.ibm.com/developerworks/db2/library/techarticle/dm- 0604normile/ http://www- 128.ibm.com/developerworks/db2/library/techarticle/dm- 0604normile/  Sales Guidance, Licensing Comparison of IDS Editions  http://w3- 103.ibm.com/software/xl/portal/resources/attachment/XT/U554629 G52098N57/LicensingComparison_IDS_EE_Vs_WE_Vs_ExpressV3 _2.xls http://w3- 103.ibm.com/software/xl/portal/resources/attachment/XT/U554629 G52098N57/LicensingComparison_IDS_EE_Vs_WE_Vs_ExpressV3 _2.xls  Partner World Informix Site containing the Q1 Dash Board with Play Tactics  https://www- 304.ibm.com/jct09002c/partnerworld/mem/mkt/mkt_camp_im_sr_id s.html https://www- 304.ibm.com/jct09002c/partnerworld/mem/mkt/mkt_camp_im_sr_id s.html Note: Look under “Sales Tools” tab for “Special Offers”

37. Information Management 37

38. Information Management 38