Wilhelmus van der Ham (WITS - Worldwide IT Solutions di Wilhelmus van der Ham & C. sas) asked a question.

May 8, 2026 at 10:48 AM
OpenEdge Replication Startup and Client connection considerations

We're in the process of setting up OpenEdge Replication for a customer and are wondering how to handle certain situations. (platform Windows 64bit, version 11.7 OE, two servers PRD1 and PRD2)

1.AutoStart of Database Server

Currently the databases are configured as auto start in the OpenEdge Explorer and with a series of startup parameters but without the -DBService which should be replserver or replagent depending on which server is the current Replication source. How can this be handled smoothly?

2.Client connection

All clients connection to the database should always connect the Replication Source. But how can a client tell which one of the two databases is the Replication Source?

 

Looking forward to your Best Practices.

  • 2 answers
  • 100 views
James Palmer likes this.

  • James Palmer (Vertu Motors PLC)

    1. I would use a .pf file in the extra parameters section of the startup (I would recommend using that for all DB startup params in honesty, then you can version control the .pf file). Your process for failing over would then make sure the correct .pf file is in place. May be a little bit of manual effort, but easier than changing OE Exploder and scriptable.
    2. We have all clients connect using a host name rather than IP then it's just a case of changing the DNS as part of the failover.

  • Simon Prinsloo (Vidisolve (Pty) Ltd)

    In out case, the host's name and IP stays the same, and replication is configured using that. We also have a "cluster" IP with its own DNS name which is assigned to the replication source. Clients exclusively access the application using the DNS name of the cluster IP.

     

    The failover script, in addition to failing over the databases, also remove the IP from the old replication source and add it to the new one. This should be relatively straight forward to script in PowerShell and it protects you against situations where DNS cache cause clients to attempt to connect to the old IP. If you plan to run reporting against the replication target, you can use a similar pattern to identify that host.

     

    Since our databases are started as systemd services using a startup script, the script simply looks if the cluster IP is present and decide based on that which replication parameter to append. That will obviously not work in your case. In your case, I would go for a version James's solution. I would have a reference pf file for the source-mode and for target-mode and put both on both machines, with names clearly indicating if it is source or target. I will let the failover script copy the relevant one for the machine's new role to a more generically named live pf. Even better with PowerShell you can easily create a symlink instead, so the live pf and the reference pf cannot not go out of sync. You then reference the live name in the in the extra parameters section.

     

    I also like James's idea of putting all DB parameters in there and put it under source control. That way, it will be much simpler to keep the config on the two machines in sync. DO NOT put the live pf in source control, it needs to be created by linking (or copying) the reference pf and if you put it in source control, one of the servers will end up with the wrong version. If you create a link, there is no extra work if you make a change, beyond checking out the latest version on both machines. If you go the copy route, you obviously need to copy it to the live version after checking out the latest one.