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.

Firewalls and access to ports

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 9051 and 9053.

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 9052 and 9054.

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.

#!/bin/sh

JAVA_EXECUTABLE_PATH="/usr/bin/java"
JAVA_MINIMUM_VERSION=1.9
JAVA_BITNESS_REQUIRED=64
JAVA_HEAP_SIZE="-Xms2048m -Xmx4096m"
PUBPORT=9051
SUBPORT=9052

If you want to use different port numbers, modify the PUBPORT and SUBPORT entries in the Replication Server startup configuration file and restart the publication server and subscription server.

Network IP addresses

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 loopback address, localhost or 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 /sbin/ifconfig command.

For Windows only: Use the ipconfig command.

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:

127.0.0.1               localhost.localdomain localhost

You can verify this configuration by using the hostname -i command, which returns the IP address associated with the host name:

$ hostname -i
127.0.0.1

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 127.0.0.1:

#127.0.0.1              localhost.localdomain localhost
192.168.2.22            localhost.localdomain localhost
::1                     localhost6.localdomain6 localhost6

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:

service network restart
/etc/init.d/networking restart
sudo /etc/init.d/networking restart

The following example shows the service network command:

$ su root
Password:
$ service network restart
Shutting down loopback interface:                          [  OK  ]
Bringing up loopback interface:                            [  OK  ]

Use the following command for CentOS 7 or RHEL 7 and Rocky Linux 8 or AlmaLinux 8 or RHEL 8:

systemctl restart network

The hostname -i command now returns the network IP address of the host:

$ hostname -i
192.168.2.22

Postgres server authentication

#postgres-server-authentication

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 POSTGRES_INSTALL_HOME/data.

The modifications needed to the pg_hba.conf file for each of these cases follow.

Postgres publication database

For a Postgres publication database, you need the following to allow access to the publication database:

host <pub_dbname>    <pub_dbuser>    <pub_ipaddr>/32   md5
host <pub_dbname>    <pub_dbuser>    <sub_ipaddr>/32   md5

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:

# TYPE  DATABASE    USER           ADDRESS           METHOD

# "local" is for Unix domain socket connections only
local   all         all                                md5
# IPv4 local connections:
host    edb         pubuser        192.168.2.22/32     md5
host    all         all            127.0.0.1/32        md5
# IPv6 local connections:
host    all         all            ::1/128             md5
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local   replication  enterprisedb                      md5
#host    replication  enterprisedb  127.0.0.1/32        md5
#host    replication  enterprisedb  ::1/128             md5

# TYPE  DATABASE    USER           ADDRESS           METHOD

# "local" is for Unix domain socket connections only
local   all         all                                md5
# IPv4 local connections:
host    edb         pubuser        192.168.2.22/32     md5
host    edb         pubuser        192.168.2.24/32     md5
host    all         all            127.0.0.1/32        md5
# IPv6 local connections:
host    all         all            ::1/128             md5
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local   replication  enterprisedb                      md5
#host    replication  enterprisedb  127.0.0.1/32        md5
#host    replication  enterprisedb  ::1/128             md5

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_dbname>, <pub_dbuser>, and <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:

# TYPE  DATABASE    USER           ADDRESS           METHOD

# "local" is for Unix domain socket connections only
local   all         all                                md5
# IPv4 local connections:
host    edb         pubuser        192.168.2.22/32     md5
host    edb         pubuser        192.168.2.24/32     md5
host    all         all            127.0.0.1/32        md5
# IPv6 local connections:
host    all         all            ::1/128             md5
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local   replication  enterprisedb                      md5
#host    replication  enterprisedb  127.0.0.1/32        md5
#host    replication  enterprisedb  ::1/128             md5
host    replication  pubuser       192.168.2.22/32     md5

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.

Postgres subscription database

For a Postgres subscription database, you need the following entries to allow access to the subscription database:

host <sub_dbname>    <sub_dbuser>    <pub_ipaddr>/32   md5
host <sub_dbname>    <sub_dbuser>    <sub_ipaddr>/32   md5

The values you substitute for <sub_dbuser> and <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:

# TYPE  DATABASE    USER           ADDRESS           METHOD

# "local" is for Unix domain socket connections only
local   all         all                                md5
# IPv4 local connections:
host    subdb       subuser        192.168.2.22/32     md5
host    all         all            127.0.0.1/32        md5
# IPv6 local connections:
host    all         all            ::1/128             md5
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local   replication  enterprisedb                      md5
#host    replication  enterprisedb  127.0.0.1/32        md5
#host    replication  enterprisedb  ::1/128             md5

# TYPE  DATABASE    USER           ADDRESS           METHOD

# "local" is for Unix domain socket connections only
local   all         all                                md5
# IPv4 local connections:
host    subdb       subuser        192.168.2.22/32     md5
host    subdb       subuser        192.168.2.24/32     md5
host    all         all            127.0.0.1/32        md5
# IPv6 local connections:
host    all         all             ::1/128            md5
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local   replication  enterprisedb                      md5
#host    replication  enterprisedb  127.0.0.1/32        md5
#host    replication  enterprisedb  ::1/128             md5

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.

• On this page
• Firewalls and access to ports
• Network IP addresses
• Postgres server authentication