[Progress Communities] [Progress OpenEdge ABL] Forum Post: OpenEdge replication to secondary target fails.

  • Thread starter Simon L. Prinsloo
  • Start date
Status
Not open for further replies.
S

Simon L. Prinsloo

Guest
Good day My client has (almost) 24/7 operations with 11 databases, two of which are particularly large. (Backups are 134 GB and 194 GB). For a number of years now, they are running RHEL and OpenEdge 11.6 with OpenEdge Replication. The DR is identical to the production server, except for the fact that it has only half the number of processors. The current OS does not support OpenEdge 11.7. The customer bought a new server and installed Centos 7. In preparation for the switch to the new production server, OpenEdge 11.6 was installed on the new server and it was configured as a secondary replication target. The idea is to transition to this machine, restage the old DR and then to remove the old production server. It will then be rebuild using Centos 7 and OpenEdge 11.6, where after the old production server will become the new DR machine, the current DR will be decommissioned and the client will upgrade to OpenEdge 11.7.5. Currently, 10 of the 11 databases have been staged successfully and are replicating perfectly to the new server as well as the old DR. The 11th database is the largest database and gave the same problem after three failed attempts to set up the secondary target on the new server. We double checked the configuration and see no difference from the others which worked. During each attempt, a new online backup was taken with the -REPLTargetCreation switch, synced to the new machine (which takes the best part of 12-14 hours) and restored. During that time, almost 50% of the AI extents on the production db fills up. When replication is restarted, the following is found in the log of the new target: Database ... is being replicated from database ... on host . The Replication Server has been terminated or the Source database has been shutdown. The Agents will enter PRE-TRANSITION, waiting for re-connection from the Replication Server. The following appears in the log of the source database: RPLU 18: (-----) The OpenEdge Replication Server is starting... RPLU 18: (10718) Restarting OpenEdge Replication Server. RPLU 18: (453) Logout by root on /dev/pts/6. RPLS 19: (10500) The Fathom Replication Server successfully started as PID 30276. RPLS 19: (10842) Connecting to Fathom Replication Agent . RPLS 19: (10507) The Fathom Replication Server has successfully connected to the Fathom Replication Agent on host . RPLS 19: (10842) Connecting to Fathom Replication Agent . RPLS 19: (10507) The Fathom Replication Server has successfully connected to the Fathom Replication Agent on host . RPLS 19: (11251) The Replication Server successfully connected to all of its configured Agents. RPLS 19: (10508) Beginning Fathom Replication synchronization for the Fathom Replication Agent . RPLS 19: (10440) Either the Fathom Replication Agent has been incorrectly configured or the target database ... has been improperly sourced. RPLS 19: (11696) The Agent cannot be properly configured and is being terminated. RPLS 19: (10700) The Fathom Replication Agent is being terminated. RPLS 19: (10504) Unexpected error -129 returned to function rpSRV_ServerLoop. RPLS 19: (10700) The Fathom Replication Agent is being terminated. RPLU 18: (452) Login by root on /dev/pts/6. RPLU 18: (7129) Usr 18 set name to root. RPLS 19: (10505) The Fathom Replication Server is ending. At this point the replication server is terminated. The only recourse in each case was to remove the new server's configuration from the repl.properties (i.e. restore the old version) file and to restart replication server, at which point the DR was brought up to date and normal processing continued. I can find nothing regarding the error -129 reported in message number 10504. Nor do I see any problem in the configuration of the server's repl.properties file they are using. I did however note that the new target server's repl.properties does not contain any reference to the primary tartget (DR database), but apparently it is the same for the 10 databases that does work. Since the database was sourced three times already, I am also of the opinion that incorrect sourcing can be ruled out as well. Any insights are welcome. Regards Simon

Continue reading...
 
Status
Not open for further replies.
Top