Open TDV (TIBCO Data Virtualization) Studio, and check whether Administration >> Configuration >> Server >> Configuration >> Cluster >>
Copy Repository Database For Cluster Join is set to "
True".
If it is set to "True", do the following:
1. Disconnect the problem node from the cluster.
2. IMPORTANT: If you do not have a current full server backup CAR taken from a good node (i.e. from a node that does not exhibit this issue),
take a full server backup CAR from a good node. This is safety precaution, as the CAR will preserve all the metadata providing a rollback option in case needed.
3. Change the value of '
Copy Repository Database For Cluster Join' from "True" to "False" on all nodes (including the disconnected node).
4. Clear the repository on the disconnected node, as follows:
(a) Shut down the TDV Server.
(b) Make sure that the Repository is still running. If you are unsure whether the Repository is running, you can find out as follows:
On Windows: Open Windows Services and verify that the Repository has a "
Running" status as shown below.
On Unix: Run the command:
ps -elf | grep postgres The command should list a postgres process with a "-D data" flag, as shown below.
(c) List all files under <TDV_INSTALL>\conf\repository\postgresql whose names begin with the word 'composite_clean'. If the filenames contain version numbers (composite_clean-
nnnnnnnnn.sql, where '
nnnnnnnnn' represents a version number), identify which filename contains the highest version number.
Example cd D:\TIBCO_DV\conf\repository\postgresql
dir composite_clean*
- composite_clean-080200001.sql
- composite_clean-080401001.sql
- composite_clean.sql
In the above example, composite_clean-
080401001.sql is the
highest versioned file.
(d) Clear the Repository by running repo_util.bat (or repo_util.sh) as follows.
NOTE: This will wipe out all the metadata, reverting the Repo to a "brand new install" state. Since the metadata is being deleted, a full server backup CAR should be maintained as a precaution (please see Step 2).
If there are no versioned files (i.e. only composite_clean.sql is present), run:
repo_util.bat -dropSchema If there are versioned files, run:
repo_util.bat -dropSchema -schemaDropScript <highest versioned file> Example cd D:\TIBCO_DV\bin
repo_util.bat
-dropSchema -schemaDropScript D:\TIBCO_DV\conf\repository\postgresql\composite_clean-
080401001.sql
5. Restart the TDV server.
If the server fails to start, check to see whether the TDV logs contain errors of the type '
Failed executing SQL CREATE INDEX' accompanied by
'The repository could not be upgraded'. If these errors are present it means that
-schemaDropScript was required, but was omitted:
Example -------------
INFO 2022-03-29 10:36:09.506 -0700 JdbcRepository - Failed repository operation: CREATE INDEX system_resource_properties_mid_index ON system_resource_properties(metadata_id);
ERROR 2022-03-29 10:36:09.508 -0700 RepositoryImpl -
The repository could not be upgraded from version 31 to version 32.
Failed executing SQL CREATE INDEX system_resource_properties_mid_index ON system_resource_properties(metadata_id);. ERROR: relation "system_resource_properties_mid_index" already exists [repository-2900112]
at com.compositesw.server.repository.internal.JdbcRepository.executeUpdate(JdbcRepository.java:11432)
-------------
6. Join the server back to the cluster.
NOTE: If
Copy Repository Database For Cluster Join is already set to "False" (or if the above steps do not resolve the issue), please contact TIBCO Technical Support for assistance.