Verifying Host Accessibility v6.2
If more than one computer is used to host the components of the replication system, each computer must be able to communicate with the others on a network. There are a number of different aspects of this topic as discussed in the following sections.
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 directions for your host’s operating system to enable accessibility.
In addition if you are running the xDB Replication Console or the xDB Replication Server CLI on a different host than where the publication server or subscription server are running, be sure the firewall on the host running these servers allows access to the ports used by the publication server and subscription server.
The xDB Replication Console and xDB Replication Server 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 on the Publication Server Details screen in Step 16 of Installing With Stack Builder or StackBuilder Plus as well 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 on the Subscription Server Details screen in Step 17 of Installing With Stack Builder or StackBuilder Plus 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 xDB Replication Server, the port numbers you specify for the publication server and the subscription server are stored in the xDB Startup Configuration file as shown by the following example. See xDB Startup Configuration File for information on the xDB Startup Configuration file.
#!/bin/sh JAVA_EXECUTABLE_PATH="/usr/bin/java" JAVA_MINIMUM_VERSION=1.8 JAVA_BITNESS_REQUIRED=64 JAVA_HEAP_SIZE="-Xms256m -Xmx1536m" PUBPORT=9051 SUBPORT=9052
If you want to use different port numbers, modify the PUBPORT and SUBPORT entries in the xDB Startup Configuration file and restart the publication server and subscription server.
Note
If you change the port numbers for the publication server or subscription server for which there are existing replication systems, there are additional updates you must perform upon these existing replication systems.See Subscription Server Network Location for changes that must be made for the publication server metadata in the control schema if the port number used by the subscription server has been changed. See Updating a Subscription for changes that must be made for the subscription metadata in the control schema if the port number used by the publication server has been changed.
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 it is strongly suggested that you supply the actual network IP address of each component and avoid the usage of 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: Open a Command Prompt window and use the ipconfig command.
The loopback address works as long as the communicating components are on the same host, but if at some future point, 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 may need to modify the /etc/hosts file so that a host’s network IP address is associated with the host’s name.
Note
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
This is also verified 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 xDB Replication Server components will have trouble locating its 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 may need to restart the network service after you have modified the /etc/hosts file. This may be done a number of different ways depending upon 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 illustrates 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 the aforementioned cases are discussed in the following sections.
Postgres Publication Database
For a Postgres publication database, the following is needed 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
Note
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 would look like the following:
# 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 the log-based method is used, 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 is 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 on synchronization replication with the log-based method.
Reload the configuration file after making the modifications.
Choose Reload Configuration (Expert Configuration, then Reload Configuration on Advanced Server) from the Postgres application menu. This will put the modified pg_hba.conf file into effect.
Postgres Subscription Database
For a Postgres subscription database, the following entries are needed 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
Note
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:
# 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.
Choose Reload Configuration (Expert Configuration, then Reload Configuration on Advanced Server) from the Postgres application menu. This will put the modified pg_hba.conf file into effect.