OpenEdge Replication Made Easy Adam Backman White Star Software

Agenda Setup – System – Database – Replication Maintenance Transition Common recovery scenarios Conclusion

What is it? and Why Do I Need it?

Types of System Replication True failover – Run the entire operation Partial failover – Run core services only in failover mode Recovery – The target machine is essentially a backup Asynchronous vs. Synchronous

Setup: System Operating system Hardware – Disk – Other resources Support software

Setup: Operating System Operating system version Patches Same Kernel parameters Two Reasons – Nothing unexpected when you fail over – Easier to maintain if both machines are identical

Setup: Disk Both machines need the same storage capacity (DB, application, temp files, …) Source machine can use 200 GB drives and the target can use 1TB drives This will affect performance in the event of a failover but you can choose to run only core services in failover mode

Setup - Other Resources CPU, Memory – Need to support replication Single fast CPU on replication machine Multiple CPUs in Production – Need to support all or some of your users depending on your recovery plan

Setup: Support software Fax EDI PostalSoft All software must be purchased and configured if your failover plan includes moving the users to the replication machine

Setup: Database Must have an existing comprehensive recovery plan in place Must have multi-volume after image setup Target database *should* have the same structure definition as the source

Setup: Replication We will get to the database in a minute but you need to also plan for replication of other portions of the system. Options: – Remote mirrors (hardware) – Operating system commands (Example: rsync) – Any others?

Asynchronous Replication Also know as log-based replication Not true replication but a point in time synchronization between two machines After image files are taken from the source machine and applied throughout the day Pros: – Cheap Cons: – Not synchronous – Must maintain the code yourself

OpenEdge Replication This is a feature/product from Progress that provides real-time synchronization between two or more databases. There is a replication server (source) and one or two replication agents (targets).

What is OpenEdge Replication? Users doing work After Image Source DB OE Replication Server OE Replication Agent(s) Target DB(s)

Pros and Cons: OpenEdge Replication Pros – Supported product (10.1 and above is best) – Real-time replication – Supports reporting on the target side Cons – Not free (REALLY NOT FREE) – Need to learn another set of utilities – No support (currently) for asynchronous replication

Initial Setup: OpenEdge Replication (Offline) After imaging must be enabled for the source database With the database down you can enable site replication for the source database proutil –C enablesitereplication source Move the properties files into place Currently the same directory as the DB Start the source database with -DBService replserv and -pica parameters Do an online backup of the source Restore the backup to the target

-pica Determines the size of the interprocess communication queue between the RDBMS and the replication server Default value 64k in 10.1C+ and 6k before Default value is generally too low Always set it to it’s maximum value – In 10.1C+ set it to 8192 (8MB) – Prior to 10.1C set it to 2048

Initial Setup: OpenEdge Replication (Online) Enable After Imaging (If necessary) Put the replication properties files in place You need to use deferred agent startup [server] defer-agent-startup= Note: number of minutes must be between 0 and (1 week) Enable replication proutil -C enablesitereplication source Do an online backup to build target database proutil online -REPLTargetCreation

Initial Setup: OpenEdge Replication (continued) After the restore to the target is complete Enable site replication on the target proutil –C enablesitereplication target Or prorest -REPLTransition Start the target with -DBService replagent and -S parameters Use the dsrutil utility to monitor replication dsrutil –C monitor Or look for the following message in the target database.lg file “The Source and Target databases are synchronized. (10668).”

Setup: OpenEdge properties files Server Properties File Agent Properties File(s)

Example: source.repl.properties [server] control-agents=agent1 database=source transition=manual transition-timeout=600 [control-agent.agent1] name=agent1 database=source host=moth port=4501 connect-timeout=120 replication-method=async critical=0

Example: target.repl.properties [agent] name=agent1 database=source listener-minport=4387 listener-maxport=4500

Maintenance Issues: OpenEdge Replication Fathom replication does not support 2-phase commit Index rebuild will require a initialization of the replication process (Use: index compact) Index and table moves must be done in multi- user mode Generally, changes to the database must be done in multi-user mode as the broker is the mechanism that starts replication

After image file status Empty – Ready for use Busy – Currently being used Full – Closed and applied to target Locked (Replication only) – Closed and not yet applied to target

Maintenance Is replication running? Other replication maintenance How to do common maintenance tasks – Add extents – Index rebuild

Monitoring Replication Use the dsrutil utility with the monitor option dsrutil -monitor This can be done on the source or target side

Monitoring: Server Site Replication Monitor Version 2 Page 1 Database: /data/source_db Database is enabled as Fathom Replication: Source Server is: Normal processing Number of configured agents: 1 Defer Agent Startup : Continue connection attempts until: Mon Nov 7 11:59: Deferred Agent Startup will expire in : 1 Hr 14 Min 44 Sec Next connection attempt in : 30 Seconds Connections attempts performed 1 Agent(s) currently connected 0 Delay Interval (current / min / max): 25 / 5 / 500 Recovery information State: No recovery being performed Agents needing recovery: 0 Agents connected: 0 Agents in synchronization: 0 Transition information: Type: Manual Transition timeout limit: 600 seconds Source: Progress Fathom Replication User Guide

Monitoring: Agent Site Replication Monitor Version 2 Page 1 Database: /data/source_db Agent: Name: agent1 ID: 1 Host name: localhost Target database: target_db State: Normal processing Critical: No Method: Asynchronous Remote agent is: Connected via broker Source and target are synchronized In normal processing Remote agent is waiting for: Nothing Recovery state: No recovery being performed Maximum bytes in TCP/IP message: Server/Agent connection time: Mon Oct 31 14:50: Server/Agent connection timeout: seconds Transition information: Type: Manual Timeout limit: 0 seconds The last block was sent at: Mon Oct 31 14:57: Activity information: Blocks sent: 720 Blocks acknowledged: 28 Synchronization points 12 AI Block Information: Current RDBMS Block (Seq / Block): 5 / 1923 Last Sent Block (Seq / Block): 5 / 1923 Server to agent load check interval: 10 blocks Time between server and agent load checks: seconds Time taken to respond to load check: seconds Source: Progress Fathom Replication User Guide

Other DSRUTIL Option applyextent Manual application of source AI extents to the target database. canceldefer Do not attempt reconnect to deferred replication agent. connectagent or startagent Start agent(s). disablesitereplication Online disable of replication on the source database. recovery Displays the replication recovery information.

Other DSRUTIL Option relwaits Release any waits so that database activity can continue. restart Restart replication server. terminate Terminates replication server or agent. transition Transition agent to a replication-enabled database. triggertransition Places the target database into a pre-transition state.

Transition Database Roles Changing roles How to transition – Auto – Manual

Database Roles Primary database - The database your application interacts with. Used as a source in normal operations mode Secondary database - The database that acts as a target in normal operations mode These roles do not change but in transition the Primary database can act as a target while the Secondary database interacts with your application

Failover Primary database fails If primary machine is available apply last transactions dsrutil -C applyextent Then transition the database dsrutil -C transition [failover] [failover] will transition the target via the replication agent then transition the source. If replication is not running you cannot use the failover option

Failback No activity on the databases No users on the database Run “dsrutil -C transition failover” This will transition the primary database (now target) to transition to a source and then transition the secondary database (no a source) to a target. If you have “restart-after-transition” set in the properties files then the databases will be restarted in their proper roles

Points to Remember Start with a good backup plan You must have multi-volume AI Choose a replication method that makes sense for you If you choose OpenEdge Replication use asynchronous replication for performance reasons Test extensively before doing replication in your production environment

Questions? Adam Backman

Thank you for your time!