SAP HANA – Fixing “getnameinfo failed” and “Could not reach any host of site”

Recently, I encountered recurring errors in an SAP HANA System Replication environment. The messages appeared in both the tenant’s indexserver_alert and the SYSTEMDB’s nameserver_alert logs.

In this case, the solution was to add the virtual IP address (VIP) and its hostname to /etc/hosts on both cluster nodes.

Symptoms

The tenant’s indexserver_alert contained the following error:

e sr_nameserver DRClient.cpp(01052) :
Could not reach any host of site '1' to send request 'dr_getservers'.
Hosts: (hostname:port) Errors:
nameserver communication error;internal error(5500)

A similar message appeared in the SYSTEMDB’s nameserver_alert:

e sr_nameserver DRClient.cpp(01052) :
Could not reach any host of site '1' to send request 'dr_getservers'.
Hosts: (hostname:port) Errors:
nameserver communication error;internal error(5500)

The SYSTEMDB log also repeatedly reported:

e commlib commlibImpl.cpp(01449) :
::getnameinfo for '192.0.2.139' failed with rc -2
(Name or service not known)

The IP address shown above is an example.

The getnameinfo message provided a useful clue: the system could not resolve a name for the reported IP address.

Checking name resolution

getnameinfo() is a system function that translates a socket address into a hostname and, optionally, a service name. Depending on the flags used by the calling application, failure to find a hostname can return an error. The function itself does not test network connectivity. Linux documentation.

The address reported in my logs belonged to the cluster VIP.

To check whether the operating system could resolve its name, I ran the following command on both nodes:

getent hosts 192.0.2.139

Neither node returned a hostname.

You can also check reverse DNS separately:

dig -x 192.0.2.139

These commands check different things: getent uses the system’s configured name resolution sources, while dig queries DNS. An entry in /etc/hosts can therefore make getent succeed without changing the DNS result.

Solution

I added a mapping for the VIP to /etc/hosts on both cluster nodes:

192.0.2.139 hana-vip.example.com hana-vip

Replace the example address and names with the actual VIP and its virtual hostname from your environment.

Use the hostname assigned to the virtual address. Mapping the VIP to a physical node’s hostname would not correctly represent an address that can move between nodes.

Also check that the hosts: configuration in /etc/nsswitch.conf includes files, so the operating system uses /etc/hosts for name resolution.

After updating both nodes, repeat the checks:

getent hosts 192.0.2.139
getent hosts hana-vip.example.com

The first command should return the VIP’s hostname, and the second should resolve that hostname to the expected address.

In my environment, the recurring errors stopped after adding the entries on both hosts.

Having the same mapping on both nodes ensures that name resolution remains available when the VIP moves to the other node.

Related SAP KBAs

Similar System Replication communication errors can have different causes. SAP documents cases where REPLICATION_STATUS is ACTIVE while SECONDARY_ACTIVE_STATUS reports CONNECTION TIMEOUT. This combination alone does not identify the cause. SAP KBA 3771265.

The following KBAs are useful when investigating these symptoms:

Full KBA content requires access to SAP for Me.

If your logs contain both the dr_getservers communication error and a recurring getnameinfo failure for the VIP, checking IP-to-hostname resolution on both nodes is a useful diagnostic step. Updating /etc/hosts resolved my case, but the same communication error can also require investigation of other causes described in the SAP KBAs.