Deliver superior customer experiences with an AI-driven platform for creating and deploying cognitive chatbots
Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
A complete cloud platform for an app or your entire digital business
Detect and predict anomalies by automating machine learning to achieve higher asset uptime and maximized yield
Automate decision processes with a no-code business rules engine
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Personalize and optimize the customer experience across digital touchpoints
Build, protect and deploy apps across any platform and mobile device
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Progress OpenEdge Replication is more reliable than ever with the debut of Replication Sets. Find out how you can benefit from this powerful new feature.
OpenEdge 11.7 introduces the concept of Replication Sets for disaster recovery plans. We covered all of the new enhancements to OpenEdge Replication in a recent blog post, but we’ll now dive in a little deeper exploring Replication Sets.
In short, a Replication Set is comprised of a source replica and two target replicas that are aware of each other. The awareness allows target replicas to transition together in the event a source replica becomes unavailable or damaged. Target replicas that transition together eliminate a single point of failure in the application environment.
Replication Sets have four important requirements:
OpenEdge has always required that After Imaging is configured and running on source replicas. Replication Sets now require that each target replica has After Imaging configured and running. The presence of After Imaging on target replicas is important as it allows for one of the target replicas to transition to a source replica. The After Imaging data will be used during the transition process to ensure that target replicas are synchronized.
Configuring After Imaging on the target replicas follows the same process as configuring After Imaging on source replicas. You should allocate the same amount of capacity on your target replicas as you do on your source replica. The configuration of After Imaging on a target replica does not need to match the physical layout of After Imaging on the source replica. Nor do target replicas require that their After Imaging configuration match. The target replicas will handle the mapping of After Imaging configurations to the data required to synchronize the targets during a transition process.
The target replicas will need to communicate with each other during the replication process so that the correct mapping of data occurs. The Replication Server will provide the data required for the targets to communicate amongst themselves. The Replication Server gets this data from the control-agent sections of the source’s properties file. It is a best practice to duplicate the source control-agent sections in each of the targets’ properties file. Duplicating the control-agent properties to each target will allow the targets to transition together if the source replica is unable to start up or the source is unable to connect to the targets.
Fail Over and Failure Recovery Transition processes for Replication Sets both need to know which target replica has the priority to transition to a source replica. The target that has priority is identified in the transition section of properties files for each replica using the transition-to-agent property. The value for the transition-to-agent property is a comma separated list that contains the names for agents for target replicas. For our purposes, let’s call our agents targetOne and targetTwo, where targetOne is the agent for the target that we want to have the priority to transition. Our transition-to-agents property would then be: transition-to-agents=targetOne,targetTwo. In the event that targetOne and its replica are not available, then the target for targetTwo has the priority to transition to a source replica.
The last configuration task now is to enable the two-target replication environment as a Replication Set. A new property has been added to enable Replication Sets. The new property is replication-set and has two valid values: 0 or 1. The default for the replication-set is 0 and disables Replication Set functionality. The value of 1 enables Replication Set functionality. The property must be placed in the transition section of properties files for each replica for Replication Sets to be enabled. The property is checked by Replication Servers and Replication Agents when they begin, either when the database server is started or when a Server or Agent is restarted using the dsrutil utility.
In conclusion, configuring a replication environment for Replication Sets involves many of the details that OpenEdge Replication users are already familiar with. The ability of Replication Servers to communicate with Replications Agents has been leveraged to allow the agents to communicate with each other. The synchronization process that occurs when Replication Server and Agents startup has been made available for Agents to use when a transition process is wanted or needed. A replication property has been enhanced to support the transition process and one has been added to enable the environment as a Replication Set. All of this together provides for the elimination a single point of failure in OpenEdge Replication environment.
Learn more about Progress OpenEdge Replication by contacting us directly or evaluating OpenEdge 11.7 free for 60 days.
This post was written by Jeff Owen, Principal Software Engineer, OpenEdge, and Dapeng Wu, Software Architect, OpenEdge.
Jeffrey is a Principal Software Engineer working for the OpenEdge database development team. He has worked for Progress for over 27 years, starting in Technical Support and moving on to join the UNIX porting team, the database development team and the SQL development team before returning to the database development team. Prior to working for Progress, he worked at IdeAsssociates.
Copyright © 2018 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.