Verifying host accessibility v7
If you use more than one computer to host the components of the replication system, each computer must be able to communicate with the others on a network.
Verify that the firewalls on the hosts allow access from the other hosts running replication system components. Refer to the instructions for your host’s operating system to enable accessibility.
In addition, you might run the Replication Server console or CLI on a host different from where the publication server or subscription server are running. In this case, be sure the firewall on the host running these servers allows access to the ports used by the publication server and subscription server.
The Replication Server console and CLI access the publication server and the subscription server using Java remote method invocation (RMI) through the designated ports.
The publication server uses the port number you specified during installation as well as the port offset by a value of 2 greater than this specified port number. So, for a default publication server installation, access is required for port numbers
The subscription server uses the port number you specified during installation as well as the port offset by a value of 2 greater than this specified port number. So, for a default subscription server installation, access is required for port numbers
When you install Replication Server, the port numbers you specify for the publication server and the subscription server are stored in the Replication Server startup configuration file as shown in the following example. See Replication Server startup configuration file for more information.
If you want to use different port numbers, modify the
SUBPORT entries in the Replication Server startup configuration file and restart the publication server and subscription server.
If you change the port numbers for the publication server or subscription server for which there are existing replication systems, you must perform additional updates on these existing replication systems.See Subscription server network location for changes to make for the publication server metadata in the control schema if the port number used by the subscription server changes. See Updating a subscription for changes to make for the subscription metadata in the control schema if the port number used by the publication server changed.
When configuring a replication system, you must supply the network location of various components such as the publication server, subscription server, publication database server, and subscription database server. This information, consisting of the component’s IP address and port number, is stored in the control schema.
When one component needs to access another, it refers to the network location stored in the control schema.
During replication system configuration, we recommend that you supply the actual network IP address of each component and avoid using the
127.x.x.x, even if all components are running on the same host.
You can obtain the network IP address using the following command:
For Linux only: Use the
For Windows only: Use the
The loopback address works as long as the communicating components are on the same host. But if, in the future, you decide to move a component to a different host on the network, the loopback address stored as the component’s network address in the control schema will no longer work for the component trying to make the connection.
For Linux only: You might need to modify the
/etc/hosts file so that a host’s network IP address is associated with the host’s name.
(For an alternative to modifying the
/etc/hosts file, see Assigning an IP Address for remote method invocation.)
The default configuration on Linux systems associates the host name with the loopback address in the
/etc/hosts file as shown by the following example:
You can verify this configuration by using the
hostname -i command, which returns the IP address associated with the host name:
In these circumstances, certain Replication Server components can have trouble locating the other components on the network as in the following cases:
- When the user interface attempts to connect to the publication server or subscription server
- When the subscription server attempts to connect to the publication server
If the loopback address
127.x.x.x is returned such as in the preceding example, edit the
/etc/hosts file so that the network IP address is associated with the host name instead.
The following example shows the modified
/etc/hosts file so that the host name
localhost is now associated with the network IP address
192.168.2.22 instead of the loopback address
On some Linux systems, you might need to restart the network service after you modify the
/etc/hosts file. You can do this in a number of different ways, depending on the Linux system you are using, as shown by the following variations:
The following example shows the service network command:
Use the following command for CentOS 7 or RHEL 7 and Rocky Linux 8 or AlmaLinux 8 or RHEL 8:
systemctl restart network
hostname -i command now returns the network IP address of the host:
A Postgres database server uses the host-based authentication file
pg_hba.conf to control access to the databases in the database server. You need to modify the
pg_hba.conf file in the following locations:
- On each Postgres database server that contains a Postgres publication database
- On each Postgres database server that contains a Postgres subscription database
In a default Postgres installation, this file is located in the directory
The modifications needed to the
pg_hba.conf file for each of these cases follow.
For a Postgres publication database, you need the following to allow access to the publication database:
The value you substitute for
pub_dbname is the name of the Postgres publication database you intend to use. The value you substitute for
pub_dbuser is the publication database user name you created in Step 1 of Postgres Publication Database.
For a Postgres publication database named edb, the resulting
pg_hba.conf file appears as follows:
The preceding example assumes the publication server and the subscription server are running on the same host, hence the single entry for database edb. If the publication server and subscription server are running on separate hosts, then the
pg_hba.conf file on the publication database server appears as follows:
In addition, the preceding examples assume publication database edb is using the trigger-based method of synchronization replication. If you are using the log-based method, the
pg_hba.conf file must contain an additional entry with the DATABASE field set to replication for
<pub_ipaddr> to allow replication connections from the publication server on the host on which it's running.
The following shows a modification of the preceding example with this additional entry as the last line in the file:
See Synchronization replication with the log-based method and Enabling synchronization replication with the log-based method for additional information.
Reload the configuration file after making the modifications. Select Reload Configuration (Expert Configuration > Reload Configuration on EDB Postgres Advanced Server) from the Postgres application menu. Reloading puts the modified
pg_hba.conf file into effect.
For a Postgres subscription database, you need the following entries to allow access to the subscription database:
The values you substitute for
<sub_dbname> are the subscription database user name and the subscription database name you created in steps 1 and 2 of Postgres subscription database.
For a Postgres subscription database named subdb, the resulting
pg_hba.conf file appears as follows:
The preceding example assumes that the publication server and the subscription server are running on the same host. Hence, only one entry is needed for database subdb. If the publication server and subscription server are running on separate hosts, then the
pg_hba.conf file on the subscription database server looks like the following:
Reload the configuration file after making the modifications.
Select Reload Configuration (Expert Configuration > Reload Configuration on EDB Postgres Advanced Server) from the Postgres application menu. Reloading puts the modified
pg_hba.conf file into effect.