... _Example host "LOCALHOST" with service "icmp_ping" and host "localhost" with service "icmp_ping"_
This occurs when a hostname is renamed with different case and the services remain unchanged. In this use case, "uniqueify-host-hostnames.sql" will not merge the duplicate hosts, leaving them in the database. Subsequent steps in the upgrade will then fail because the table includes violation of the constraint that requires case insensitive uniqueness.
h3. What Results
Where the duplicate hostnames have different services we just detach the service information from the older host and reattach those services and associated records to the newer host; then we delete the older host. This way you lose no state or detail message.
If the same service names are seen on both hosts the problem is not that easy to fix since the service name is also duplicated, and the association is already present on the newer host. We have to delete all the service records from the older host, as there is no way to merge them, one must go.
In both cases, the resolution will delete some records but updating status, events, and performance metrics from the various feeders and agents will resume to the surviving name and its associated services.
h3. Action to Take
To resolve, first identify whether you have either duplicate host scenario using the de-duper_indentify.sql script:
{code}
source /usr/local/groundwork/scripts/setenv.sh
psql -d gwcollagedb -f show-similar-hosts.sql
{code}
If the output of this shows no names, return to the upgrade process. But if the result shows a list of duplicate host names you MUST do the next step. Remove the duplicates by running the de-duper_merge.sql script:
{code}
source /usr/local/groundwork/scripts/setenv.sh
psql -d gwcollagedb -f merge-similar-hosts.sql
{code}
Verify that a successful deduplication was accomplished by re-running the show-similar-hosts.sql script. It should return an empty list indicating no duplicate names. You may then return to the upgrade process.
|
E-mail
